# flayr Muse connector

From musedirectory.ai, the independent directory of Meta Muse connectors. Not affiliated with Meta.

## flayr

Create, schedule and publish social posts to 13 platforms for your brands.

- Record: https://musedirectory.ai/connector/flayr
- Category: Marketing & Ads
- Developer: flayr.social (https://flayr.social)
- Muse status: Extra setup. Not in Muse's Connectors list yet. Muse can still use it: its page gives you a request to paste into Muse.
- Health: Working, 361ms, checked 2026-10-30T05:56:20Z
- Endpoint: https://flayr.social/api/mcp
- Auth: No account needed; Pricing: unknown
- Screening: Screened, no issues found (2026-10-30T05:56:20Z)
- Source: Found in the official MCP Registry (social.flayr/flayr) https://registry.modelcontextprotocol.io/v0/servers?search=social.flayr%2Fflayr

Flayr connects to your social media accounts (Facebook, Instagram, TikTok, LinkedIn, YouTube, Pinterest, X, Bluesky, Threads and others) to let you draft posts with media, schedule them, set up posting queues, and track engagement metrics across all platforms.

Example request: "Schedule a video post to go out on Instagram, TikTok and YouTube next Tuesday at 7pm with different captions for each platform."

How to connect: Not in Muse's Connectors list yet, but Muse can still use it. Paste this into Muse: "Use flayr to help me. It is a free service with an MCP server at https://flayr.social/api/mcp. It does not need an API key. Ask me before you share anything with it." Muse asks before it shares anything with the app's site. Meta does not review apps used this way, so only use ones you trust. We tested this in the Muse app on September 24, 2026: Muse used an app's link directly this way and returned a live answer.

Tools:
- 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
- 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
- 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
- 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, or an API video generation): pending, processing, completed or failed. For a combine, `resultContentId` is the new draft once completed; a failed combine is refunded automatically. Poll every 10-30 s — renders take about a minute
- 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". Needs the explicit `appr
- 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_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:<key>, arm), at a fixed post age `window` (48h / 7d / 30d / lifetime) so posts are compa
- 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:<id>` plus `<compareKey>:<variant>`. (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:<id>) and `<compareKey>:<variant>` 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.)
- 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.)

Screening checks:
- MCP handshake: pass (Answered in 361ms)
- Domain against threat feeds (Cloudflare security DNS): pass (flayr.social not flagged)
- Published packages against the OSV malicious-package database: n/a (No npm or PyPI package published)
- Hidden instructions or invisible characters in tool text: pass (57 tools read, nothing found)
- Inputs asking for passwords, card numbers or seed phrases: pass (None found)
- Domain and redirects: pass (Domain registered 211 days ago)
- AI review of purpose and tool behavior: pass (No concerns)