Writes a native post per network from one idea and publishes it: TikTok, Instagram, YouTube & more
Scored across 21 tools
Most tools target distinct actions/resources: publishing vs scheduling vs bulk scheduling vs recurring, account vs brand vs credits. Some overlap among AI content tools (generate_posts, replicate_top_post, plan_week) and between scheduling variants, but descriptions clarify boundaries.
Predominantly snake_case with verb_noun or verb_noun_phrase patterns (create_brand, get_post_status, list_scheduled_posts). Minor deviations like my_account and bulk_schedule break the verb_noun convention but remain readable and consistent in casing.
21 tools is on the heavy side but justified for a full social-media management platform covering publishing, scheduling, AI drafts, media, brands, billing, and analytics. No obvious redundant tool that should be removed.
Covers core lifecycle: connect, upload, generate, publish, schedule (one-off, bulk, recurring), status, cancel, performance, account/billing. Missing explicit update/edit for scheduled posts or recurring series and brand deletion, but agents can work around by cancel/recreate.
Checks, and on request schedules, many posts at once: a CSV file's text (csv) or a list of rows (rows), each row one post with the columns date ("2026-10-12 09:00" in the row's or the upload's timezone, an ISO time with offset, or "next_slot"), networks ("linkedin, x"), text, optional text_ (each network its own text), media_urls (https links; video: or document: prefix), alt_text, first_comment (LinkedIn, Bluesky, Mastodon), x_reply and x_thread (X), title, brand and label. dry_run defaults to true: nothing is scheduled and the result lists, for every row, the time it would go out, its networks, each network's length as that network counts it, the X credits it would use, whether it would wait for approval or be held by the plan, and its errors and warnings. With dry_run false the upload is scheduled whole or not at all: if any row has an error nothing is scheduled (code bulk_rows_invalid) and each row says what to fix. The plan limits rows per upload (Free 20, Starter 500, Pro 1,000, Agency 2,000, Scale 5,000); on Free, posts past the 3 scheduled at a time are saved as held. The same upload twice is refused (code bulk_already_scheduled) unless allow_duplicate is true. The result has batch_id; DELETE /api/bulk/{batch_id} undoes the whole upload. Write the rows for the user when they describe a content plan; show them the dry run before scheduling.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | The CSV file's text, first line = column names. Comma, semicolon or tab separated. | |
| rows | No | Instead of csv: the posts as objects with the same column names, e.g. [{"date":"2026-10-12 09:00","networks":"linkedin, bluesky","text":"…"}]. | |
| dry_run | No | true (default): only check. false: schedule every row, or none. | |
| brand_id | No | Default brand for rows without a brand column. | |
| timezone | No | IANA timezone for dates without one, e.g. "America/Lima". Default: each row's timezone column, else the brand's queue timezone. | |
| date_format | No | How to read dates like 12/10/2026. Default ymd (2026-10-12). | |
| fit_long_text | No | Accept a text over a network's limit and cut it at a sentence or word when published, instead of refusing the row. | |
| allow_duplicate | No | Schedule an upload identical to one already scheduled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it explains dry_run output contents, atomic all-or-nothing scheduling with the bulk_rows_invalid code, per-plan row limits, held posts on Free, duplicate refusal with bulk_already_scheduled, and the batch_id + DELETE undo path. Annotations (non-destructive, non-idempotent, open-world) are complemented by real operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation and the dry_run default, and the dense column enumeration earns its place. It is one long block of prose with no paragraph breaks, which slightly hurts scanability, but little is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the structure of the dry-run result, the failure mode, and the undo mechanism, and covers limits, duplication and holding behaviour. An agent has everything needed to call it correctly without a structured return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the eight top-level params, so the baseline is 3. The description earns above that by enumerating the row column names and their syntax (date formats and 'next_slot', per-network text_<network>, media_urls prefixes, alt_text, x_reply/x_thread, brand/label) that the loosely-typed rows items schema does not define.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and scope: 'Checks, and on request schedules, many posts at once', plus the two accepted input forms (csv or rows). An agent can immediately distinguish this bulk operation from the single-post scheduler among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete procedural guidance ('show them the dry run before scheduling', 'write the rows for the user when they describe a content plan') and notes dry_run defaults to true. It doesn't explicitly name schedule_post as the single-post alternative, so sibling routing is left to inference, but the 'many posts at once' framing covers it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels a queued or held post, or withdraws one waiting for approval, so it is never published (a withdrawn post's approval links stop working). Only works before it starts publishing. Takes the id of the scheduled post.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Scheduled post id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real value beyond that: it explains the withdrawal side effect (approval links stop working) and the pre-publishing timing limit, which annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the action and states, then the critical timing constraint and side effect. No filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation with no output schema, the description covers what the tool does, when it is valid, and the user-visible side effect. It stops short of stating what a successful call returns or how an already-cancelled post is handled, though the idempotent annotation partly covers the latter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single id parameter, so the schema already carries the meaning. "Takes the id of the scheduled post" restates the schema without adding format, source, or lookup guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (cancels/withdraws) and resource (queued, held, or approval-waiting scheduled post), and enumerates the post states it applies to. An agent can distinguish this from schedule_post, list_scheduled_posts, or get_post_status 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Only works before it starts publishing" gives a clear applicability window, which is the decisive condition for choosing this tool. It does not name an alternative for the post-publish case, but the exclusion is stated clearly enough to route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new, empty brand (a separate business with its own connected social accounts) on the PostWire account and returns its id. The plan limits the number of brands; at the limit nothing is created and the response names the plan that includes more brands, its monthly price and a checkout link.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Brand name, e.g. the client's business name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses key behavioral traits: the brand is created empty, the id is returned, and at the plan limit nothing is created and the response redirects the user to an upgrade path with plan name, price, and checkout link. This is valuable side-effect and failure-mode context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every clause earns its place—defining brand, noting the return value, and explaining the plan-limit behavior. No repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter), the schema documents the parameter fully, and the description covers the return value plus the important edge case at the plan limit. An agent has enough to call it correctly without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'name' parameter with a clear example, so the description adds little parameter-specific meaning. Per the baseline, 3 is appropriate when schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Creates'), a precise resource ('a new, empty brand'), defines what a brand is, and notes the return value. It clearly differentiates this tool from sibling listing or connection tools like list_brands and create_connect_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: creating a new separate business entity on the PostWire account. It doesn't explicitly name alternatives or state when not to use it, but the purpose is specific enough that an agent can route to it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a one-hour link the user opens in a browser to connect social accounts (TikTok, Instagram, YouTube, Facebook Pages, LinkedIn, Bluesky…) to their PostWire account: the page shows each network as a button, signs in to it on the network's own page, and then offers the next one, so several networks can be connected from one link. Nothing is connected until the user completes it on the page. With platform the page offers only that network; with brand_id the accounts are connected to that brand. Instagram opens with Log in with Instagram (a Business or Creator account, no Facebook Page needed), and the page also offers connecting through a Facebook Page. Returns the url of that page and message_for_user: one plain sentence telling the person what to do.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_id | No | Brand to connect it to. Omit for the default brand. | |
| platform | No | Platform to connect. Omit to let the user choose on the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With minimal annotations (readOnlyHint=false, non-destructive, non-idempotent), the description carries real weight and delivers: the link expires in one hour, no account is connected until the user finishes the browser flow, and the response contains url plus message_for_user. It doesn't mention auth/permission requirements or re-issuing behavior, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and expiry, and every clause carries information (flow mechanics, Instagram specifics, return values). It is a long run-on sentence with some detail (the Facebook Page fallback) that could be trimmed, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-param tool with no output schema, it covers the full lifecycle an agent needs: what it creates, expiry, that side effects are user-gated, how the two optional params change behavior, and what the response returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuine semantics: platform narrows the page to a single network while omitting it lets the user choose, and brand_id routes the resulting connections to a specific brand. That goes beyond the schema's terse property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Creates a one-hour link the user opens in a browser to connect social accounts') and immediately scopes it with the networks and the PostWire account. The 'link' family siblings (create_upload_link, get_upgrade_link) are clearly differentiated by the connect-accounts purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: use it to generate a page where the user connects one or many networks, and nothing happens until the user completes the flow. It explains the platform/brand_id selection modes but never names an alternative tool or states an exclusion, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sets up a post that repeats on a schedule: daily, weekly on some weekdays, or monthly on some days of the month (31 falls on the last day of shorter months; -1 = the last day), every N days, weeks or months, at 1-4 times a day in a timezone (daylight saving handled), from a start date until an end date or for a number of times. variants (a list of texts) are used in turn, so the same text does not repeat every time. The duplicate guard (guard_days, default 3, 0 = off) skips a network where the same text went out in the last guard_days when an occurrence is published: networks flag repeated posts. Occurrences are put in the queue up to 7 days ahead as ordinary scheduled posts (each can be edited or canceled alone), and go through the brand's approval rules and the plan's limits like any post. On every paid plan (Starter 25, Pro 100, Agency 500, Scale 2,000 at a time); not on Free. Returns the recurring post with its next occurrences and any warnings (for example: one text every day with a 3-day guard would be skipped).
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | When it repeats. | |
| text | No | The post, when there is one text. | |
| label | No | Name shown in the queue, e.g. "Monday tip". | |
| brand_id | No | Brand whose accounts to use; omit for the default brand. | |
| variants | No | Texts used in turn: the 1st occurrence uses the 1st, the 2nd the 2nd, and so on, starting again after the last. | |
| photo_url | No | Optional image (public https link). | |
| platforms | Yes | Connected platforms to post to. | |
| video_url | No | Optional video (public https link). | |
| guard_days | No | Skip a network where the same text went out in the last N days. Default 3; 0 = off. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnly=false, destructive=false, idempotent=false, openWorld=true; the description goes far beyond that, disclosing DST handling, the duplicate guard and its default/off behavior, that occurrences are queued up to 7 days ahead as editable/cancelable posts, that they flow through brand approval rules and plan limits, and that the call returns warnings. This is exactly the mutation context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single dense paragraph, but nearly every clause carries unique behavior (guard, queue, plans, returns). Front-loaded with purpose before the mechanics. Slightly less scannable than it could be as one long run-on, but no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with nested objects and no output schema, the description covers inputs, side effects, plan gating, and the return shape ('the recurring post with its next occurrences and any warnings'), including an example warning. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning beyond the schema: it explains the guard_days skip semantics with a worked edge case, the 31/-1 month-day fallback, the round-robin use of variants, and DST-aware timezone handling. These clarify how parameters interact at runtime rather than just restating field docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Sets up a post that repeats on a schedule') and immediately scopes it to recurring behavior, distinguishing it from one-off siblings like schedule_post and bulk_schedule. The recurrence taxonomy (daily, weekly, monthly, every N) makes the tool's remit unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives rich operating context (paid-plan requirement with tier limits, Free exclusion, queue/approval behavior) but never explicitly says when to prefer this over schedule_post or bulk_schedule, nor does it name an alternative. Usage is strongly implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a single-use link, valid for 24 hours, to a PostWire page where the user picks one photo or video from any device (JPG, PNG, WebP, GIF, MP4, MOV or WebM, up to 1 GB; big videos upload in parts automatically). The file stays in the account's PostWire media storage while a scheduled post needs it, is deleted the day after that post is published, and 7 days after upload if no post uses it (2 days on the Free plan; so post or schedule it soon). A file attached to a chat does not reach PostWire; this page is how it gets there. Returns the page url, an upload_id for checking the upload's status, and message_for_user: one plain sentence telling the person what to open and do.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far beyond the annotations, it discloses single-use semantics, a 24-hour validity window, accepted formats (JPG, PNG, WebP, GIF, MP4, MOV, WebM), a 1 GB cap, automatic multi-part upload for large videos, and a detailed retention/deletion policy (deleted the day after the scheduled post publishes, 7 days after upload if unused, 2 days on Free). It also names the return payload. Annotations only say non-read-only, non-destructive, non-idempotent; the description adds the operational substance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The key fact — a single-use 24-hour upload link — is front-loaded, and no sentence is filler; formats, limits, retention and returns all carry weight. The single long paragraph with stacked parentheticals is dense and would read better broken into lifecycle vs. return-value groupings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned url, upload_id and message_for_user, and it covers the full upload lifecycle including edge cases (Free-plan shorter retention, chat attachments not reaching PostWire). An agent has everything needed to call it and explain the result to a user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero input parameters, so per the baseline this scores 4. The description instead spends its detail budget on outcomes and lifecycle rules, which is the right call for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource: 'Creates a single-use link, valid for 24 hours, to a PostWire page where the user picks one photo or video.' Scope and mechanism are unambiguous. It does not, however, distinguish itself from the similarly named sibling create_connect_link or clarify the relationship to get_uploaded_file, so the agent gets no explicit disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies real context for when this applies: a file must reach PostWire media storage, and 'A file attached to a chat does not reach PostWire; this page is how it gets there.' The 'so post or schedule it soon' line ties it to the post/schedule workflow. No explicit exclusions or named alternative tools are given, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes one draft per platform from a single idea, adapted to each network's rules (character limit, hashtags, title and tags for YouTube, hook-first caption for TikTok and Reels, link placement for LinkedIn, Slack formatting, plain text for Nostr). For the blogs (wordpress, devto, hashnode) the draft is a full article: title (<= 70 characters), summary (120-160 characters), a Markdown body with H2 sections, and 3-5 tags (Dev.to: 4). Nothing is published. Returns { drafts: { : { text, title?, tags?, summary?, thread?, first_comment? } } } and, if the writer skipped a platform, { missing: [...] }. thread (the posts after text) comes back when the user asks for a thread (X, Bluesky, Mastodon), or on Bluesky and Mastodon when the idea is too long for one post there; first_comment comes with it when the idea has a link (LinkedIn, X, Bluesky, Mastodon), so the link goes in the first comment. Counts toward the account's daily AI limit.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The idea or message to communicate. More detail gives better drafts. | |
| media_url | No | Optional public https URL of the photo or video the post is about. | |
| platforms | Yes | Platforms to write for, e.g. ["linkedin","x","bluesky"]. | |
| brand_voice | No | Optional tone or style notes, e.g. "friendly, no emojis, first person plural". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows it's a non-destructive mutation. The description adds real value beyond that: it clarifies 'Nothing is published' (resolving the write-hint ambiguity), discloses that the call 'Counts toward the account's daily AI limit', and details the return shape including the missing-platform case. Strong disclosure, though it doesn't explain auth or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, followed by per-platform rules and return shape. It is dense and long, but with no output schema the return-format detail is not wasted. Slightly packed, but every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully carries the return-value burden: the exact { drafts: { <platform>: { text, title?, ... } } } shape, the { missing: [...] } case, and the conditional presence of thread and first_comment. Combined with the publication and daily-limit notes, an agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema and the baseline is 3. The description lists per-platform formatting behavior (character limits, hashtags, hooks) that relates to the 'platforms' argument but adds no per-parameter syntax or constraint detail beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Writes one draft per platform from a single idea') and immediately scopes it as a drafting tool with 'Nothing is published', which cleanly separates it from publishing siblings like post_to_social and schedule_post. The verb+resource are fully clear and the agent can distinguish it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'Nothing is published' suggests using this when you want drafts, and the thread/first_comment passages describe output conditions. However, no sibling tool is named as an alternative and no explicit when-to-use-vs-when-not guidance is given. Adequate but leaves the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns what the account's own numbers say works, over the last 90 days, computed from the numbers each network reports (no estimates): the published posts ranked against the median of the same social account on the same network, each with its network, brand, link, excerpt, metric (views where the network reports them, otherwise likes + reposts + replies), value, that median, n (posts in the median), a verdict (winner at 2x the median or more, under at half or less) and what the post had (format, first-line type, question, emoji, number up front, day and time, length, hashtags); best_times: the time of day and day of week whose posts did best, with the size of the effect and both sample sizes, or — below 8 measured posts or without a clear difference — two hours to post at to learn it; streak: weeks in a row with at least one post; headline_pattern: the strongest pattern, as a sentence with its numbers; next: three concrete suggestions for the next post, each with the numbers behind it; competitors: public accounts the user watches (YouTube, Bluesky, Mastodon; TikTok captions only), their posts against their own median and what their best posts share; measurable: what each network lets PostWire read, and why the rest is not measurable. Posts younger than 24 hours are not ranked; patterns need at least 10 measured posts and 3 per group. Depending on the account's plan it also returns every pattern, the per-network detail and which formats to double down on or rethink; on a plan without them, locked.patterns_preview says which further patterns are ready and how large each effect is, without the winning value. Read-only; nothing here uses AI.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_id | No | Only this brand's posts. Omit for all brands. | |
| platform | No | Only posts on this network. | |
| timezone | No | IANA timezone for the day and time patterns, e.g. "America/Lima". Default UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only assert readOnly/idempotent/non-destructive; the description goes far beyond them with the 90-day window, the 24-hour ranking floor, minimum sample thresholds, plan-gated output (locked.patterns_preview revealing effect sizes but withholding winning values), per-network measurability limits, and the 'no estimates, no AI' computation basis. That is exactly the behavioral context an agent needs before promising results to a user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening clause is well front-loaded and the field inventory is genuinely needed since there is no output schema, but the whole thing is delivered as one ~330-word semicolon-chained sentence with no visual hierarchy. Dense and information-earning, yet structurally unscannable for an agent skimming before a call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analytics tool with no output schema, three optional filter params and rich annotations, the description covers what is returned, the computation basis, the gating rules and the fallback behavior ('below 8 measured posts ... two hours to post at to learn it'). Nothing an agent needs to invoke it correctly or set expectations is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so brand_id, platform and timezone (with its IANA example) are already fully documented in the schema. The description only indirectly touches timezone via 'day and time patterns' and never adds filter syntax beyond what the schema provides — baseline 3 is correct here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific return (ranked posts, best times, streaks, patterns, suggestions, competitor benchmarks) computed from the account's own reported numbers over a fixed 90-day window. An agent can distinguish it immediately from every sibling, none of which produce analytics — the nearest relatives (replicate_top_post, plan_week) consume this kind of data rather than produce it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description names qualifying conditions ('patterns need at least 10 measured posts and 3 per group', 'posts younger than 24 hours are not ranked') and closes with 'Read-only; nothing here uses AI.' However, it never says when to prefer this over list_scheduled_posts or get_post_status, nor that replicate_top_post is the natural follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the status and link of a published post, by platform and the post id returned when it was published. For a post that is waiting for approval or scheduled, pass the id PostWire returned for it (platform can then be omitted): the status is pending_approval (with who was asked and the review link), rejected (with the reason), scheduled, or each network's result once it went out. For TikTok and YouTube it asks the platform for the processing status and returns the public link once there is one. For an Instagram video returned as "processing", pass the id it returned: the answer is processing, published (with its id and link) or failed (with the reason). For networks that publish immediately it returns status "published" and, where the id allows it, the post's link (Telegram channels, including private ones as t.me/c//; Bluesky; LinkedIn; Facebook).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post id returned when it was published on that platform, or the id PostWire returned for a post waiting for approval or scheduled. | |
| brand_id | No | Brand whose account published it; omit for the default brand. | |
| platform | No | Platform of the post, e.g. "tiktok". Can be omitted for a post waiting for approval or scheduled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, but the description goes well beyond them: it enumerates the possible statuses (pending_approval, rejected, scheduled, processing, published, failed), explains that TikTok/YouTube trigger a platform-side processing poll, that Instagram may return 'processing' requiring a re-call, and that immediate-publish networks return the public link with channel-specific URL shapes. That is exactly the behavioral depth an agent needs for a polling-style read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded – purpose first, then per-scenario detail – and nearly every sentence carries platform-specific information that would otherwise be missing. It is one dense block rather than a scannable structure, which costs it the top mark, but there is little filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carries the full burden of explaining return values, and it does: it enumerates the possible status values, what accompanies each (review link, rejection reason, failure reason), and the link format per network. An agent can call this and interpret the response without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds conditional logic the schema only hints at: 'platform can then be omitted' for approval/scheduled posts, the dual meaning of 'id' (platform post id vs. PostWire id), and the re-call pattern for Instagram videos returned as 'processing'. That materially clarifies how to populate the parameters in each case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Returns the status and link of a published post, by platform and the post id.' That is unambiguous and clearly distinct from the performance-oriented sibling get_post_performance. It stops short of naming any sibling or stating exclusions, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description spends most of its length on scenario routing – which id to pass for pending/scheduled posts, for Instagram 'processing' videos, for TikTok/YouTube – which is genuinely useful invocation context. However, it never says when to reach for this tool instead of list_scheduled_posts, get_post_performance, or cancel_scheduled_post, and gives no when-not guidance. Implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns PostWire's paid plans with their monthly price and what each includes (posts a month, brands, AI drafts a day, networks per post, scheduled posts at a time), the account's current plan, and a checkout link for one plan (the next plan up when none is given). The link opens a Stripe payment page in the browser and nothing is charged unless the user pays there; for an account that already has a subscription it opens the plan page of the PostWire dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Plan to check out. Omit for the next plan up. | |
| interval | No | Billing period of the link: month (default) or year (20% off, billed once a year). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds meaningful behavior: the link opens a Stripe payment page in the browser, nothing is charged unless the user pays there, and existing subscribers are routed to the dashboard plan page instead. It stops short of link expiry or single-use semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The return contents are front-loaded in the first sentence, with the click-behavior caveat second. The first sentence is dense with a long parenthetical feature list, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return-value burden, and it does: it enumerates plans, prices, plan contents, current plan, and the checkout link, plus what happens on click. Nothing an agent needs to call or interpret this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both params are enum-constrained with descriptions, so the schema already does the heavy lifting. The description restates the plan default ('next plan up') and interval meaning that the schema already documents, adding little beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (returns paid plans, the current plan, and a checkout link) and enumerates the returned payload (monthly price, post/brand/AI-draft/network/scheduled-post limits). It is clearly distinguishable from siblings like my_account or get_x_credits, which do not surface plans or checkout links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear selection context: 'the next plan up when none is given' tells the agent the default when the plan parameter is omitted. It does not explicitly contrast with alternatives or state when-not-to-use, but the default behavior and interval default are well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the status of a file uploaded through a PostWire upload link, by upload_id: "waiting" until the file has arrived, then "done" with its media_url (an https URL valid for 6 hours, renewed when the post goes out, that works as video_url or photo_url), kind (photo or video), size and content type.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_id | Yes | The upload_id returned with the upload link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/closed-world, and the description adds substantial behavior beyond them: the two-state status machine, the 6-hour media_url validity window, its renewal when the post goes out, and that the URL serves as both video_url and photo_url. This is exactly the runtime context an agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the status semantics first and the return payload second; the nested parenthetical is dense but every clause (validity window, renewal, dual URL use) carries real information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return contract and does: status values, media_url with lifetime, kind, size, and content type. Nothing needed to interpret the response is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented as 'The upload_id returned with the upload link.' The description's 'by upload_id' adds no syntax, format, or sourcing detail beyond what the schema states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns status) and resource (a file uploaded through a PostWire upload link) keyed by upload_id, which clearly distinguishes it from sibling create_upload_link. An agent can tell it apart 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the polling workflow by describing the waiting→done transition and tying the tool to an upload link, so an agent knows to call it after creating a link. It does not explicitly name create_upload_link as the prerequisite or state when-not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows what posting to X (Twitter) costs this account and what it has left. X is a pay-per-use add-on of the paid plans (Starter, Pro, Agency, Scale; not Free, not during a trial): 1 X credit = 1 plain X post, a post with a link uses 10, each image or video adds 1. Returns mode (paid, free, trial or internal), the plan's monthly X credits, used and left, top-up credits, X posts today against the daily limit, the price table, the last movements, and links to buy top-up credits (80 credits for $5, 340 for $20; each opens a Stripe payment page, nothing is charged unless paid there). With text, it also returns how many credits that post would use (with thread or reply: the whole chain).
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Optional: an X post to price before sending it. | |
| reply | No | Optional: a reply under the post (or the thread), priced with it. | |
| video | No | Optional: a video attached to that post. | |
| images | No | Optional: images attached to that post. | |
| thread | No | Optional: the posts of a thread after text, to price the whole thread. |
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 substantial non-obvious context: the credit conversion rules, the meaning of the returned mode values, the top-up price points, and the explicit reassurance that opening a Stripe page charges nothing. That is exactly the value-add expected above the annotation bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and the cost model, then the return contents, then the top-up details. It is long for one description but nearly every clause carries distinct information; the plan-list parenthetical is the only slightly expendable part.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 full burden and does so: it enumerates the return fields (mode, monthly credits, used/left, top-ups, daily usage, price table, movements, purchase links) and explains the pricing semantics. Nothing an agent needs to call or interpret it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining what the parameters are FOR (pricing a post before sending) and how the pricing aggregates across text, reply, images, video and thread ('with thread or reply: the whole chain'). It stops short of tying each individual parameter to a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Shows what posting to X (Twitter) costs this account and what it has left') and immediately grounds it in the pricing model, which clearly separates it from siblings like get_upgrade_link or my_account. An agent can tell what it does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: it is the pre-flight cost/balance check, and the optional params exist to price a prospective post, thread, reply, image or video before sending. It does not explicitly name an alternative or a 'do not use when' condition, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the account's brands (one business each) with the social accounts connected to each: platform, the handle, display name, picture and profile link the network reports, when it was connected, and whether posts to it need only text, a video, or a photo or video. Also returns the plan's brand limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those hints: the exact fields returned for each connected account, the 'one business each' cardinality, and the inclusion of the plan's brand limit. Minor gaps like pagination or error behavior are not material for a simple listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the main purpose before enumerating details. It is dense but not wasteful, though the long field enumeration could have been formatted more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the full burden of explaining what the agent will receive. It covers the core entities, the connected-account fields, content-type requirements, and the plan limit, making the tool callable without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so there are no parameters for the description to clarify. The baseline of 4 applies because nothing additional is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and a clear resource ('the account's brands') plus the connected social accounts and plan limit. It is immediately distinguishable from siblings like list_platforms or create_brand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this is a read-only listing operation for brand and connected-account data, which makes the intended use obvious. It does not explicitly name alternatives or exclusion conditions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the social platforms and destinations PostWire can publish to and, for each, whether it connects with OAuth or with credentials (fields, plus optional_fields), and kind "article" for the blogs (WordPress, Dev.to, Hashnode), where a post is an article with a title. Does not need a PostWire account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: no account/authentication is required, and the response is self-describing (OAuth vs credentials, field vs optional_field, article kind). It stops short of describing pagination or full response shape, but with annotations present this clears the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence but front-loaded with the core purpose, and every clause carries information. It is somewhat run-on, and the parenthetical blog examples and 'title' detail are lower-value embellishment, but nothing is truly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carries the burden of describing return values, and it does so at a conceptual level (per-platform auth type, credential field names, article kind). It is sufficient for an agent to know what it will get, though the exact field names and structure remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description instead documents the shape of the returned data (fields, optional_fields, kind) which is useful orientation, though it does not enumerate concrete field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Lists) and resource (social platforms and destinations PostWire can publish to), and goes further by naming the per-platform attributes returned: auth mechanism, field names, and a 'kind' of article for blogs. This clearly separates it from action siblings like post_to_social or schedule_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer it is a discovery/reference call to run before configuring a destination. The note 'Does not need a PostWire account' is a useful precondition that helps the agent decide to call it early, but there is no explicit when-to-use or alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the account's scheduled posts (queued, held, pending_approval = waiting for a person to approve it, publishing, processing = sent and Instagram is still processing the video, done, failed, rejected = not approved, or canceled) with their id, time, platforms and status. Optional from/to limit the time range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only posts scheduled before this time. | |
| from | No | Only posts scheduled at or after this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds useful behavioral context beyond them: the full status taxonomy with definitions (e.g., pending_approval = waiting for approval, processing = Instagram still processing video). This is genuinely helpful for interpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, but the long parenthetical enumerating status meanings is dense and slightly interrupts readability. Every element is relevant, but the structure could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple read-only tool with two well-documented optional params, the description covers purpose, return fields (id, time, platforms, status), and status vocabulary. No output schema exists, so explaining status semantics is a reasonable inclusion that aids result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents from/to. The description restates them as 'Optional from/to limit the time range' without adding syntax or boundary semantics beyond the schema. Baseline 3 for high-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource (lists scheduled posts) and enumerates the status values it returns, which helps distinguish it from get_post_status. It doesn't explicitly delineate itself from sibling get_post_status, but the plural 'posts' plus status enumeration makes the distinction reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The optional from/to parameters imply a time-range listing use case but there's no explicit guidance on when to use this over get_post_status or the filtering tools. Usage is implied by the description rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Makes a short vertical video from the words of a post, for networks that take only video (YouTube) or video or photos (TikTok): an MP4 of 1080x1920, 8 to 12 seconds, H.264 with AAC sound. The first line appears as a large heading and up to two more sentences appear one after another over a softly moving plain background, with royalty-free background music or silence; an optional footer line (for example the brand's name) sits under the text. Emoji, links and trailing hashtags are left out and no PostWire mark is added. Draws Latin, Greek and Cyrillic text. No AI is used and nothing is published. The file stays in the account's PostWire media storage while a scheduled post needs it, is deleted the day after that post is published, and 7 days after upload if no post uses it (2 days on the Free plan; so post or schedule it soon). Returns media_url (an https URL valid for 6 hours, renewed when the post goes out, that works as video_url), duration_s, text_on_video (the lines shown) and message_for_user. Up to 10 videos an hour per account, and per day 10 on the Free plan and 60 on paid plans.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The post's words. The first line or sentence becomes the heading. | |
| music | No | Background music: auto picks one of the three beds; none gives a silent track. Default auto. | |
| style | No | Light (warm off-white, default) or dark background. | |
| footer | No | Optional short line under the text, such as the brand or shop name. Omit for none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, but the description adds substantial behavioral context beyond annotations: it details file format, dimensions, duration, codec, text rendering, music options, privacy (no AI, no watermark), storage lifecycle including deletion timelines per plan, return values, and rate limits. This is rich, non-obvious information that goes far beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and key constraints, then flows into behavioral details. It is somewhat long but every sentence adds value; no obvious repetition. Could be slightly more structured with paragraphs or bullets for readability, but acceptable as a dense block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and four parameters with full schema coverage, the description is highly complete: it covers what the tool does, output format details, return values (media_url, duration_s, text_on_video, message_for_user), lifecycle of the generated file, rate limits, and plan-specific differences. An agent has all needed information to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds meaningful context about how parameters affect output: text becomes heading and sentences, music can be royalty-free or silence, footer sits under the text, style options are light or dark. It enriches understanding beyond the schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (makes) and resource (short vertical video) and names the target networks (YouTube, TikTok) where video content is required. It clearly distinguishes itself from sibling tools like post_to_social or schedule_post by focusing on video generation from text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: for networks that take only video or video/photos, and it mentions the need to post or schedule soon due to deletion. However, it does not explicitly name alternatives or state when not to use this tool compared to siblings like generate_posts or replicate_top_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the signed-in PostWire account: plan, usage against each plan limit (posts this month, brands, AI drafts today, networks per post, scheduled posts waiting), brands, and which social accounts are connected, each with its brand and the handle, display name and picture the network reports for it. When a limit is at least 80 % used, the result includes the plan that raises it, its monthly price and a checkout link. On the free plan it also includes insights_teaser: how many What works patterns are ready and how strong they are. When no social account is connected, it includes a one-hour link to a page where several networks can be connected, and message_for_user: one plain sentence for the person. While the account has not published anything yet, next_step.say_this is one exact sentence the person can say to get the first post out (for example: connect a network and post, or post a first video). A free account that has not had a trial gets trial_offer: Pro now with the first month 50% off ("Get Pro today: first month $14.50 (50% off), then $29/month. Cancel anytime."), its terms in one sentence and its link; a trial that is running is described in trial.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotent safety profile; the description goes well beyond them by disclosing conditional behaviors: what appears at >=80% limit usage, the free-plan insights_teaser, the one-hour connect link plus message_for_user when nothing is connected, next_step guidance for unpublished accounts, and trial_offer details with exact pricing text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and core content are front-loaded, and each following sentence covers a distinct conditional branch of the response. It is long and the sentences are dense, but with no output schema the detail earns its place rather than repeating structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameters, and only safety annotations, the description is the sole carrier of return-value semantics and it covers the base payload and every conditional extension (limit warnings, teaser, connect link, next step, trial offer) an agent needs to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies and no parameter-level information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Shows') and resource ('the signed-in PostWire account') and enumerates the returned content (plan, usage limits, brands, connected accounts), which is enough to distinguish it from siblings like list_brands, get_upgrade_link and get_x_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the account-overview/status tool, and the mention of checkout link and trial_offer overlaps with get_upgrade_link, but the description never says when to call this versus those alternatives or what prerequisites apply beyond being signed in.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes one post per day for 1 to 7 days from a single topic, each day from a different angle and each platform in its own native format, and queues them to be published publicly at the given hour on each day starting tomorrow, through the connected accounts. Text only: platforms that require a video or photo (TikTok, YouTube, Instagram) are refused. Every platform must already be connected. The whole week counts as one AI draft toward the daily AI limit. Every day is written; days that do not fit in the plan's monthly post limit or in its scheduled-posts limit (Free: 3 waiting at a time) are saved as held (never published on the current plan; each says held_for) and are scheduled automatically when the plan is upgraded; the result then also gives that plan, its price and a checkout link. On a plan with a networks-per-post limit (Free: 2) each day goes out to the first platforms only, named in held_networks. Returns the queued and held items with their id, time and a preview of each platform's text; any of them can be canceled before it runs. If the brand's approval rules or a limit on this API key or connected app hold the post, nothing is published: the result has status "pending_approval", the post's id and approval_id, who was notified and a review link, and the post goes out once a person approves it from the emailed link or the PostWire dashboard — an AI assistant or an API key cannot approve it. A limit on this key or app can also refuse a post with code key_network_not_allowed, key_brand_not_allowed or key_monthly_cap_reached.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days, starting tomorrow. Default 5. | |
| hour | No | Hour of the day to publish, on the timezone's clock. Default 10. | |
| topic | Yes | What the week is about, e.g. "our new autumn menu and the farmers behind it". | |
| brand_id | No | Brand whose accounts to use; omit for the default brand. | |
| timezone | No | IANA timezone of that hour, e.g. "America/Lima". Default UTC. | |
| platforms | Yes | Text-capable platforms to post to each day, e.g. ["linkedin","bluesky"]. | |
| brand_voice | No | Optional tone or style notes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say it is a non-idempotent, open-world write; the description adds the real behavior an agent needs: week counts as one AI draft against the daily limit, over-limit days are saved as held_for and auto-scheduled on upgrade, networks-per-post limit truncates to held_networks, and approval rules force a pending_approval outcome with approval_id and a human-only review link. It even enumerates refusal codes (key_network_not_allowed, key_brand_not_allowed, key_monthly_cap_reached), which is far beyond what the annotations supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded in the first sentence, which is good, but the remainder is a dense single paragraph mixing limits, held behavior, approval flow, and error codes with internal redundancies (held restated with held_for and never published). It is informative but hard to scan and could be split into tighter sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 full burden of return-value disclosure and does so: it describes queued and held items with id, time, and per-platform preview, cancellability before run, and the pending_approval payload including status, id, approval_id, notified parties, and review link. Nothing an agent needs to call or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (days, hour, topic, brand_id, timezone, platforms, brand_voice) is already documented in the schema, and the description mostly restates the day range and hour semantics rather than adding format or syntax detail. The one added nuance is that platform eligibility is constrained to text-capable networks, but that is already implied by the enum and platform descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource and scope: writes one post per day for 1-7 days from a single topic, each day a different angle, each platform in native format, queued for public publication. That combination of per-day generation with multi-platform native formatting is specific enough to separate it from schedule_post, bulk_schedule, and generate_posts without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear preconditions and exclusions: text-only, platforms requiring video/photo (TikTok, YouTube, Instagram) are refused, and every platform must already be connected. It never names a sibling tool as the alternative for the non-text or single-post case, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publishes a post immediately and publicly to the listed platforms through the social accounts connected to the user's PostWire account. A published post cannot be withdrawn from PostWire. Accepts one text for all platforms or a separate per_platform draft for each. YouTube requires video_url; TikTok requires video_url or photos (photo_url or media); Instagram requires a photo or video, and two or more media items make a carousel. Every platform must already be connected; otherwise nothing is published and the error names the missing ones. The same payload sent twice within 2 minutes is refused as a duplicate unless idempotency_key differs. When a platform is connected in more than one brand and brand_id is omitted, nothing is published and the error lists the brands. Returns { posted, published_to, results: [{ platform, ok, id?, url?, account?, error? }] }, where account and published_to name the handle and brand each post went to. After the account's first post through this connection, next_step proposes a week of posts on the same topic for the text networks it went to (its topic and platforms); nothing is queued until the person asks for it. The plan sets how many networks one post goes out to (Free: 2): only the first platforms in the list are published and each of the others comes back with ok: false, held: true and code networks_per_post (its version was written and not sent), listed in held_networks with a one-sentence held_message, and message_for_user says it in plain words for the person; every network can still be connected and written for. TikTok and Instagram videos may still be processing when this returns (status processing, no url yet). When the networks-per-post or the monthly post limit stops a platform, the result also names the plan that lifts it, its price and a checkout link, and, for a free account that has not had one, a link to Pro with the first month 50% off (trial_offer: paid today, then the regular monthly price, cancel anytime). Such an account also gets the trial link once after its first post from an assistant, with a one-sentence trial_message. X (Twitter) is a pay-per-use add-on on paid plans: each X post uses X credits (1 for a plain post, 10 for a post with a link, +1 per image or video) from the plan's monthly X credits, then from top-up credits; a post without enough credits is not sent to X and its result says how to get more. An X thread: per_platform.x.thread is the list of posts after per_platform.x.text (up to 25, each at most 280 characters as X counts them, a link counts 23); per_platform.x.reply is one more post under the last one, the usual place for a link. Each post of a thread or reply is an X post: it uses credits by the same rule and counts toward the daily X limit, and the whole chain is reserved before anything is sent. Write a thread only when the user asks for one. The X result then has thread.tweets (every post's id), thread_url, and thread.status: complete, or pending when X refused a later post (the first post stays published and PostWire retries the rest on its own). If the brand's approval rules or a limit on this API key or connected app hold the post, nothing is published: the result has status "pending_approval", the post's id and approval_id, who was notified and a review link, and the post goes out once a person approves it from the emailed link or the PostWire dashboard — an AI assistant or an API key cannot approve it. A limit on this key or app can also refuse a post with code key_network_not_allowed, key_brand_not_allowed or key_monthly_cap_reached.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Post text used for every platform that has no per_platform draft. | |
| media | No | Several images (or images and videos) in one post, in order: an Instagram carousel (up to 10), TikTok photo post (up to 35 images; PNG is converted to JPEG automatically for Instagram and TikTok), Bluesky (up to 4 images), Mastodon (up to 4), LinkedIn (up to 20 images, or one PDF document). Networks that take one item get the first. Each item: { url, type: image|video|document, alt? }. | |
| title | No | Title, used by YouTube. | |
| privacy | No | Who can see the TikTok and YouTube posts: public (everyone), unlisted (YouTube), friends (TikTok mutual followers) or private (only the account owner). TikTok asks that the account owner choose this for each TikTok post. Without it a TikTok post goes out private and YouTube uses the channel default. | |
| brand_id | No | Which brand's accounts to use. Omit to use the default brand. | |
| photo_url | No | Public https URL of an image. | |
| platforms | Yes | Platforms to publish to, all in one call, e.g. ["linkedin","bluesky"]. | |
| video_url | No | Public https URL of a video. Required for YouTube; TikTok takes a video or photos. | |
| per_platform | No | Per-platform drafts: { "<platform>": { "text": "…", "title": "…", "tags": ["…"] } }. X, Bluesky and Mastodon also take "thread" (the posts after text, in order, each a reply to the one before; media stays on the first post). LinkedIn, X, Bluesky and Mastodon take "first_comment" (posted by the author right under the post, or under the last post of a thread: the place for the link). X also calls it "reply". Pass the thread and first_comment that generate_posts returned as they are. | |
| idempotency_key | No | Optional unique key; a repeat with the same key within 24 h is refused instead of posted twice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring a destructive, non-readOnly, open-world operation, the description adds substantial behavioral detail beyond them: irreversible public posting, duplicate refusal windows, platform connection requirements, per-platform media rules, brand ambiguity errors, approval holds, X credit accounting, thread reservation behavior, processing statuses, and specific error codes. This is unusually transparent for a complex publishing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded, but the description is a very long, dense block with numerous run-on sentences and nested details. The complexity justifies depth, yet the structure could be much tighter and more scannable without losing essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the return shape, including posted, published_to, results fields, and thread results. It also covers error cases, held networks, approval flows, X credit usage, and platform-specific processing statuses, making it complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description still adds useful cross-parameter semantics: one text for all platforms or separate per_platform drafts, YouTube/TikTok/Instagram media requirements, the carousel threshold, thread and first_comment behavior, and the idempotency_key duplicate window. Much of this is also in the schema, but the fallback and interaction rules are clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Publishes a post immediately and publicly to the listed platforms.' The word 'immediately' clearly distinguishes it from sibling tools such as schedule_post and bulk_schedule, and it names the scope of platforms and account context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use this tool: for immediate public publishing and when the user asks to post now. It also lists many prerequisites and exclusions, such as required platform connections, platform-specific media needs, and approval holds. It does not explicitly name schedule_post as the alternative for later posting, so it falls short of a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes new drafts, one per platform, that reuse the structure, opening type, length, format and tone of one of the account's published posts, on a new topic or a new angle; the reference post's sentences are not reused. Nothing is published or scheduled. Takes the id of a published post of the account (the ids that the account's post performance results list). Counts toward the account's daily AI limit. Available depending on the account's plan. Returns { drafts: { : { text, title?, tags? } }, reference }.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional new topic. Omit for a new angle on the same subject. | |
| post_id | Yes | The id of the reference post: one of the account's published posts, as listed in its post performance results. | |
| platforms | No | Platforms to write for. Default: the reference post's platform. | |
| brand_voice | No | Optional tone or style notes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false). The description goes well beyond them by disclosing that nothing is published or scheduled, that the call consumes the account's daily AI quota, and that availability is plan-gated – exactly the quota and side-effect context an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph that is well front-loaded: what it writes and what it reuses comes first, constraints and return shape last. There is minor redundancy – the post_id provenance is stated in both the description and the schema, and the sentence chain is long – but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by inlining the return shape ({ drafts: { <platform>: { text, title?, tags? } }, reference }). Combined with the quota, plan-gating and no-publish disclosures, an agent has everything needed to call this tool correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so post_id, topic, platforms and brand_voice are already documented, including the platform default. The description largely restates the schema (published-post ids from performance results, new topic vs new angle) without adding format or interaction detail, so the schema-baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Writes new drafts, one per platform') and pins down the mechanism precisely: reuse of structure, opening type, length, format and tone from a reference post, with an explicit negative ('the reference post's sentences are not reused'). It is distinguishable from generate_posts in substance, but it never names that sibling, so the differentiation is left for the agent to infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states clear operating context: the required id must come from the account's post performance results, nothing is published or scheduled, it counts toward the daily AI limit, and availability depends on the plan. What is missing is explicit routing against alternatives such as generate_posts or plan_week, so the when-to-use-this-instead signal is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queues a post to be published at a future time (run_at, ISO 8601 with timezone, up to 365 days ahead), or in the brand's next free queue slot (run_at "next_slot": the earliest weekly slot all its platforms share that no other waiting post of the brand uses; the result gives the time chosen) through the connected accounts. Takes the same content fields as publishing now. Every platform must already be connected and media must suit each platform, or it is refused now instead of failing later. When a platform is connected in more than one brand and brand_id is omitted, nothing is queued and the error lists the brands. Returns the queued item with its id and, for each platform, the handle and brand it will publish to. The plan sets how many posts can wait in the queue at once (Free: 3): past that the post is not refused but saved as held (code queue_limit, status held) — kept, never published on the current plan, and scheduled automatically when the plan is upgraded; the result then also gives that plan, its price and a checkout link. On a plan with a networks-per-post limit (Free: 2) only the first platforms are published when it runs; the result names the others in held_networks. A queued or held post can be canceled before it runs. X (Twitter) is a pay-per-use add-on on paid plans: each X post uses X credits (1 for a plain post, 10 for a post with a link, +1 per image or video) from the plan's monthly X credits, then from top-up credits; a post without enough credits is not sent to X and its result says how to get more. An X thread: per_platform.x.thread is the list of posts after per_platform.x.text (up to 25, each at most 280 characters as X counts them, a link counts 23); per_platform.x.reply is one more post under the last one, the usual place for a link. Each post of a thread or reply is an X post: it uses credits by the same rule and counts toward the daily X limit, and the whole chain is reserved before anything is sent. Write a thread only when the user asks for one. The X result then has thread.tweets (every post's id), thread_url, and thread.status: complete, or pending when X refused a later post (the first post stays published and PostWire retries the rest on its own). If the brand's approval rules or a limit on this API key or connected app hold the post, nothing is published: the result has status "pending_approval", the post's id and approval_id, who was notified and a review link, and the post goes out once a person approves it from the emailed link or the PostWire dashboard — an AI assistant or an API key cannot approve it. A limit on this key or app can also refuse a post with code key_network_not_allowed, key_brand_not_allowed or key_monthly_cap_reached.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Post text for platforms without a per_platform draft. | |
| label | No | Optional short label shown in the PostWire queue. | |
| media | No | Several images (or images and videos) in one post, in order: an Instagram carousel (up to 10), TikTok photo post (up to 35 images; PNG is converted to JPEG automatically for Instagram and TikTok), Bluesky (up to 4 images), Mastodon (up to 4), LinkedIn (up to 20 images, or one PDF document). Networks that take one item get the first. Each item: { url, type: image|video|document, alt? }. | |
| title | No | Title, used by YouTube. | |
| run_at | Yes | When to publish: ISO 8601 with offset, e.g. "2026-10-01T09:00:00-05:00", or "next_slot" for the brand's next free queue slot. | |
| privacy | No | Who can see the TikTok and YouTube posts: public (everyone), unlisted (YouTube), friends (TikTok mutual followers) or private (only the account owner). TikTok asks that the account owner choose this for each TikTok post. Without it a TikTok post goes out private and YouTube uses the channel default. | |
| brand_id | No | Brand whose accounts to use; omit for the default brand. | |
| timezone | No | With run_at next_slot: the IANA timezone to read the slots in when the brand has none saved, e.g. "America/Lima". | |
| photo_url | No | Public https URL of an image. | |
| platforms | Yes | Platforms to publish to. | |
| video_url | No | Public https URL of a video (YouTube needs one; TikTok takes a video or photos). | |
| per_platform | No | Per-platform drafts: { "<platform>": { "text": "…" } }. X, Bluesky and Mastodon also take "thread": ["…"] (the posts after text; X max 25, Bluesky and Mastodon max 9 more, each within the network's limit). LinkedIn, X, Bluesky and Mastodon take "first_comment": "…" (posted by the author under the post, or under the last post of a thread: the place for the link; on X it is an X post and uses credits). X also calls it "reply". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnly=false, openWorld=true, idempotent=false, destructive=false, so the description carries the behavioral load and does so richly: queue caps (Free: 3) with held/queue_limit behavior, networks-per-post limits (held_networks), X credit pricing, thread reservation semantics, approval gating (pending_approval, AI/API key cannot approve), and specific refusal codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is well front-loaded with the core purpose, but the body is an extremely dense run-on bundling pricing, thread rules, approval flows, and error codes into one block. Nearly all content is relevant, yet the lack of structure hurts scanability for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps up to describe returns: the queued item with id plus per-platform handle and brand, held status with plan/price/checkout link, thread.tweets/thread_url/thread.status, and pending_approval with approval_id and review link. Given the 12-parameter, nested-object tool, coverage is essentially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains run_at 'next_slot' resolution and the shared-weekly-slot rule, plus thread limits (X max 25 posts, 280 chars as X counts, a link counts 23) and reply/first_comment equivalence. These go beyond the terse schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (queues) and resource (a post to publish at a future time) plus the two modes: an explicit run_at or the brand's next free queue slot. It clearly distinguishes itself from immediate publishing by noting it takes 'the same content fields as publishing now,' so an agent can separate it from post_to_social 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives strong when-to-use context: choose next_slot for the earliest shared free slot, only write a thread 'when the user asks for one,' and note that queued/held posts can be canceled before they run. It does not name sibling tools (post_to_social, bulk_schedule, cancel_scheduled_post) explicitly, leaving the routing slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_connect_link1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]create_recurring_post1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]generate_posts1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]get_post_performance1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]get_post_status1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]plan_week1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]post_to_social8 fields changedInput schema / properties / per_platform / additionalProperties / properties / canonical_urlAdded value: +{
+ "description": "Dev.to and Hashnode: where the article was first published.",
+ "format": "uri",
+ "type": "string"
+}Input schema / properties / per_platform / additionalProperties / properties / first_commentAdded value: +{
+ "description": "LinkedIn, X, Bluesky, Mastodon: the author's first comment, posted right after the post (under the last post of a thread) — where the link goes. Bluesky <= 300 characters, Mastodon <= 500, X <= 280 (an X post: it uses X credits), LinkedIn <= 1250. Other networks report it as not posted.",
+ "maxLength": 1500,
+ "type": "string"
+}Input schema / properties / per_platform / additionalProperties / properties / reply / descriptionPrevious value: -"X only: one post under the last post of the chain, e.g. the link."New value: +"X only: the same as first_comment — one post under the last post of the chain, e.g. the link."Input schema / properties / per_platform / additionalProperties / properties / statusAdded value: +{
+ "description": "Blogs: publish now, or save a draft on the blog.",
+ "enum": [
+ "publish",
+ "draft"
+ ],
+ "type": "string"
+}Input schema / properties / per_platform / additionalProperties / properties / summaryAdded value: +{
+ "description": "Blogs: the article's excerpt / meta description.",
+ "maxLength": 400,
+ "type": "string"
+}Input schema / properties / per_platform / additionalProperties / properties / thread / descriptionPrevious value: -"X only: the posts of a thread after text, each a reply to the one before (max 25, each <= 280 as X counts)."New value: +"X, Bluesky, Mastodon: the posts of a thread after text, each a reply to the one before. X: max 25, each <= 280 as X counts. Bluesky: max 9 (10 posts in all), each <= 300 characters. Mastodon: max 9, each <= 500 characters or the server's own limit. Each result lists every post's URL (thread.posts); if a later post is refused, the earlier ones stay published and thread.not_posted lists the rest."Input schema / properties / per_platform / descriptionPrevious value: -"Per-platform drafts: { \"<platform>\": { \"text\": \"…\", \"title\": \"…\", \"tags\": [\"…\"] } }. X also takes \"thread\" (the posts after text, in order) and \"reply\" (one post under the last one, e.g. the link)."New value: +"Per-platform drafts: { \"<platform>\": { \"text\": \"…\", \"title\": \"…\", \"tags\": [\"…\"] } }. X, Bluesky and Mastodon also take \"thread\" (the posts after text, in order, each a reply to the one before; media stays on the first post). LinkedIn, X, Bluesky and Mastodon take \"first_comment\" (posted by the author right under the post, or under the last post of a thread: the place for the link). X also calls it \"reply\". Pass the thread and first_comment that generate_posts returned as they are."Input schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]replicate_top_post1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]schedule_post2 fields changedInput schema / properties / per_platform / descriptionPrevious value: -"Per-platform drafts: { \"<platform>\": { \"text\": \"…\" } }. X also takes \"thread\": [\"…\"] (the posts after text, max 25) and \"reply\": \"…\" (one post under the last one)."New value: +"Per-platform drafts: { \"<platform>\": { \"text\": \"…\" } }. X, Bluesky and Mastodon also take \"thread\": [\"…\"] (the posts after text; X max 25, Bluesky and Mastodon max 9 more, each within the network's limit). LinkedIn, X, Bluesky and Mastodon take \"first_comment\": \"…\" (posted by the author under the post, or under the last post of a thread: the place for the link; on X it is an X post and uses credits). X also calls it \"reply\"."Input schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "wordpress",
+ "devto",
+ "hashnode",
+ "slack",
+ "nostr",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]bulk_schedulecreate_recurring_postget_upgrade_link1 field changedInput schema / properties / intervalAdded value: +{
+ "description": "Billing period of the link: month (default) or year (20% off, billed once a year).",
+ "enum": [
+ "month",
+ "year"
+ ],
+ "type": "string"
+}get_x_credits2 fields changedInput schema / properties / replyAdded value: +{
+ "description": "Optional: a reply under the post (or the thread), priced with it.",
+ "maxLength": 1000,
+ "type": "string"
+}Input schema / properties / threadAdded value: +{
+ "description": "Optional: the posts of a thread after text, to price the whole thread.",
+ "items": {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ "maxItems": 25,
+ "type": "array"
+}post_to_social3 fields changedInput schema / properties / per_platform / additionalProperties / properties / replyAdded value: +{
+ "description": "X only: one post under the last post of the chain, e.g. the link.",
+ "maxLength": 1000,
+ "type": "string"
+}Input schema / properties / per_platform / additionalProperties / properties / threadAdded value: +{
+ "description": "X only: the posts of a thread after text, each a reply to the one before (max 25, each <= 280 as X counts).",
+ "items": {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ "maxItems": 25,
+ "type": "array"
+}Input schema / properties / per_platform / descriptionPrevious value: -"Per-platform drafts: { \"<platform>\": { \"text\": \"…\", \"title\": \"…\", \"tags\": [\"…\"] } }."New value: +"Per-platform drafts: { \"<platform>\": { \"text\": \"…\", \"title\": \"…\", \"tags\": [\"…\"] } }. X also takes \"thread\" (the posts after text, in order) and \"reply\" (one post under the last one, e.g. the link)."schedule_post1 field changedInput schema / properties / per_platform / descriptionPrevious value: -"Per-platform drafts: { \"<platform>\": { \"text\": \"…\" } }."New value: +"Per-platform drafts: { \"<platform>\": { \"text\": \"…\" } }. X also takes \"thread\": [\"…\"] (the posts after text, max 25) and \"reply\": \"…\" (one post under the last one)."get_post_status3 fields changedInput schema / properties / id / descriptionPrevious value: -"The post id returned when it was published on that platform."New value: +"The post id returned when it was published on that platform, or the id PostWire returned for a post waiting for approval or scheduled."Input schema / properties / platform / descriptionPrevious value: -"Platform of the post, e.g. \"tiktok\"."New value: +"Platform of the post, e.g. \"tiktok\". Can be omitted for a post waiting for approval or scheduled."Input schema / requiredPrevious value: -[
- "platform",
- "id"
-]New value: +[
+ "id"
+]create_connect_link1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]generate_posts1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]get_post_performance1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]get_post_status1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]get_x_creditsplan_week1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]post_to_social1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]replicate_top_post1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]schedule_post1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram",
+ "x"
+]make_video_from_textpost_to_social1 field changedInput schema / properties / privacy / descriptionPrevious value: -"Who can see the TikTok and YouTube posts: public, unlisted (YouTube), friends (TikTok mutual followers) or private. Without it a TikTok post goes out private (only the account owner sees it) and YouTube uses the channel default — send \"public\" to publish publicly."New value: +"Who can see the TikTok and YouTube posts: public (everyone), unlisted (YouTube), friends (TikTok mutual followers) or private (only the account owner). TikTok asks that the account owner choose this for each TikTok post. Without it a TikTok post goes out private and YouTube uses the channel default."schedule_post1 field changedInput schema / properties / privacy / descriptionPrevious value: -"Who can see the TikTok and YouTube posts: public, unlisted (YouTube), friends (TikTok mutual followers) or private. Without it a TikTok post goes out private (only the account owner sees it) and YouTube uses the channel default — send \"public\" to publish publicly."New value: +"Who can see the TikTok and YouTube posts: public (everyone), unlisted (YouTube), friends (TikTok mutual followers) or private (only the account owner). TikTok asks that the account owner choose this for each TikTok post. Without it a TikTok post goes out private and YouTube uses the channel default."get_post_performancereplicate_top_postschedule_post3 fields changedInput schema / properties / run_at / descriptionPrevious value: -"When to publish, ISO 8601 with offset, e.g. \"2026-10-01T09:00:00-05:00\"."New value: +"When to publish: ISO 8601 with offset, e.g. \"2026-10-01T09:00:00-05:00\", or \"next_slot\" for the brand's next free queue slot."Input schema / properties / run_at / formatRemoved value: -"date-time"Input schema / properties / timezoneAdded value: +{
+ "description": "With run_at next_slot: the IANA timezone to read the slots in when the brand has none saved, e.g. \"America/Lima\".",
+ "type": "string"
+}post_to_social2 fields changedInput schema / properties / privacy / descriptionPrevious value: -"YouTube visibility. Default: the platform's default."New value: +"Who can see the TikTok and YouTube posts: public, unlisted (YouTube), friends (TikTok mutual followers) or private. Without it a TikTok post goes out private (only the account owner sees it) and YouTube uses the channel default — send \"public\" to publish publicly."Input schema / properties / privacy / enumPrevious value: -[
- "public",
- "unlisted",
- "private"
-]New value: +[
+ "public",
+ "unlisted",
+ "friends",
+ "private"
+]schedule_post1 field changedInput schema / properties / privacyAdded value: +{
+ "description": "Who can see the TikTok and YouTube posts: public, unlisted (YouTube), friends (TikTok mutual followers) or private. Without it a TikTok post goes out private (only the account owner sees it) and YouTube uses the channel default — send \"public\" to publish publicly.",
+ "enum": [
+ "public",
+ "unlisted",
+ "friends",
+ "private"
+ ],
+ "type": "string"
+}create_connect_link1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram"
+]generate_posts1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram"
+]get_post_status1 field changedInput schema / properties / platform / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram"
+]plan_week1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram"
+]post_to_social1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram"
+]schedule_post1 field changedInput schema / properties / platforms / items / enumPrevious value: -[
- "telegram",
- "bluesky",
- "mastodon",
- "discord",
- "tiktok",
- "youtube",
- "reddit",
- "linkedin",
- "facebook",
- "instagram",
- "x"
-]New value: +[
+ "telegram",
+ "bluesky",
+ "mastodon",
+ "discord",
+ "tiktok",
+ "youtube",
+ "reddit",
+ "linkedin",
+ "facebook",
+ "instagram"
+]Schedule, generate and publish social posts to X, LinkedIn, Instagram, Threads and YouTube
Schedule and publish videos to TikTok, YouTube, Instagram and 5 more networks.
Post and schedule to Instagram, TikTok, YouTube, LinkedIn, X, Threads, Bluesky, Pinterest, Facebook.
Generate AI short-form videos and auto-publish them to TikTok, YouTube, Instagram, Facebook and X.
Add one secure layer between your agents and this server.
