flayr

Was du damit machen kannst

Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.

• Verbindung: Läuft in der Cloud
• Transport: Streamable HTTP
• Kategorie: Sonstiges

Installation

Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.

Du brauchst

• Läuft in der CloudNichts zu installieren; die Verbindung läuft übers Internet

Welche App nutzt du?

https://flayr.social/api/mcp

claude mcp add --transport http flayr https://flayr.social/api/mcp

{
  "mcpServers": {
    "flayr": {
      "url": "https://flayr.social/api/mcp"
    }
  }
}

{
  "servers": {
    "flayr": {
      "type": "http",
      "url": "https://flayr.social/api/mcp"
    }
  }
}

https://flayr.social/api/mcp

Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.

Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.

Was er kann

Tool-Namen und -Beschreibungen genau so, wie der Server sie am 7. Nov. 2026 gemeldet hat. Geschrieben hat sie der Entwickler, nicht wir; wir zeigen sie als reinen Text.

• whoami

  [read-only] Returns who this connection (an OAuth sign-in or an API key) belongs to: userId, the account's current plan tier, and brandId/brandName when the connection is bound to one brand (null = account-wide). Call this first to learn what the connection can reach. (Wraps GET

• list_brands

  [read-only] Lists the brands this connection can file content into and publish through. Use an `id` as `brandId` on create_content, publish, queues and analytics tools; "personal" means the account owner's personal accounts. A connection bound to one brand sees only that brand (a

• brand_profile_get

  [read-only] A brand's profile (website, companyName, tagline, industry, audience, values, pillars, hashtag sets), its default voice, colors and fonts. `brandId` comes from list_brands; a brand-bound connection may omit it. (Wraps GET /api/v2/brand/intelligence.)

• brand_profile_update

  [writes flayr data · `write` scope] Fills in a brand's profile — e.g. `{ brandId, profile: { website: "https://…" } }`. Changes only the fields you send; the voice, colors and fonts stay as they are unless you pass them. Use it to clear list_brands setup items such as hasWebsite.

