Markaestroofficial
A
licenseA
qualityB
maintenanceSchedule, publish, and measure social posts on Facebook, Instagram, TikTok, LinkedIn, Threads, Pinterest, and X for one brand or many.
34
MIT
Broadcast
Server Details
Schedule and publish posts to X, LinkedIn, Instagram, Facebook, TikTok and Bluesky.
Ownership verified
- Status
- Healthy
- Uptime
- 98.4% over 24 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A4.6/5.0
Scored across 13 tools
Disambiguation5/5
The tools target clearly distinct resources and actions: creating, editing, deleting, validating, and inspecting posts; uploading media; and managing feeds. Descriptions explicitly clarify boundaries between closely related tools like schedule_post, update_post, cancel_post, get_schedule, and get_post.
Naming Consistency5/5
All tool names follow a consistent verb_noun convention, such as cancel_post, list_accounts, get_stats, upload_media, and validate_post. There are no mixed casing styles or vague standalone verbs.
Tool Count5/5
Thirteen tools are well scoped for a social publishing server with feed following, validation, media upload, scheduling, and analytics. Each tool covers a distinct operation and the set stays within a practical size.
Completeness4/5
The core lifecycle is well covered: accounts and feeds can be listed and managed, posts can be validated, scheduled, updated, cancelled, inspected, and analyzed. Minor gaps exist around media/account management, such as no tool to list or delete uploaded media, but these are not blocking for the primary workflow.
Available Tools
13 toolscancel_postCancel (delete) a postADestructiveInspect
Permanently deletes a post and its media (a file shared by several targets goes once, and one still used by another post is kept); this cannot be undone. Only use it when the user asks to drop a post; to change the text or date, use update_post instead. A post already published is removed from Broadcast only, not from the networks. Requires the delete scope.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the post to delete, from get_schedule or schedule_post. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and non-idempotent, so irreversibility alone would add little; the description goes further by explaining the shared-media lifecycle (a file used by several targets is deleted once, one still referenced elsewhere is kept) and the published-post limitation. It also discloses the required delete scope. The only gap is that it says nothing about the response or how failures surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the destructive action and the routing rule, and nearly every clause carries information an agent needs. The long parenthetical about shared media interrupts the sentence flow and makes the opening harder to parse on a single read, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool with no output schema, the description covers the things that matter: what gets destroyed, what is preserved, scope limitations for published posts, authorization requirements, and the correct alternative tool. An agent has everything needed to call it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both id and sourceUrl documented in the schema itself, including provenance for id and an explicit 'never invent one' instruction for sourceUrl. The description adds no parameter-level meaning of its own, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Permanently deletes a post and its media') and immediately scopes the behavior to media cleanup. It also names the sibling update_post and the boundary between them, so an agent can distinguish cancel_post from other post tools without reading schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the positive trigger ('Only use it when the user asks to drop a post') and routes the alternative case explicitly ('to change the text or date, use update_post instead'). The caveat that already-published posts are removed from Broadcast only, not from the networks, further clarifies when this tool does and does not achieve the user's goal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
follow_feedFollow an RSS feedAInspect
Follows an RSS or Atom feed (or a blog's address: its advertised feed is found). The articles it lists today are skipped; from now on each new article becomes a post for the given accounts, checked every 15 minutes. Posts wait for the user's approval unless autoPublish is true (publish scope; only when the user asked for it). TikTok cannot be a target. 10 feeds max.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Address of the RSS or Atom feed, or of the blog itself (its advertised feed is found). | |
| accounts | No | Account ids the feed's posts go to (see list_accounts). TikTok is not possible: its posts are set up by hand. | |
| platforms | No | Alternative to `accounts`: every connected account of these networks. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. | |
| autoPublish | No | false (default): each post waits for the user's approval in the app. true: posts are published right away, without approval (needs the publish scope); a post that breaks a network rule or lacks X credits still waits for approval. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (not read-only, not idempotent, not destructive, closed-world); the description goes well beyond that by disclosing the polling cadence, the skip-existing-articles rule, the approval queue by default, the publish-scope requirement for autoPublish, and the exception where rule-breaking or credit-lacking posts still wait for approval. These are exactly the operational facts an agent needs before invoking a recurring automation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action and the blog-address special case, then behavior, then constraints. Every clause carries information (skip rule, cadence, approval, TikTok exclusion, 10-feed cap) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers triggers, side effects, and limits thoroughly. The one gap is that it never says what the call returns (e.g. a feed identifier needed later by update_feed or unfollow_feed), which an agent managing the subscription lifecycle would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents url, accounts, platforms, sourceUrl, and autoPublish in detail. The description adds only the nuance that autoPublish requires the publish scope and should only be set when the user asked — useful but largely duplicative of the schema text, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (follows) plus resource (an RSS or Atom feed), with the extra scope that a bare blog address is accepted and its advertised feed resolved. It is immediately distinguishable from siblings like list_feeds, unfollow_feed, and update_feed, which manage existing subscriptions rather than create one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context: today's articles are skipped, polling happens every 15 minutes, and autoPublish should only be used when the user explicitly asked. It also states two hard constraints (TikTok not a valid target, 10 feeds maximum). It does not, however, point to an alternative tool (e.g. schedule_post for one-off publishing), which is the only missing piece for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_postGet one postARead-onlyIdempotentInspect
Returns one post by id with its per-network results: the media each target publishes (targets[].media, its own when ownMedia is true), status, link to the published post, the error when a network failed, and its numbers on the network (stats: views, likes, comments, shares; null until read or where the network shares none). Use it after publishing, or when get_schedule shows a post as partial or failed; use get_schedule instead to browse several posts.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post id, as returned by schedule_post or get_schedule. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, closed-world read, so the safety profile is covered. The description adds real value beyond that by describing the response shape: per-target media with the ownMedia flag, publish link, per-network error, and stats that are null until read or where a network shares none. It stops short of stating what happens for an unknown id (not-found behavior), which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well ordered: purpose first, then return contents, then routing guidance. The enumeration of response fields is long but each item carries information an agent would otherwise lack given there is no output schema. Slightly heavy for a single-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value semantics and it does, including the null-stats and failed-network cases. Combined with annotations covering safety and a fully documented id parameter, an agent has everything needed to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single id parameter is already documented as coming from schedule_post or get_schedule. The description adds no additional meaning about the id (format, prefix, scoping) beyond what the schema provides, so the baseline holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ("Returns one post by id") and immediately scopes it against the sibling: get_schedule is named as the tool for browsing several posts. An agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggering conditions ("after publishing, or when get_schedule shows a post as partial or failed") and names the alternative with the condition that selects it. Both the when and the when-not are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scheduleGet the scheduleARead-onlyIdempotentInspect
Lists posts with their status, date and targets (each target's media is what it publishes: its own when ownMedia, else the post's). Give from and to to read a date range (sorted by date), status to filter, or nothing for the 50 most recent posts. Read it before schedule_post to avoid duplicates and slots too close together. It does not return per-network results; use get_post for one post's links and errors.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only posts scheduled before this date-time. | |
| from | No | Only posts scheduled at or after this date-time. | |
| limit | No | Default 50. | |
| status | No | Only posts with this status. review = waiting for the user's approval; partial = published on some networks, failed on others. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower; the description nonetheless adds real behavioral context — default scope (50 most recent), ordering when a range is given, and the media/ownMedia resolution rule for targets. It also declares a scope limit (no per-network results/errors) that saves a wasted call, though it doesn't discuss pagination beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with what is returned, then how to parameterize it, then the workflow and exclusion notes. Every clause carries information; nothing is restated from the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so — status, date, targets, media resolution — plus what it does not return and which sibling to use instead. Nothing an agent needs to call this correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning: `from`/`to` together produce a date-sorted range, `status` is a filter, and omitting all parameters yields the 50 most recent rather than an empty result. That default-behavior explanation is the main thing the schema alone doesn't convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (lists posts) and immediately defines the returned shape — status, date, targets, with the `media`/`ownMedia` resolution rule spelled out. It explicitly distinguishes itself from two siblings (get_post, schedule_post), so an agent can pick it without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit invocation patterns: `from`+`to` for a date range sorted by date, `status` to filter, nothing for the 50 most recent. It also names a workflow prerequisite (read before schedule_post to avoid duplicates and slots too close together) and routes to get_post when per-network results are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsGet post statisticsARead-onlyIdempotentInspect
Returns how published posts did over a period (default: the last 30 days): totals, numbers per network (posts, views, likes, comments, shares, followers and their change), interactions per publication day and the best posts. Use it when the user asks what worked, which network or which post performed best, or to pick the next posts' topics and times; use get_post instead for one post's numbers (each target's stats). Numbers come from Bluesky, Mastodon, Facebook and Instagram (views too), read for 30 days after publication; X, LinkedIn, Threads, TikTok and YouTube are not read (available: false), so never compare them on these numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the period. Default: now. | |
| top | No | How many best posts to return (by interactions). Default 5. | |
| from | No | Start of the period: posts published at or after this date-time. Default: 30 days before `to`. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantive context beyond them: the source networks read (Bluesky, Mastodon, Facebook, Instagram with views), the 30-day post-publication read window, and critically that X, LinkedIn, Threads, TikTok and YouTube return available: false and must never be compared on these numbers. That is a behavioral constraint an agent could not infer from schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is appropriately sized and front-loaded — return contents first, then use cases, then data-source caveats. It is a single dense paragraph with a semicolon-chained clause list that could be slightly tightened, but every clause carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-value burden and does so by enumerating the metric groups and the best-posts list. Combined with the source-network caveat and the sibling routing, an agent has everything needed to call it and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: `from` and `to` document their defaults (now / 30 days before `to`) and `top` documents its by-interactions semantics and default of 5. The description restates the 30-day default period but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (published post performance) and enumerates exactly what is returned: totals, per-network numbers (posts, views, likes, comments, shares, followers and their change), interactions per publication day, and best posts. It explicitly distinguishes itself from the sibling get_post, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states concrete triggers — 'when the user asks what worked, which network or which post performed best, or to pick the next posts' topics and times' — and names the alternative with its selecting condition: 'use get_post instead for one post's numbers'. Both the when and the when-not are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsList connected accountsARead-onlyIdempotentInspect
Lists the social accounts connected to Broadcast (id, platform, handle). Call it first: schedule_post, validate_post and update_post take these ids (or the platform names) as targets, and a network missing here cannot be posted to until the user connects it in the app. When the user groups accounts in projects, each account has a project: a post's accounts must all come from one project, so pass account ids rather than platform names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context: accounts absent from this list cannot be targeted until the user connects them in the app. It does not discuss any caching or freshness of the returned account list, which is the one remaining behavioral unknown for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose before moving to ordering and the project constraint; each sentence earns its place. The final sentence is somewhat dense, packing the project-scoping rule and the id-vs-platform-name preference together, which slightly hurts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what comes back, and it does so by naming id, platform and handle plus the per-account `project` field. For a zero-parameter read tool, an agent has everything it needs to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is no parameter semantics to elaborate and the baseline applies. The description usefully spends its space on the implicit contract with downstream tools instead of restating a schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ("Lists the social accounts connected to Broadcast") and even names the returned fields (id, platform, handle). It distinguishes itself from the sibling tools by positioning itself as the prerequisite that schedule_post, validate_post and update_post depend on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit ordering guidance ("Call it first") and names the concrete downstream tools that consume the ids, which is exactly the when-to-use signal an agent needs. It also states the consequence of a missing network, so the agent knows when this call is required rather than optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_feedsList followed RSS feedsARead-onlyIdempotentInspect
Lists the RSS or Atom feeds Broadcast follows for the user: each new article becomes a post (its title, its link and the link's image) for the feed's accounts. Returns each feed's id, address, target accounts, whether its posts wait for approval (autoPublish false) and the last problem reading it. Call it to get the id that update_feed and unfollow_feed take, or before follow_feed to avoid following the same feed twice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing the return shape (id, address, target accounts, autoPublish flag, last read error) and the autoPublish semantics, which is meaningful context not present in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the resource and behavior, then the return fields, then the routing guidance. Slightly dense with parentheticals, but each sentence carries distinct load and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description must explain what comes back — and it does, listing every returned field and its meaning. Combined with the sibling-routing guidance, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is nothing to disambiguate and the description correctly omits parameter detail rather than inventing any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Lists') and resource ('RSS or Atom feeds Broadcast follows'), and further clarifies the causal model — each new article becomes a post for the feed's accounts. An agent can distinguish this from follow_feed/unfollow_feed/update_feed without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the downstream consumers and conditions: 'Call it to get the id that update_feed and unfollow_feed take, or before follow_feed to avoid following the same feed twice.' This states both when to call it and the concrete alternatives it feeds into.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schedule_postCreate or schedule a postAInspect
Creates a new post for one or more networks; to change a post that already exists, use update_post instead. Default status is "review": the post appears in the app with its date and waits for the user's approval before it is published. Status "scheduled" publishes automatically at scheduledAt, without approval (requires the publish scope); with scheduledAt "now" it goes out within a minute. Use "scheduled" only when the user explicitly asked to publish without approval; otherwise keep "review". X credits are checked before a scheduled post is accepted, and a scheduled TikTok post needs tiktok settings the user chose (otherwise keep it in review). repeat (day, week or month) makes it a recurring post: each time it goes out, the next occurrence is created with the same content at the same time; update_post with repeat null stops the series. Always pass an idempotencyKey (for instance the source item's id or a date-based slug) so a retried call does not create a duplicate. Returns the post, or the validation errors when a network rule is broken.
Network rules (the server enforces them on each target with its own text and media; use overrides for a shorter text on one network and mediaOverrides for other media there):
x: 280 chars (links count 23); Every link counts as 23 characters. Up to 4 images or 1 video.
bluesky: 300 chars; Up to 4 images or 1 video (50 MB max). Without media, the first link becomes a preview card.
facebook: 63206 chars; Published on the linked Facebook Page. Without media, the first link becomes a preview card.
instagram: 2200 chars; Media required, JPEG images and MP4 or MOV videos only: one image, one video (Reel), or a carousel of up to 20 images and videos, mixed. With instagramStory: true, published as a story instead: exactly one image or one video (60 s max), no caption, no replies, gone after 24 h. Links in the caption are not clickable.
tiktok: 2200 chars; Media required: one video or a set of images. Links are not clickable; hashtags are recognised. Status scheduled needs
tiktoksettings (privacy chosen by the user); without them use status review and the user picks them in Broadcast.linkedin: 3000 chars; Published on the linked personal profile. Up to 20 images or 1 video. Without media, the first link becomes an article card.
mastodon: 500 chars; Up to 4 images or 1 video.
youtube: 5000 chars; One video required, no images. The text becomes the description; the title is its first line (100 chars max). Published public, not made for kids, unless changed in Broadcast. Vertical videos of 3 min or less become Shorts.
threads: 500 chars; The 500 limit counts UTF-8 bytes: an accented letter takes 2, an emoji 4. Up to 20 images (JPEG or PNG) and videos (MP4 or MOV, 5 min max), mixed in a carousel, at most 5 links. Without media, the first link becomes a preview card. Only the first hashtag becomes a topic. Replies:
replies(optional) lists messages posted under the post right after it, from the same account, each{"text":"…","media":[…]}. On x, bluesky, threads and mastodon they form a thread (each one replies to the one before; 4 images or one video each, 20 mixed on threads; limits 280 on x with links at 23, 300 on bluesky, 500 on threads and mastodon). On linkedin, facebook and instagram only the first goes out, as a comment (text only; 1250 on linkedin), e.g. to keep a link out of a LinkedIn post. Up to 24. Each reply on X costs credits like a post. When a text is too long for X or Bluesky, put a short opening inoverrides.x(oroverrides.bluesky) and the rest inrepliesrather than cutting the message;noReplies: ["linkedin"]keeps the replies off a network (e.g. LinkedIn when it gets the whole text).xThreadandfirstCommentare older names for the same thing. Media per network:mediaOverridesworks likeoverrides(keyed by account id or platform, an account id wins) and replacesmediafor that target; a target without an entry getsmedia, an empty list sends the text alone. Upload each file once and reuse its key across targets. Alt text: give every image analt(a short factual description, in the post's language), either to upload_media or per media ref ({"key":"…","alt":"…"}, which wins); it is sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram. Example, one message as a vertical 9:16 video for TikTok, Instagram (Reel) and YouTube (Short) and a 4:5 carousel elsewhere:{"platforms":["tiktok","instagram","youtube","x","facebook","threads","bluesky","mastodon"],"media":[{"key":"<4:5 image 1>"},{"key":"<image 2>"},{"key":"<image 3>"},{"key":"<image 4>"}],"mediaOverrides":{"tiktok":[{"key":"<9:16 video>"}],"instagram":[{"key":"<9:16 video>"}],"youtube":[{"key":"<9:16 video>"}]}}(4 images at most because of x, bluesky and mastodon; give instagram, threads or facebook a longer carousel of their own). The X credit cost depends only on the text and link (and the number of replies). Dates are ISO 8601 with an offset; Europe/Paris is the user's time zone.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Main text of the post. Per-network overrides go in `overrides`; leave it as an empty string when every target has its own text there (never write quote marks as the text). | |
| link | No | Link appended after the text (becomes a preview card on Bluesky, Mastodon, Threads, Facebook and LinkedIn without media). | |
| media | No | Images (4 on x, bluesky and mastodon, 10 on facebook, 20 on instagram, threads and linkedin, 35 on tiktok) or one video, for every target without its own entry in `mediaOverrides`. Instagram and Threads also take a carousel of up to 20 images and videos, mixed. Instagram takes JPEG images and MP4 or MOV videos only. | |
| repeat | No | Publishes the post again every day, week or month at the same time (Europe/Paris), counted from scheduledAt: once an occurrence goes out, the next one is created with the same content. null stops the series. TikTok settings chosen in the app apply to every occurrence. | |
| status | No | draft: saved without a date. review (default when scheduledAt is set): waits for an approval in the app. scheduled: published automatically at scheduledAt, without approval (needs the publish scope); with scheduledAt "now" it goes out within a minute. | |
| tiktok | No | The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. While TikTok's audit of Broadcast is pending they are optional: the post goes out private (SELF_ONLY), interactions off. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true). | |
| replies | No | Replies Broadcast posts under the post right after it goes out, from the same account. On x, bluesky, threads and mastodon they form a thread: each one replies to the one before. On linkedin, facebook and instagram only the first one goes out, as a comment under the post (text only; e.g. the link, kept out of the post). None on tiktok, youtube or an instagram story. Up to 24. On X each reply costs credits like a post (10 with a link). If one fails, the post stays published, the replies carry on from that one on the automatic retries, and the target's `replies` says where they stopped. null or [] removes them. When the post's text is longer than a thread network takes, put its first part in `overrides` for that network and the rest in replies. Per network, `noReplies` turns them off. | |
| xThread | No | Deprecated: same as `replies` (ignored when `replies` is given). | |
| accounts | No | Target account ids (see GET /accounts / list_accounts). | |
| hashtags | No | Hashtags appended on their own line, with or without the leading #. | |
| noReplies | No | Account ids or platform names that get no replies (e.g. ["linkedin"] to keep the thread on x and bluesky only). On update_post it replaces the list; omit it to keep it. | |
| overrides | No | Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x). On update_post it replaces every override at once. | |
| platforms | No | Alternative to `accounts`: every connected account of these networks. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. | |
| scheduledAt | No | ISO 8601 date-time with offset (e.g. 2026-10-14T09:00:00+02:00), or "now". Required for status review and scheduled. | |
| firstComment | No | Deprecated: a single reply, same as `replies: [{ text }]` (ignored when `replies` is given). | |
| idempotencyKey | No | Client-chosen key: a retried call with the same key returns the post already created instead of a duplicate. | |
| instagramStory | No | true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no replies; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {"<id>": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`. | |
| mediaOverrides | No | Media replacing `media` for one network, keyed by account id or platform name like `overrides` (an account id wins over its platform): e.g. a vertical 9:16 video for tiktok, instagram and youtube, and a 4:5 carousel for the others in `media`. A target without an entry gets `media`; an empty list sends it no media. The same key may be used by several targets. Each target is validated with its own media. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare a non-read-only, non-destructive, non-idempotent, closed-world mutation; the description adds the real behavioral load: publish-scope requirement, approval-vs-automatic publishing, X credit charges and pre-checks, recurring-series propagation, partial-failure behavior for replies ('if one fails, the post stays published'), and the returned validation errors. The only tension is `openWorldHint: false` against a tool that publishes publicly to nine external networks, but the description itself makes the external side effects clearer than the annotation does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long, but front-loaded with the highest-stakes decision (review vs scheduled vs credits vs TikTok settings) before the reference material, and the network rules are bulleted for scanning. Some content is duplicated from the schema's own parameter descriptions (repeat semantics, mediaOverrides precedence, alt text), so not every sentence is strictly new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter, nested, multi-target mutation tool with no output schema, the description covers defaults, permissions, costs, error return shape ('Returns the post, or the validation errors'), idempotency guidance and the timezone/ISO-8601 requirement. Nothing an agent needs in order to call it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns more by explaining the semantics the schema cannot: per-network character and media limits enforced on each target, override/mediaOverrides precedence and empty-list meaning, reply threading vs comment behavior per network, alt-text propagation, and a worked cross-network example. It repeats some material already present verbatim in the schema (media/alt text, mediaOverrides precedence), which is why it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Creates a new post') scoped to 'one or more networks', then immediately distinguishes it from the sibling update_post ('to change a post that already exists, use update_post instead'). An agent can separate create from edit/get/cancel without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit decision rules: default to status 'review', use 'scheduled' only when the user explicitly asked to publish without approval, and keep TikTok in review unless the user supplied `tiktok` settings. It also names the alternative tool and the stop condition ('update_post with repeat null stops the series'), leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unfollow_feedUnfollow an RSS feedADestructiveInspect
Stops following a feed: no new post is made from its articles. Posts already made from it stay, scheduled ones included; cancel them with cancel_post if needed. To only change its accounts or approval, use update_feed instead. Requires the delete scope.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the feed to stop following, from list_feeds. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description supplies context annotations cannot express: what is destroyed is only future posting (existing posts persist, including scheduled ones, which need a separate cancel_post call) and the required delete scope. This is exactly the kind of side-effect and auth detail the highest bar asks for.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loading the core action and its effect before the alternative-tool routing and the scope requirement. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, single-required-param tool with no output schema, the description covers effect, persistence of past/scheduled posts, the cancellation path, the sibling alternative, and the auth scope — nothing an agent needs before calling it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'id' and the optional 'sourceUrl' are fully documented in the schema, and the description adds nothing about either. Baseline 3 is appropriate when the schema does all the parameter work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Stops following a feed') and immediately defines the observable consequence ('no new post is made from its articles'), which distinguishes it from update_feed and cancel_post by name. An agent can pick this tool without opening any other schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes to alternatives with conditions: cancel_post for already-scheduled posts, update_feed for account/approval changes only. It also states a prerequisite (delete scope), so both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_feedUpdate an RSS feedAInspect
Changes the target accounts of a feed already followed, or whether its posts are published without approval (autoPublish, publish scope; only when the user asked for it). Only the fields given change; posts already made from the feed are not touched. Use it instead of unfollowing and following again, which would skip the articles already listed in the feed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the feed, from list_feeds or follow_feed. | |
| accounts | No | Account ids the feed's posts go to (see list_accounts). TikTok is not possible: its posts are set up by hand. | |
| platforms | No | Alternative to `accounts`: every connected account of these networks. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. | |
| autoPublish | No | false (default): each post waits for the user's approval in the app. true: posts are published right away, without approval (needs the publish scope); a post that breaks a network rule or lacks X credits still waits for approval. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (not read-only, not destructive, not idempotent); the description adds real semantics beyond them — partial update ('Only the fields given change'), no retroactive effect on existing posts, and the publish-scope requirement for autoPublish. It stops short of describing failure modes or the response, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with zero filler: what changes, what is left alone, and which sibling to avoid. The parenthetical scope note is dense but earns its place by preventing an unauthorized autoPublish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with full schema coverage and no output schema, the description covers purpose, partial-update behavior, side-effect scope, and alternative routing. Only minor operational details (e.g. behavior on invalid account ids) are absent, which the schema largely covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so id, accounts, platforms, sourceUrl and autoPublish are already documented in the schema. The description reinforces accounts and autoPublish (including the publish-scope dependency) but adds no syntax or format detail beyond what the schema already provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (changes) and resource (a feed already followed) and names the exact fields affected: target accounts and autoPublish behavior. It is clearly separable from sibling follow_feed/unfollow_feed, which it explicitly contrasts itself against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing rule: 'Use it instead of unfollowing and following again, which would skip the articles already listed in the feed.' It also gates autoPublish with 'only when the user asked for it', so the agent knows both when to pick this tool and when to enable the risky option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_postUpdate a postAInspect
Edits a draft, review or scheduled post: text, link, hashtags, replies, media, media per network, targets, date or status. Only the fields given are changed; overrides and mediaOverrides are each replaced as a whole when given (pass every entry to keep), kept when omitted. Use it instead of schedule_post to fix or reschedule an existing post (no duplicate is created), and instead of cancel_post when the post should still go out. Setting status "scheduled" publishes without approval and needs the publish scope, so only do it when the user asked. A published post cannot be edited.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the post to edit, from get_schedule or schedule_post. | |
| body | No | Main text of the post. Per-network overrides go in `overrides`; leave it as an empty string when every target has its own text there (never write quote marks as the text). | |
| link | No | Link appended after the text (becomes a preview card on Bluesky, Mastodon, Threads, Facebook and LinkedIn without media). | |
| media | No | Images (4 on x, bluesky and mastodon, 10 on facebook, 20 on instagram, threads and linkedin, 35 on tiktok) or one video, for every target without its own entry in `mediaOverrides`. Instagram and Threads also take a carousel of up to 20 images and videos, mixed. Instagram takes JPEG images and MP4 or MOV videos only. | |
| repeat | No | Publishes the post again every day, week or month at the same time (Europe/Paris), counted from scheduledAt: once an occurrence goes out, the next one is created with the same content. null stops the series. TikTok settings chosen in the app apply to every occurrence. | |
| status | No | draft: saved without a date. review (default when scheduledAt is set): waits for an approval in the app. scheduled: published automatically at scheduledAt, without approval (needs the publish scope); with scheduledAt "now" it goes out within a minute. | |
| tiktok | No | The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. While TikTok's audit of Broadcast is pending they are optional: the post goes out private (SELF_ONLY), interactions off. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true). | |
| replies | No | Replies Broadcast posts under the post right after it goes out, from the same account. On x, bluesky, threads and mastodon they form a thread: each one replies to the one before. On linkedin, facebook and instagram only the first one goes out, as a comment under the post (text only; e.g. the link, kept out of the post). None on tiktok, youtube or an instagram story. Up to 24. On X each reply costs credits like a post (10 with a link). If one fails, the post stays published, the replies carry on from that one on the automatic retries, and the target's `replies` says where they stopped. null or [] removes them. When the post's text is longer than a thread network takes, put its first part in `overrides` for that network and the rest in replies. Per network, `noReplies` turns them off. | |
| xThread | No | Deprecated: same as `replies` (ignored when `replies` is given). | |
| accounts | No | Target account ids (see GET /accounts / list_accounts). | |
| hashtags | No | Hashtags appended on their own line, with or without the leading #. | |
| noReplies | No | Account ids or platform names that get no replies (e.g. ["linkedin"] to keep the thread on x and bluesky only). On update_post it replaces the list; omit it to keep it. | |
| overrides | No | Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x). On update_post it replaces every override at once. | |
| platforms | No | Alternative to `accounts`: every connected account of these networks. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. | |
| scheduledAt | No | ISO 8601 date-time with offset (e.g. 2026-10-14T09:00:00+02:00), or "now". Required for status review and scheduled. | |
| firstComment | No | Deprecated: a single reply, same as `replies: [{ text }]` (ignored when `replies` is given). | |
| instagramStory | No | true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no replies; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {"<id>": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`. | |
| mediaOverrides | No | Replaces every per-network media list at once, like `overrides`: a target left out goes back to `media`; {} removes them all. Omit it to keep them. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give the generic safety profile (not read-only, not idempotent, not destructive), so the description carries the real behavioral load and does: it discloses PATCH-style partial updates vs. whole-list replacement for `overrides`/`mediaOverrides`, that omitted collections are kept, that publishing via "scheduled" bypasses approval and requires the publish scope, and that published posts are immutable. These are non-obvious state and permission consequences beyond anything in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose then the update contract then routing and the dangerous-path caution. The field enumeration is long but functional, and every clause either routes the agent or prevents a specific mistake; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter mutation tool with no output schema and nested objects, the description covers the highest-risk behaviors — partial update semantics, duplicate avoidance, and the scope-gated publish path. It does not itself explain the per-network specifics (tiktok settings, instagramStory, repeat), but those are fully described in the schema, so the remaining gap is small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds semantics the schema does not: the update contract ("only the fields given are changed", overrides replaced wholesale when given, kept when omitted — with the concrete instruction to pass every entry to keep). That is exactly the operational meaning an agent needs to avoid accidentally wiping per-network overrides on a partial edit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (edits) plus the resource (an existing post) and enumerates the editable surfaces: text, link, hashtags, replies, media, media per network, targets, date, status. It also scopes the tool to three states (draft, review, scheduled) and explicitly says a published post cannot be edited, so an agent can distinguish it from schedule_post and cancel_post without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names both alternatives and the condition that selects each: use instead of schedule_post to fix or reschedule without creating a duplicate, and instead of cancel_post when the post should still go out. It further gated the risky path (status "scheduled" publishes without approval, needs publish scope, only when the user asked), which is exactly the when/when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_mediaUpload media from a URLAInspect
Copies a public image (JPEG, PNG, WebP, GIF; 10 MB max) or video (MP4, MOV, WebM; 100 MB max) into Broadcast and returns its key. Give an image its alt text here: posts using the key send it. Call it before schedule_post or update_post whenever the post has media, then pass the key in media; a plain URL is not accepted there. Required for Instagram and TikTok, which refuse text-only posts.
| Name | Required | Description | Default |
|---|---|---|---|
| alt | No | Alternative text describing the image for people who cannot see it. Kept with the file: every post using this key without its own `alt` sends it (bluesky, mastodon, x, linkedin, threads, facebook, instagram). | |
| url | Yes | Public URL of an image (JPEG, PNG, WebP, GIF, 10 MB max) or video (MP4, MOV, WebM, 100 MB max) to copy into Broadcast. | |
| sourceUrl | No | Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-idempotent, non-destructive mutation; the description adds real behavioral context beyond that: the URL is copied into Broadcast, the response carries a `key`, the key is what later calls accept, and alt text persists with the file. It does not say what happens on failure (unsupported host, oversized file) or whether re-uploading the same URL creates a duplicate, which matters given idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the action and limits before the workflow rules, with no filler. The format/size list slightly duplicates the `url` schema description, a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description states the return value (`key`), the workflow position among siblings, and the platform-level requirement that motivates it. Combined with a fully documented schema, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds cross-field meaning: `alt` is stored with the file and inherited by posts using the key, and `url` is a copy source rather than a reference. `sourceUrl` is left entirely to the schema, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Copies a public image ... or video ... into Broadcast') and even the return value ('returns its `key`'), with concrete format and size bounds. It is clearly distinguishable from siblings like schedule_post and update_post, which it names as downstream consumers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing ('Call it before schedule_post or update_post whenever the post has media'), a hard exclusion ('a plain URL is not accepted there'), and a platform precondition ('Required for Instagram and TikTok, which refuse text-only posts'). An agent has no inference left to make about when to call this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_postValidate a postARead-onlyIdempotentInspect
Checks a post against every target network without creating anything: returns errors (blocking, per target: each one is checked with its own text and media), warnings and, per target, the exact text with its length and the media it would publish. Call it before schedule_post when unsure whether a text, link or media fits every network; schedule_post runs the same checks and refuses an invalid post, but validate_post lets you fix it first with no side effect.
Network rules (the server enforces them on each target with its own text and media; use overrides for a shorter text on one network and mediaOverrides for other media there):
x: 280 chars (links count 23); Every link counts as 23 characters. Up to 4 images or 1 video.
bluesky: 300 chars; Up to 4 images or 1 video (50 MB max). Without media, the first link becomes a preview card.
facebook: 63206 chars; Published on the linked Facebook Page. Without media, the first link becomes a preview card.
instagram: 2200 chars; Media required, JPEG images and MP4 or MOV videos only: one image, one video (Reel), or a carousel of up to 20 images and videos, mixed. With instagramStory: true, published as a story instead: exactly one image or one video (60 s max), no caption, no replies, gone after 24 h. Links in the caption are not clickable.
tiktok: 2200 chars; Media required: one video or a set of images. Links are not clickable; hashtags are recognised. Status scheduled needs
tiktoksettings (privacy chosen by the user); without them use status review and the user picks them in Broadcast.linkedin: 3000 chars; Published on the linked personal profile. Up to 20 images or 1 video. Without media, the first link becomes an article card.
mastodon: 500 chars; Up to 4 images or 1 video.
youtube: 5000 chars; One video required, no images. The text becomes the description; the title is its first line (100 chars max). Published public, not made for kids, unless changed in Broadcast. Vertical videos of 3 min or less become Shorts.
threads: 500 chars; The 500 limit counts UTF-8 bytes: an accented letter takes 2, an emoji 4. Up to 20 images (JPEG or PNG) and videos (MP4 or MOV, 5 min max), mixed in a carousel, at most 5 links. Without media, the first link becomes a preview card. Only the first hashtag becomes a topic. Replies:
replies(optional) lists messages posted under the post right after it, from the same account, each{"text":"…","media":[…]}. On x, bluesky, threads and mastodon they form a thread (each one replies to the one before; 4 images or one video each, 20 mixed on threads; limits 280 on x with links at 23, 300 on bluesky, 500 on threads and mastodon). On linkedin, facebook and instagram only the first goes out, as a comment (text only; 1250 on linkedin), e.g. to keep a link out of a LinkedIn post. Up to 24. Each reply on X costs credits like a post. When a text is too long for X or Bluesky, put a short opening inoverrides.x(oroverrides.bluesky) and the rest inrepliesrather than cutting the message;noReplies: ["linkedin"]keeps the replies off a network (e.g. LinkedIn when it gets the whole text).xThreadandfirstCommentare older names for the same thing. Media per network:mediaOverridesworks likeoverrides(keyed by account id or platform, an account id wins) and replacesmediafor that target; a target without an entry getsmedia, an empty list sends the text alone. Upload each file once and reuse its key across targets. Alt text: give every image analt(a short factual description, in the post's language), either to upload_media or per media ref ({"key":"…","alt":"…"}, which wins); it is sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram. Example, one message as a vertical 9:16 video for TikTok, Instagram (Reel) and YouTube (Short) and a 4:5 carousel elsewhere:{"platforms":["tiktok","instagram","youtube","x","facebook","threads","bluesky","mastodon"],"media":[{"key":"<4:5 image 1>"},{"key":"<image 2>"},{"key":"<image 3>"},{"key":"<image 4>"}],"mediaOverrides":{"tiktok":[{"key":"<9:16 video>"}],"instagram":[{"key":"<9:16 video>"}],"youtube":[{"key":"<9:16 video>"}]}}(4 images at most because of x, bluesky and mastodon; give instagram, threads or facebook a longer carousel of their own). The X credit cost depends only on the text and link (and the number of replies). Dates are ISO 8601 with an offset; Europe/Paris is the user's time zone.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Main text of the post. Per-network overrides go in `overrides`; leave it as an empty string when every target has its own text there (never write quote marks as the text). | |
| link | No | Link appended after the text (becomes a preview card on Bluesky, Mastodon, Threads, Facebook and LinkedIn without media). | |
| media | No | Images (4 on x, bluesky and mastodon, 10 on facebook, 20 on instagram, threads and linkedin, 35 on tiktok) or one video, for every target without its own entry in `mediaOverrides`. Instagram and Threads also take a carousel of up to 20 images and videos, mixed. Instagram takes JPEG images and MP4 or MOV videos only. | |
| repeat | No | Publishes the post again every day, week or month at the same time (Europe/Paris), counted from scheduledAt: once an occurrence goes out, the next one is created with the same content. null stops the series. TikTok settings chosen in the app apply to every occurrence. | |
| status | No | draft: saved without a date. review (default when scheduledAt is set): waits for an approval in the app. scheduled: published automatically at scheduledAt, without approval (needs the publish scope); with scheduledAt "now" it goes out within a minute. | |
| tiktok | No | The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. While TikTok's audit of Broadcast is pending they are optional: the post goes out private (SELF_ONLY), interactions off. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true). | |
| replies | No | Replies Broadcast posts under the post right after it goes out, from the same account. On x, bluesky, threads and mastodon they form a thread: each one replies to the one before. On linkedin, facebook and instagram only the first one goes out, as a comment under the post (text only; e.g. the link, kept out of the post). None on tiktok, youtube or an instagram story. Up to 24. On X each reply costs credits like a post (10 with a link). If one fails, the post stays published, the replies carry on from that one on the automatic retries, and the target's `replies` says where they stopped. null or [] removes them. When the post's text is longer than a thread network takes, put its first part in `overrides` for that network and the rest in replies. Per network, `noReplies` turns them off. | |
| xThread | No | Deprecated: same as `replies` (ignored when `replies` is given). | |
| accounts | No | Target account ids (see GET /accounts / list_accounts). | |
| hashtags | No | Hashtags appended on their own line, with or without the leading #. | |
| noReplies | No | Account ids or platform names that get no replies (e.g. ["linkedin"] to keep the thread on x and bluesky only). On update_post it replaces the list; omit it to keep it. | |
| overrides | No | Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x). On update_post it replaces every override at once. | |
| platforms | No | Alternative to `accounts`: every connected account of these networks. | |
| scheduledAt | No | ISO 8601 date-time with offset (e.g. 2026-10-14T09:00:00+02:00), or "now". Required for status review and scheduled. | |
| firstComment | No | Deprecated: a single reply, same as `replies: [{ text }]` (ignored when `replies` is given). | |
| idempotencyKey | No | Client-chosen key: a retried call with the same key returns the post already created instead of a duplicate. | |
| instagramStory | No | true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no replies; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {"<id>": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`. | |
| mediaOverrides | No | Media replacing `media` for one network, keyed by account id or platform name like `overrides` (an account id wins over its platform): e.g. a vertical 9:16 video for tiktok, instagram and youtube, and a 4:5 carousel for the others in `media`. A target without an entry gets `media`; an empty list sends it no media. The same key may be used by several targets. Each target is validated with its own media. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description reinforces them with 'without creating anything' / 'no side effect' rather than contradicting them. It goes further by describing the response shape (blocking errors per target, warnings, resolved text with length and media) — valuable since there is no output schema. The deduction is for the bulk of the remaining text being per-network publishing rules rather than validation behaviour (e.g. how warnings are ordered, whether partial failures are reported).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the schedule_post comparison are correctly front-loaded, but the body is a 600+ word wall of per-network rules, alt-text policy, credit cost and date-format advice, much of which is irrelevant to a non-creating validation call (dates are ISO 8601 with an offset; Europe/Paris is the user's time zone). The network rules could be compressed to the constraint that actually triggers an error, and the flat prose block has no scannable structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with nested objects, no annotations about returns and no output schema, this is complete: it explains what success and failure output look like, covers the per-network limits that determine validity, and documents the override/override-precedence mechanics an agent must get right before calling it. An agent has everything required to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for 18 parameters, so the baseline is 3; the description still adds cross-parameter meaning the schema cannot express: overrides are for 'a shorter text on one network', mediaOverrides substitutes media per target with 'an account id wins' over its platform, noReplies ['linkedin'] keeps replies off a network, and the long-text guidance on splitting into overrides + replies. The worked example showing one video for TikTok/Instagram/YouTube and a carousel elsewhere is genuinely instructive. It stops short of stating which parameters are ignored in validation (e.g. scheduledAt, repeat, tiktok, status, idempotencyKey all appear irrelevant to a dry run but are neither flagged nor excluded).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource with scope: 'Checks a post against every target network without creating anything', and immediately enumerates what comes back (blocking errors, warnings, and per-target text, length and media). It is clearly distinguished from the sibling schedule_post, so an agent can pick between them without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing advice: 'Call it before schedule_post when unsure whether a text, link or media fits every network', plus the reason schedule_post is not a substitute ('runs the same checks and refuses an invalid post, but validate_post lets you fix it first with no side effect'). That is a when-to-use, a when-to-use-the-alternative, and the trade-off in one place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
schedule_post5 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, mastodon, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 500 on threads and mastodon, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Deprecated: a single reply, same as `replies: [{ text }]` (ignored when `replies` is given)." - changed
Input schema / properties / instagramStory / descriptionPrevious value: -"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`."New value: +"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no replies; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`." - added
Input schema / properties / noRepliesAdded value: +{ + "description": "Account ids or platform names that get no replies (e.g. [\"linkedin\"] to keep the thread on x and bluesky only). On update_post it replaces the list; omit it to keep it.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / repliesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "media": { + "description": "This reply's own media: 4 images or one video (a carousel of 20 images and videos on threads). Only sent in threads: a comment goes without its media.", + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 20, + "type": "array" + }, + "text": { + "description": "The reply's text. Limits as each network counts them: 280 on x (a link counts 23), 300 on bluesky, 500 on threads and mastodon, 1250 on linkedin, 2200 on instagram, 8000 on facebook.", + "maxLength": 8000, + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + "maxItems": 24, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Replies Broadcast posts under the post right after it goes out, from the same account. On x, bluesky, threads and mastodon they form a thread: each one replies to the one before. On linkedin, facebook and instagram only the first one goes out, as a comment under the post (text only; e.g. the link, kept out of the post). None on tiktok, youtube or an instagram story. Up to 24. On X each reply costs credits like a post (10 with a link). If one fails, the post stays published, the replies carry on from that one on the automatic retries, and the target's `replies` says where they stopped. null or [] removes them. When the post's text is longer than a thread network takes, put its first part in `overrides` for that network and the rest in replies. Per network, `noReplies` turns them off." +} - added
Input schema / properties / xThreadAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "media": { + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 4, + "type": "array" + }, + "text": { + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + "maxItems": 24, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Deprecated: same as `replies` (ignored when `replies` is given)." +}
- Changed
update_post5 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, mastodon, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 500 on threads and mastodon, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Deprecated: a single reply, same as `replies: [{ text }]` (ignored when `replies` is given)." - changed
Input schema / properties / instagramStory / descriptionPrevious value: -"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`."New value: +"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no replies; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`." - added
Input schema / properties / noRepliesAdded value: +{ + "description": "Account ids or platform names that get no replies (e.g. [\"linkedin\"] to keep the thread on x and bluesky only). On update_post it replaces the list; omit it to keep it.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / repliesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "media": { + "description": "This reply's own media: 4 images or one video (a carousel of 20 images and videos on threads). Only sent in threads: a comment goes without its media.", + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 20, + "type": "array" + }, + "text": { + "description": "The reply's text. Limits as each network counts them: 280 on x (a link counts 23), 300 on bluesky, 500 on threads and mastodon, 1250 on linkedin, 2200 on instagram, 8000 on facebook.", + "maxLength": 8000, + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + "maxItems": 24, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Replies Broadcast posts under the post right after it goes out, from the same account. On x, bluesky, threads and mastodon they form a thread: each one replies to the one before. On linkedin, facebook and instagram only the first one goes out, as a comment under the post (text only; e.g. the link, kept out of the post). None on tiktok, youtube or an instagram story. Up to 24. On X each reply costs credits like a post (10 with a link). If one fails, the post stays published, the replies carry on from that one on the automatic retries, and the target's `replies` says where they stopped. null or [] removes them. When the post's text is longer than a thread network takes, put its first part in `overrides` for that network and the rest in replies. Per network, `noReplies` turns them off." +} - added
Input schema / properties / xThreadAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "media": { + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 4, + "type": "array" + }, + "text": { + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + "maxItems": 24, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Deprecated: same as `replies` (ignored when `replies` is given)." +}
- Changed
validate_post5 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, mastodon, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 500 on threads and mastodon, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Deprecated: a single reply, same as `replies: [{ text }]` (ignored when `replies` is given)." - changed
Input schema / properties / instagramStory / descriptionPrevious value: -"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`."New value: +"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no replies; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`." - added
Input schema / properties / noRepliesAdded value: +{ + "description": "Account ids or platform names that get no replies (e.g. [\"linkedin\"] to keep the thread on x and bluesky only). On update_post it replaces the list; omit it to keep it.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / repliesAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "media": { + "description": "This reply's own media: 4 images or one video (a carousel of 20 images and videos on threads). Only sent in threads: a comment goes without its media.", + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 20, + "type": "array" + }, + "text": { + "description": "The reply's text. Limits as each network counts them: 280 on x (a link counts 23), 300 on bluesky, 500 on threads and mastodon, 1250 on linkedin, 2200 on instagram, 8000 on facebook.", + "maxLength": 8000, + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + "maxItems": 24, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Replies Broadcast posts under the post right after it goes out, from the same account. On x, bluesky, threads and mastodon they form a thread: each one replies to the one before. On linkedin, facebook and instagram only the first one goes out, as a comment under the post (text only; e.g. the link, kept out of the post). None on tiktok, youtube or an instagram story. Up to 24. On X each reply costs credits like a post (10 with a link). If one fails, the post stays published, the replies carry on from that one on the automatic retries, and the target's `replies` says where they stopped. null or [] removes them. When the post's text is longer than a thread network takes, put its first part in `overrides` for that network and the rest in replies. Per network, `noReplies` turns them off." +} - added
Input schema / properties / xThreadAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "media": { + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 4, + "type": "array" + }, + "text": { + "maxLength": 1000, + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + "maxItems": 24, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Deprecated: same as `replies` (ignored when `replies` is given)." +}
4 tool updates
- Changed
schedule_post2 fields changed- changed
Input schema / properties / media / items / properties / alt / descriptionPrevious value: -"Alternative text for images."New value: +"Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`." - changed
Input schema / properties / mediaOverrides / additionalProperties / items / properties / alt / descriptionPrevious value: -"Alternative text for images."New value: +"Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`."
- Changed
update_post2 fields changed- changed
Input schema / properties / media / items / properties / alt / descriptionPrevious value: -"Alternative text for images."New value: +"Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`." - changed
Input schema / properties / mediaOverrides / additionalProperties / items / properties / alt / descriptionPrevious value: -"Alternative text for images."New value: +"Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`."
- Changed
upload_media1 field changed- changed
Input schema / properties / alt / descriptionPrevious value: -"Alternative text for an image, read by screen readers on the networks that support it."New value: +"Alternative text describing the image for people who cannot see it. Kept with the file: every post using this key without its own `alt` sends it (bluesky, mastodon, x, linkedin, threads, facebook, instagram)."
- Changed
validate_post2 fields changed- changed
Input schema / properties / media / items / properties / alt / descriptionPrevious value: -"Alternative text for images."New value: +"Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`." - changed
Input schema / properties / mediaOverrides / additionalProperties / items / properties / alt / descriptionPrevious value: -"Alternative text for images."New value: +"Alternative text describing the image for people who cannot see it (what it shows, in the post's language; no \"image of\"). Sent on bluesky, mastodon, x, linkedin, threads, facebook and instagram (not on instagram stories, reels or videos); ignored elsewhere. Omitted: the alt given to upload_media for this key. May differ per network in `mediaOverrides`."
3 tool updates
- Changed
schedule_post6 fields changed- added
Input schema / properties / instagramStory / anyOfAdded value: +[ + { + "type": "boolean" + }, + { + "additionalProperties": { + "type": "boolean" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } +] - changed
Input schema / properties / instagramStory / descriptionPrevious value: -"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Default false."New value: +"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`." - removed
Input schema / properties / instagramStory / typeRemoved value: -"boolean" - changed
Input schema / properties / media / descriptionPrevious value: -"Images (up to 10 for most networks, 20 on Instagram, Threads and LinkedIn) or one video. Instagram and Threads also take a carousel of up to 20 images and videos, mixed: then target only them. Instagram takes JPEG images and MP4 or MOV videos only."New value: +"Images (4 on x, bluesky and mastodon, 10 on facebook, 20 on instagram, threads and linkedin, 35 on tiktok) or one video, for every target without its own entry in `mediaOverrides`. Instagram and Threads also take a carousel of up to 20 images and videos, mixed. Instagram takes JPEG images and MP4 or MOV videos only." - added
Input schema / properties / mediaOverridesAdded value: +{ + "additionalProperties": { + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text for images.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 35, + "type": "array" + }, + "description": "Media replacing `media` for one network, keyed by account id or platform name like `overrides` (an account id wins over its platform): e.g. a vertical 9:16 video for tiktok, instagram and youtube, and a 4:5 carousel for the others in `media`. A target without an entry gets `media`; an empty list sends it no media. The same key may be used by several targets. Each target is validated with its own media.", + "propertyNames": { + "type": "string" + }, + "type": "object" +} - changed
Input schema / properties / overrides / descriptionPrevious value: -"Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x)."New value: +"Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x). On update_post it replaces every override at once."
- Changed
update_post6 fields changed- added
Input schema / properties / instagramStory / anyOfAdded value: +[ + { + "type": "boolean" + }, + { + "additionalProperties": { + "type": "boolean" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } +] - changed
Input schema / properties / instagramStory / descriptionPrevious value: -"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Default false."New value: +"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`." - removed
Input schema / properties / instagramStory / typeRemoved value: -"boolean" - changed
Input schema / properties / media / descriptionPrevious value: -"Images (up to 10 for most networks, 20 on Instagram, Threads and LinkedIn) or one video. Instagram and Threads also take a carousel of up to 20 images and videos, mixed: then target only them. Instagram takes JPEG images and MP4 or MOV videos only."New value: +"Images (4 on x, bluesky and mastodon, 10 on facebook, 20 on instagram, threads and linkedin, 35 on tiktok) or one video, for every target without its own entry in `mediaOverrides`. Instagram and Threads also take a carousel of up to 20 images and videos, mixed. Instagram takes JPEG images and MP4 or MOV videos only." - added
Input schema / properties / mediaOverridesAdded value: +{ + "additionalProperties": { + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text for images.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 35, + "type": "array" + }, + "description": "Replaces every per-network media list at once, like `overrides`: a target left out goes back to `media`; {} removes them all. Omit it to keep them.", + "propertyNames": { + "type": "string" + }, + "type": "object" +} - changed
Input schema / properties / overrides / descriptionPrevious value: -"Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x)."New value: +"Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x). On update_post it replaces every override at once."
- Changed
validate_post6 fields changed- added
Input schema / properties / instagramStory / anyOfAdded value: +[ + { + "type": "boolean" + }, + { + "additionalProperties": { + "type": "boolean" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } +] - changed
Input schema / properties / instagramStory / descriptionPrevious value: -"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Default false."New value: +"true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Or per Instagram account: an object keyed by account id (e.g. {\"<id>\": true}), the accounts left out staying posts. Default false. A story takes the target's own media when it has some in `mediaOverrides`." - removed
Input schema / properties / instagramStory / typeRemoved value: -"boolean" - changed
Input schema / properties / media / descriptionPrevious value: -"Images (up to 10 for most networks, 20 on Instagram, Threads and LinkedIn) or one video. Instagram and Threads also take a carousel of up to 20 images and videos, mixed: then target only them. Instagram takes JPEG images and MP4 or MOV videos only."New value: +"Images (4 on x, bluesky and mastodon, 10 on facebook, 20 on instagram, threads and linkedin, 35 on tiktok) or one video, for every target without its own entry in `mediaOverrides`. Instagram and Threads also take a carousel of up to 20 images and videos, mixed. Instagram takes JPEG images and MP4 or MOV videos only." - added
Input schema / properties / mediaOverridesAdded value: +{ + "additionalProperties": { + "items": { + "additionalProperties": false, + "properties": { + "alt": { + "description": "Alternative text for images.", + "maxLength": 1000, + "type": "string" + }, + "key": { + "description": "Media key returned by POST /media (or the upload_media tool).", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 35, + "type": "array" + }, + "description": "Media replacing `media` for one network, keyed by account id or platform name like `overrides` (an account id wins over its platform): e.g. a vertical 9:16 video for tiktok, instagram and youtube, and a 4:5 carousel for the others in `media`. A target without an entry gets `media`; an empty list sends it no media. The same key may be used by several targets. Each target is validated with its own media.", + "propertyNames": { + "type": "string" + }, + "type": "object" +} - changed
Input schema / properties / overrides / descriptionPrevious value: -"Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x)."New value: +"Text replacing `body` for one network, keyed by account id or platform name (e.g. a shorter text for x). On update_post it replaces every override at once."
3 tool updates
- Changed
schedule_post2 fields changed- changed
Input schema / properties / tiktok / descriptionPrevious value: -"The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true)."New value: +"The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. While TikTok's audit of Broadcast is pending they are optional: the post goes out private (SELF_ONLY), interactions off. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true)." - changed
Input schema / properties / tiktok / properties / privacy / descriptionPrevious value: -"Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know."New value: +"Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know. Until TikTok approves Broadcast (audit pending), every TikTok post is published as SELF_ONLY whatever is sent here: tell the user."
- Changed
update_post2 fields changed- changed
Input schema / properties / tiktok / descriptionPrevious value: -"The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true)."New value: +"The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. While TikTok's audit of Broadcast is pending they are optional: the post goes out private (SELF_ONLY), interactions off. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true)." - changed
Input schema / properties / tiktok / properties / privacy / descriptionPrevious value: -"Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know."New value: +"Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know. Until TikTok approves Broadcast (audit pending), every TikTok post is published as SELF_ONLY whatever is sent here: tell the user."
- Changed
validate_post2 fields changed- changed
Input schema / properties / tiktok / descriptionPrevious value: -"The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true)."New value: +"The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. While TikTok's audit of Broadcast is pending they are optional: the post goes out private (SELF_ONLY), interactions off. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true)." - changed
Input schema / properties / tiktok / properties / privacy / descriptionPrevious value: -"Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know."New value: +"Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know. Until TikTok approves Broadcast (audit pending), every TikTok post is published as SELF_ONLY whatever is sent here: tell the user."
3 tool updates
- Changed
schedule_post1 field changed- changed
Input schema / properties / body / descriptionPrevious value: -"Main text of the post. Per-network overrides go in `overrides`; it may be empty (\"\") when every target has an override."New value: +"Main text of the post. Per-network overrides go in `overrides`; leave it as an empty string when every target has its own text there (never write quote marks as the text)."
- Changed
update_post1 field changed- changed
Input schema / properties / body / descriptionPrevious value: -"Main text of the post. Per-network overrides go in `overrides`; it may be empty (\"\") when every target has an override."New value: +"Main text of the post. Per-network overrides go in `overrides`; leave it as an empty string when every target has its own text there (never write quote marks as the text)."
- Changed
validate_post1 field changed- changed
Input schema / properties / body / descriptionPrevious value: -"Main text of the post. Per-network overrides go in `overrides`; it may be empty (\"\") when every target has an override."New value: +"Main text of the post. Per-network overrides go in `overrides`; leave it as an empty string when every target has its own text there (never write quote marks as the text)."
3 tool updates
- Changed
schedule_post3 fields changed- added
Input schema / properties / instagramStoryAdded value: +{ + "description": "true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Default false.", + "type": "boolean" +} - changed
Input schema / properties / media / descriptionPrevious value: -"Images (up to 10 for most networks) or one video. Not both."New value: +"Images (up to 10 for most networks, 20 on Instagram, Threads and LinkedIn) or one video. Instagram and Threads also take a carousel of up to 20 images and videos, mixed: then target only them. Instagram takes JPEG images and MP4 or MOV videos only." - added
Input schema / properties / tiktokAdded value: +{ + "additionalProperties": false, + "description": "The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true).", + "properties": { + "allowComment": { + "description": "Allow comments. Default false.", + "type": "boolean" + }, + "allowDuet": { + "description": "Allow duets (videos). Default false.", + "type": "boolean" + }, + "allowStitch": { + "description": "Allow stitches (videos). Default false.", + "type": "boolean" + }, + "brandedContent": { + "description": "Promotes a third party: labelled \"Paid partnership\"; cannot be SELF_ONLY.", + "type": "boolean" + }, + "privacy": { + "description": "Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know.", + "enum": [ + "PUBLIC_TO_EVERYONE", + "MUTUAL_FOLLOW_FRIENDS", + "FOLLOWER_OF_CREATOR", + "SELF_ONLY" + ], + "type": "string" + }, + "yourBrand": { + "description": "Promotes the user's own business: labelled \"Promotional content\".", + "type": "boolean" + } + }, + "required": [ + "privacy" + ], + "type": "object" +}
- Changed
update_post3 fields changed- added
Input schema / properties / instagramStoryAdded value: +{ + "description": "true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Default false.", + "type": "boolean" +} - changed
Input schema / properties / media / descriptionPrevious value: -"Images (up to 10 for most networks) or one video. Not both."New value: +"Images (up to 10 for most networks, 20 on Instagram, Threads and LinkedIn) or one video. Instagram and Threads also take a carousel of up to 20 images and videos, mixed: then target only them. Instagram takes JPEG images and MP4 or MOV videos only." - added
Input schema / properties / tiktokAdded value: +{ + "additionalProperties": false, + "description": "The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true).", + "properties": { + "allowComment": { + "description": "Allow comments. Default false.", + "type": "boolean" + }, + "allowDuet": { + "description": "Allow duets (videos). Default false.", + "type": "boolean" + }, + "allowStitch": { + "description": "Allow stitches (videos). Default false.", + "type": "boolean" + }, + "brandedContent": { + "description": "Promotes a third party: labelled \"Paid partnership\"; cannot be SELF_ONLY.", + "type": "boolean" + }, + "privacy": { + "description": "Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know.", + "enum": [ + "PUBLIC_TO_EVERYONE", + "MUTUAL_FOLLOW_FRIENDS", + "FOLLOWER_OF_CREATOR", + "SELF_ONLY" + ], + "type": "string" + }, + "yourBrand": { + "description": "Promotes the user's own business: labelled \"Promotional content\".", + "type": "boolean" + } + }, + "required": [ + "privacy" + ], + "type": "object" +}
- Changed
validate_post3 fields changed- added
Input schema / properties / instagramStoryAdded value: +{ + "description": "true: every Instagram target is published as a story instead of a post (exactly one image or one video of 60 s max; no caption, no first comment; gone after 24 h). Default false.", + "type": "boolean" +} - changed
Input schema / properties / media / descriptionPrevious value: -"Images (up to 10 for most networks) or one video. Not both."New value: +"Images (up to 10 for most networks, 20 on Instagram, Threads and LinkedIn) or one video. Instagram and Threads also take a carousel of up to 20 images and videos, mixed: then target only them. Instagram takes JPEG images and MP4 or MOV videos only." - added
Input schema / properties / tiktokAdded value: +{ + "additionalProperties": false, + "description": "The user's TikTok settings for every TikTok target, required to schedule a TikTok post (status scheduled); without them the post waits in review for the user to pick them in Broadcast. By publishing, the user accepts TikTok's Music Usage Confirmation (and Branded Content Policy when brandedContent is true).", + "properties": { + "allowComment": { + "description": "Allow comments. Default false.", + "type": "boolean" + }, + "allowDuet": { + "description": "Allow duets (videos). Default false.", + "type": "boolean" + }, + "allowStitch": { + "description": "Allow stitches (videos). Default false.", + "type": "boolean" + }, + "brandedContent": { + "description": "Promotes a third party: labelled \"Paid partnership\"; cannot be SELF_ONLY.", + "type": "boolean" + }, + "privacy": { + "description": "Who can see the post, as the user chose it: PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, FOLLOWER_OF_CREATOR or SELF_ONLY. Never pick it for them: ask when you do not know.", + "enum": [ + "PUBLIC_TO_EVERYONE", + "MUTUAL_FOLLOW_FRIENDS", + "FOLLOWER_OF_CREATOR", + "SELF_ONLY" + ], + "type": "string" + }, + "yourBrand": { + "description": "Promotes the user's own business: labelled \"Promotional content\".", + "type": "boolean" + } + }, + "required": [ + "privacy" + ], + "type": "object" +}
7 tool updates
- Changed
cancel_post1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
- Changed
follow_feed1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
- Changed
schedule_post1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
- Changed
unfollow_feed1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
- Changed
update_feed1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
- Changed
update_post1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
- Changed
upload_media1 field changed- added
Input schema / properties / sourceUrlAdded value: +{ + "description": "Optional https address of the conversation or session making this call (for instance a Claude Code session link), shown as a link in the user's activity log. Omit it when unknown; never invent one.", + "format": "uri", + "type": "string" +}
3 tool updates
- Changed
schedule_post2 fields changed- changed
Input schema / properties / body / descriptionPrevious value: -"Main text of the post. Per-network overrides go in `overrides`."New value: +"Main text of the post. Per-network overrides go in `overrides`; it may be empty (\"\") when every target has an override." - removed
Input schema / properties / body / minLengthRemoved value: -1
- Changed
update_post2 fields changed- changed
Input schema / properties / body / descriptionPrevious value: -"Main text of the post. Per-network overrides go in `overrides`."New value: +"Main text of the post. Per-network overrides go in `overrides`; it may be empty (\"\") when every target has an override." - removed
Input schema / properties / body / minLengthRemoved value: -1
- Changed
validate_post2 fields changed- changed
Input schema / properties / body / descriptionPrevious value: -"Main text of the post. Per-network overrides go in `overrides`."New value: +"Main text of the post. Per-network overrides go in `overrides`; it may be empty (\"\") when every target has an override." - removed
Input schema / properties / body / minLengthRemoved value: -1
3 tool updates
- Changed
schedule_post2 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, mastodon, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 500 on threads and mastodon, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why." - changed
Input schema / properties / link / descriptionPrevious value: -"Link appended after the text (becomes a preview card on Bluesky, Facebook and LinkedIn without media)."New value: +"Link appended after the text (becomes a preview card on Bluesky, Mastodon, Threads, Facebook and LinkedIn without media)."
- Changed
update_post2 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, mastodon, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 500 on threads and mastodon, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why." - changed
Input schema / properties / link / descriptionPrevious value: -"Link appended after the text (becomes a preview card on Bluesky, Facebook and LinkedIn without media)."New value: +"Link appended after the text (becomes a preview card on Bluesky, Mastodon, Threads, Facebook and LinkedIn without media)."
- Changed
validate_post2 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, mastodon, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 500 on threads and mastodon, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why." - changed
Input schema / properties / link / descriptionPrevious value: -"Link appended after the text (becomes a preview card on Bluesky, Facebook and LinkedIn without media)."New value: +"Link appended after the text (becomes a preview card on Bluesky, Mastodon, Threads, Facebook and LinkedIn without media)."
5 tool updates
- Changed
follow_feed1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon", - "threads" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads", + "youtube" +]
- Changed
schedule_post1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon", - "threads" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads", + "youtube" +]
- Changed
update_feed1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon", - "threads" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads", + "youtube" +]
- Changed
update_post1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon", - "threads" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads", + "youtube" +]
- Changed
validate_post1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon", - "threads" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads", + "youtube" +]
5 tool updates
- Changed
follow_feed1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads" +]
- Changed
schedule_post2 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky and linkedin; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 on linkedin. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why." - changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads" +]
- Changed
update_feed1 field changed- changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads" +]
- Changed
update_post2 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky and linkedin; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 on linkedin. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why." - changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads" +]
- Changed
validate_post2 fields changed- changed
Input schema / properties / firstComment / descriptionPrevious value: -"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky and linkedin; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 on linkedin. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why."New value: +"Optional reply Broadcast posts under the post right after it goes out, from the same account (e.g. the link, kept out of the post on LinkedIn, or the rest of a thread). Only on x, bluesky, linkedin, threads, facebook and instagram; ignored elsewhere. Limits: 280 on x (links count 23), 300 on bluesky, 1250 elsewhere. On X it costs credits like one more post. If it fails, the post stays published and the target's comment.error says why." - changed
Input schema / properties / platforms / items / enumPrevious value: -[ - "bluesky", - "x", - "facebook", - "instagram", - "tiktok", - "linkedin", - "mastodon" -]New value: +[ + "bluesky", + "x", + "facebook", + "instagram", + "tiktok", + "linkedin", + "mastodon", + "threads" +]
1 tool update
- Added
get_stats
2 tool updates
- Changed
unfollow_feed1 field changed- added
Input schema / properties / id / descriptionAdded value: +"Id of the feed to stop following, from list_feeds."
- Changed
update_feed1 field changed- added
Input schema / properties / id / descriptionAdded value: +"Id of the feed, from list_feeds or follow_feed."
12 tool updates
- First observed
cancel_post - First observed
follow_feed - First observed
get_post - First observed
get_schedule - First observed
list_accounts - First observed
list_feeds - First observed
schedule_post - First observed
unfollow_feed - First observed
update_feed - First observed
update_post - First observed
upload_media - First observed
validate_post
Publisher details
- Operator
- Taraxe · Publisher source
- Operator website
- https://www.taraxe.com
- Vendor relationship
- First-party
- Documentation
- https://www.taraxe.com/broadcast/skill.md
- Trust center
- Not applicable
- Restrictions
- Free, no subscription. Only X posts use prepaid credits (1 per post, 10 with a link)
Related MCP Connectors
Schedule and publish posts on X, LinkedIn, Instagram, Bluesky and Pinterest.
Schedule and publish posts to Instagram, Threads, TikTok, Facebook and Bluesky.
Schedule and publish social media posts to Instagram, Facebook, TikTok, X, LinkedIn and more.
Schedule and publish posts to Instagram, TikTok, X, LinkedIn, YouTube, Pinterest, Facebook & more.
Related MCP Servers
- FlicenseAqualityCmaintenanceSchedule and manage social media posts across Facebook, Instagram, Twitter/X, LinkedIn, YouTube, TikTok, and Pinterest directly from Claude.10-
AdaptlyPostofficial
AlicenseAqualityBmaintenanceGives AI agents the ability to schedule and publish social media posts to Instagram, TikTok, YouTube, X, LinkedIn, Facebook, Pinterest, Threads, and Bluesky. Create, schedule, and bulk-plan posts with per-platform captions, then check per-platform results and retry failures.12MIT- AlicenseNot gradedqualityCmaintenanceSocial media scheduling and publishing for AI agents. 17 validation-first tools to post to X, LinkedIn, Instagram, TikTok, YouTube, Reddit, Discord, Telegram, and more through one connected workspace.187 npm106MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.