• list_connected_accounts

  [read-only] The social accounts a brand can post to — the same set publish would use for that `brandId`: platform, handle, display name, health (healthy, needs_reauth, disconnected) and whether flayr can post there right now (`postable`; Reddit is paused because Reddit closed its

• account_refresh

  [writes flayr data · `write` scope] Re-reads a connected account's handle, display name and avatar from the network (use after the user renames the account) and returns the stored values. Changes nothing else: no connect, disconnect or post. If the status is not `updated`, tell t

• list_youtube_playlists

  [read-only] Playlists of the YouTube channel(s) a brand publishes to. Use a playlist id as `youtube.playlistId` on create_content or publish. (Wraps GET /api/v2/youtube/playlists.)

• list_pinterest_boards

  [read-only] Boards of the Pinterest account(s) a brand publishes to. Use a board id as `pinterest.boardId` on publish. A board is required; the one you pick is remembered as the brand's default for next time, and a publish that uses the default says so (defaultBoardApplied). (Wra

• upload_media

  [writes flayr data · `write` scope] Step 1 of attaching a LOCAL file (video or image) to a draft. Returns a single-use, short-lived `uploadUrl`. Step 2: POST the raw file bytes to it with the file's Content-Type, e.g. `curl -X POST -H "Content-Type: video/mp4" --data-binary @clip

• list_content

  [read-only] Lists content items (drafts), newest first. Each carries `postState` ("posted" / "scheduled" / null) and `posts[]` (up to 5): where it went out, per platform, with status, live URL and failure reason. (Wraps GET /api/v2/content.)

• get_content

  [read-only] One content item plus its live posting status: `postState` and `posts[]` (up to 20, newest first) with each post's status (scheduled · publishing · published · partial · failed · review_held · held), scheduledAt, and per-platform status, live URL and error. The item's

• create_content

  [writes flayr data · `write` scope] Creates a DRAFT content item. Nothing is posted. Give `text` plus optional media (`videoUrl` / `imageUrl`, or `videoStorageId` / `imageStorageId` from upload_media), target `platforms`, `brandId` (from list_brands; omitted → the brand last acti

• update_content

  [writes flayr data · `write` scope] Edits a draft in place; only the fields you pass change. Any media field replaces the draft's media as a set (keeps the id, so queue items still point at it). Refused (409) for archived or already-published items, and a media swap is refused on

• labels_bulk_edit

  [writes flayr data · `write` scope] Adds and/or removes labels on up to 100 content items in one call: each item becomes (labels − remove) + add. Published items are fine (labels are metadata). Each item succeeds or fails on its own; read `results`. Removing `source:ai-generated`

• delete_content

  [DESTRUCTIVE] DESTRUCTIVE: permanently deletes a content item from the library. Posts already live on a platform are not removed. Needs the `write` scope. Ask the user before calling. (Wraps DELETE /api/v2/content/{id}.)

• combine_clips

  [writes flayr data · `write` scope] Extends a video draft (`id`) with more clips and image cards into ONE finished video, rendered by flayr and saved as a NEW linked draft (same brand, caption copied, credits merged, labelled variant:combined). Nothing is posted and the original

• get_job_status

  [read-only] Status of an async job (combine_clips, render_motion_ad, or an API video generation): pending, processing, completed or failed. For a combine or a motion ad, `resultContentId` is the new draft once completed; a failed combine is refunded automatically. Poll every 10-3

• render_motion_ad

  [writes flayr data · `write` scope] Turns one Library image (the card) into a 6-15 s motion ad: hook (push-in on the card), up to 3 body beats (pans with the text), then a CTA end card in the brand color with the CTA and the link host. 9:16 unless `aspect` is 1:1 or 16:9. The tex

• ad_cut_lint

  [writes flayr data · `write` scope] Checks an ad's cut against the ad-cut rules: too many joins (warning), joins only at a rest point, no cut inside a caption or its fade, one caption layer, no audio dip at a join, exactly one ending, and the network's length / aspect / ad-text w

• publish

  [PUBLISHES to social accounts · `publish` scope] PUBLISHES TO REAL SOCIAL ACCOUNTS. Posts now, or at `scheduledAt` (ISO-8601, future). Prefer `contentId` (a draft from create_content: its text and media become the post) over inline `content`. The post goes out through the target

• get_post

  [read-only] A post (`id` = convexPostId from publish, or posts[].id from get_content): status, slot, platforms, and while it is scheduled the first comment each platform will publish and whether it can be changed now. (Wraps GET /api/v2/posts/{id}.)

• update_scheduled_post

  [PUBLISHES to social accounts · `publish` scope] CHANGES WHAT A SCHEDULED POST WILL PUBLISH on real accounts, keeping its slot, accounts, options, labels and draft. `firstComment` sets per-platform first comments (linkedin, facebook, instagram, threads, youtube; null removes; X/B

• cancel_scheduled_post

  [PUBLISHES to social accounts · `publish` scope] Takes a SCHEDULED post off the platform schedule and marks it cancelled (the draft stays, so it can be published again). Safe to repeat. Refused within 5 minutes of the slot, and when the platform will not remove it (some YouTube u

• list_reviews

  [read-only] Scheduled posts waiting for (or given) a human sign-off, oldest slot first. `canApprove` tells whether THIS connection may approve each one. (Wraps GET /api/v2/reviews.)

• decide_review

  [PUBLISHES to social accounts · `publish` scope] decision "approve" sends a held post to the platform for its slot (GOES LIVE) — needs the explicit `review` scope (admin does not include it) and never works on a post the same connection created. decision "hold" takes a scheduled

• list_approvals

  [read-only] Content held for approval that waits on the account owner's decision, newest first: posts filed with publish `requiresApproval: true`, drafts submitted for review, and workflow runs parked at an approval gate. `kind` is "manual" or "workflow". With status "rejected" i

• decide_approval

  [PUBLISHES to social accounts · `publish` scope] Same rules as the dashboard: only the assigned approver may decide. On a "workflow" approval, decision "approve" resumes the parked run, whose next steps may publish (GOES LIVE); "reject" cancels it. On a "manual" approval, "approv

• list_approval_groups

  [read-only] The same held content as list_approvals, grouped by piece: the variants of one draft (or sharing a `group: ` label), with the axes they vary on (theme, hook, audio …), a tally (approved / redo / dropped / open) and each variant's state and slot time. `status` open (de

• decide_approval_group

  [PUBLISHES to social accounts · `publish` scope] Decides several variants of a group from list_approval_groups at once, each as decide_approval would: `members` "all" (open variants), an array of approvalIds, or {axis: value} (e.g. {"audio":"voice"}). "approve" marks them approve

• list_queues

  [read-only] Posting (drip) queues of one brand. A queue posts one item every cadenceHours at timeOfDay in its timezone, keeping `lookahead` items booked at the platform. (Wraps GET /api/v2/queues.)

• get_queue

  [read-only] A queue and its items in order, with each item's state (queued · publishing · scheduled · posted · failed · skipped), booked or projected slot, and attribution status. (Wraps GET /api/v2/queues/{id}.)

• create_queue

  [PUBLISHES to social accounts · `publish` scope] Creates a posting queue. Once items are added it BOOKS REAL POSTS on the given platforms on its cadence (default daily 19:00 America/Chicago, 2 booked ahead). Use `startsAt` to hold everything until a date. Needs the `publish` scop

• update_queue

  [PUBLISHES to social accounts · `publish` scope] `status: "paused"` stops new bookings (already-booked posts stay booked); "active" resumes. Other fields (platforms, cadenceHours, timeOfDay, lookahead, startsAt, name) apply from the next booking. Needs the `publish` scope (or adm

• delete_queue

  [DESTRUCTIVE] DESTRUCTIVE: deletes the queue (its drafts stay in the library). With posts booked at the platform it is refused (409) unless `unschedule: true`, which first deletes those platform posts. Needs the `publish` scope (or admin) on the Agency plan or higher. Ask the use

• add_queue_items

  [PUBLISHES to social accounts · `publish` scope] Appends drafts (content ids) to the end of a queue — they will be BOOKED AND POSTED on the queue's schedule. Use `contentIds`, or `items` for a per-item YouTube title or platforms. Drafts of another brand, duplicates, archived draf

• queue_item_action

  [PUBLISHES to social accounts · `publish` scope] `action`: "skip" passes over a queued item; "retry" puts a failed/skipped item back in line; "unschedule" deletes a booked platform post and puts the item back in line. Also `youtubeTitle`, per-item `platforms`, and `position` (0-b

• remove_queue_item

  [DESTRUCTIVE] DESTRUCTIVE: removes an item (the draft stays in the library). A booked (`scheduled`) item is refused (409) unless `unschedule: true`, which deletes its platform post first. Needs the `publish` scope (or admin) on the Agency plan or higher. (Wraps DELETE /api/v2/que

• reorder_queue_items

  [PUBLISHES to social accounts · `publish` scope] Send every waiting (queued) item id exactly once, in the new order. Booked, posted, failed and skipped items keep their places. Needs the `publish` scope (or admin) on the Agency plan or higher. (Wraps POST /api/v2/queues/{id}/item

• get_analytics

  [read-only] Engagement overview for the last 7, 30 or 90 days. Pro plan or higher. (Wraps GET /api/v2/analytics.)

• query_insights

  [read-only] Read-only analytics query: one `metric` aggregated (median by default) over posts, broken down by up to a few dimensions (platform, weekday, hour, brand, campaign, postType, label: , arm), at a fixed post age `window` (48h / 7d / 30d / lifetime) so posts are compared

• compare_labels

  [read-only] Splits every labelled post by the values of one label key (e.g. key "cut" → cut:opus vs cut:raw) and reports medians with n per group at the 48h / 7d snapshot. Descriptive, not a significance test. Pro plan or higher. (Wraps GET /api/v2/analytics/experiments.)

• list_experiments

  [read-only] A/B experiments. Content joins one by carrying the label `experiment: ` plus ` : `. (Wraps GET /api/v2/experiments.)

• get_experiment

  [read-only] One experiment: hypothesis, variants, compareKey, window and status. (Wraps GET /api/v2/experiments/{id}.)

• create_experiment

  [writes flayr data · `write` scope] Creates an A/B experiment. Then tag drafts with its `label` (experiment: ) and ` : ` via update_content `labels`, publish them, and read get_experiment_results. (Wraps POST /api/v2/experiments.)

• update_experiment

  [writes flayr data · `write` scope] Changes an experiment's fields (e.g. status "running" / "done", endAt, notes). Only the fields you pass change. (Wraps PATCH /api/v2/experiments/{id}.)

• delete_experiment

  [DESTRUCTIVE] DESTRUCTIVE: deletes the experiment record (content keeps its labels). Ask the user before calling. (Wraps DELETE /api/v2/experiments/{id}.)

• get_experiment_results

  [read-only] The experiment's posts split by its compareKey, with the leading variant by its primary metric and n per arm. Small samples: read medians with their n. (Wraps GET /api/v2/experiments/{id}/results.)

• get_experiment_readout

  [read-only] n per arm, pooled reach engagement rate, a 90% interval and a hedged verdict (likely_winner, no_clear_winner or not_enough_data). Missing numbers are "not reported" (null), never 0. Say "likely", never "proven". (Wraps GET /api/v2/experiments/{id}/readout.)

• get_experiment_rounds

  [read-only] A version test's rounds: each closed round's frozen snapshot, the open round's live numbers (null = not reported), the winner if one was recorded, and any repeat-winner proposal. (Wraps GET /api/v2/experiments/{id}/rounds.)

• start_experiment_round

  [writes flayr data · `write` scope] Files the round's versions into the approval queue on the given platforms, in spaced slots with UTM links. Nothing posts until a person approves each one. Round 2 re-tests the arms kept from round 1. (Wraps POST /api/v2/experiments/{id}/rounds.

• close_experiment_round

  [writes flayr data · `write` scope] Freezes the open round's numbers and keeps the best arms for the next round. A winner is recorded only when the readout says likely_winner, or when `pick` names an arm the user chose. Ask the user before passing `pick`. (Wraps POST /api/v2/expe

• propose_repeat_winner

  [writes flayr data · `write` scope] Proposes slots to post the winning version again (default 3 over 2 weeks). Only a proposal: nothing is booked or posted until the user confirms it in flayr, and then each post still goes through approval. (Wraps POST /api/v2/experiments/{id}/re

• list_text_templates

  [read-only] Reusable text shapes per brand: sections, length targets, hook patterns, CTA slots and guardrails. Use one to shape a draft's text before create_content. (Wraps GET /api/v2/text-templates.)

• get_text_template

  [read-only] One format (text template) with its full structure and example. (Wraps GET /api/v2/text-templates/{id}.)

• create_text_template

  [writes flayr data · `write` scope] Creates a reusable format (text template) in a brand. (Wraps POST /api/v2/text-templates.)

• update_text_template

  [writes flayr data · `write` scope] Changes a format; only the fields you pass change. `archived: true` hides it. (Wraps PATCH /api/v2/text-templates/{id}.)

• delete_text_template

  [DESTRUCTIVE] DESTRUCTIVE: deletes a format (drafts started from it keep their text). Ask the user before calling. (Wraps DELETE /api/v2/text-templates/{id}.)

• list_attribution_rules

  [read-only] The brand's "posts like this must carry a credit" rules and its mode (flag / push_down). In push_down mode publish refuses or holds a post missing a required credit — add `credits` with update_content first. (Wraps GET /api/v2/attribution-rules.)

• list_share_rules

  [read-only] The brand's share rules: "when publishes, reshare to (or comment on it) after N minutes with text T", each with its approval mode. (Wraps GET /api/v2/automations/reshare-rules.)

• create_share_rule

  [PUBLISHES to social accounts · `publish` scope] Creates a rule that reshares (or comments on) every new post of the source accounts. Defaults to needs_approval: each fire waits for approve in act_on_publish_action. Only LinkedIn (native reshare) and X (quote own / retweet) reall

Basischecksi

Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 8. Nov. 2026

• ! Vorsicht

  Entwickler passt zum Repo

  Die Registry nennt kein Quell-Repo, deshalb können wir den Herausgeber (flayr.social) nicht dem Code zuordnen

• … Noch nicht geprüft

  Wird noch gepflegt

  Dieses Repo haben wir noch nicht von GitHub gelesen

• … Noch nicht geprüft

  Hat eine Lizenz

  Dieses Repo haben wir noch nicht von GitHub gelesen

• ✓ Bestanden

  Endpunkt antwortet

  Antwort in 335 ms (HTTP 200)

• – Nicht zutreffend

  Anmeldung mit OAuth

  Keine Anmeldung nötig

• ✓ Bestanden

  Keine versteckten Anweisungen in Tool-Beschreibungen

  Wir haben 60 Tool-Beschreibungen gelesen und keine versteckten Anweisungen an die KI gefunden

Im Vergleich mit anderen in Sonstigesi

• Mehr Sterne als 0 % der anderen 18437 Server in dieser Kategorie
• Neuer in der Registry veröffentlicht als 81 % der anderen 18437 Server in dieser Kategorie
• Basischecks gleich gut wie oder besser als bei 36 % der anderen 18437 Server in dieser Kategorie

Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.

Alternativen

Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.

So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti

README vom Entwickler

Keine README im Repo gefunden