Writes a native post per network from one idea and publishes it: TikTok, Instagram, YouTube & more
Scored across 15 tools
Each tool serves a clear, distinct purpose—brand management, connection, upload, generation, publishing, scheduling, and status—with no overlapping operations. The close pair schedule_post and plan_week are differentiated by scope (single vs. weekly batch) and plan_week includes AI generation.
All tool names follow a consistent verb_noun pattern (cancel_scheduled_post, create_brand, get_post_status, list_platforms) in snake_case. The only slight deviation is my_account and plan_week, but they still fit the overall style and are unambiguous.
15 tools is well-scoped for a social media management server covering account, brands, connections, uploads, AI drafting, scheduling, and publishing. Each tool contributes to a complete workflow without redundancy or bloat.
The core lifecycle is well covered: connect accounts, upload media, generate drafts, publish, schedule, cancel, and check status. Minor gaps include no brand update/delete, no account disconnect tool, and no listing of published posts beyond individual status checks, but these are edge cases that don't break primary workflows.
Cancels a queued or held post so it is never published. 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 mark the tool as destructive and idempotent. The description adds meaningful behavioral context by clarifying the destructive outcome ('never published') and the critical timing limitation, which goes beyond what the annotations 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?
Three short sentences with no filler. The core action and critical constraints are front-loaded, and every sentence contributes meaningful 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?
For a simple one-parameter tool with rich annotations and no output schema, the description covers the action, the timing restriction, and the outcome. Nothing essential is missing for an agent to decide whether to call 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 coverage is 100%, and the single parameter 'id' is already documented as 'Scheduled post id.' The description restates this without adding new detail about id format, source, or validation, so it adds minimal value beyond the 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?
The description states a specific verb ('cancels') and resource ('queued or held post'), and clearly frames the outcome ('so it is never published'). It is immediately distinguishable from sibling tools like schedule_post and list_scheduled_posts.
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 an explicit usage constraint: 'Only works before it starts publishing.' This tells an agent when the tool is applicable, though it does not name alternative tools or exclusion scenarios.
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 a social account (TikTok, YouTube, LinkedIn, Bluesky…) to their PostWire account. Nothing is connected until the user completes it on the page. With brand_id the account is connected to that brand. Returns the url of that page.
| 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?
Annotations indicate a non-readonly, non-destructive operation. The description adds crucial behavioral details: the link expires in one hour, nothing is connected until the user completes the action, and the return value is the URL. This goes beyond the 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?
The description is three concise sentences with no filler, front-loading the primary purpose. Every sentence contributes 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?
For a simple tool, it covers the essential aspects: purpose, expiry, completion requirement, and return value. No output schema exists, but the description adequately sets expectations.
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 covers both parameters with descriptions, but the description adds behavioral nuance: with brand_id the account connects to that brand, and omitting platform lets the user choose on the page. This enhances the schema's information.
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') and resource ('one-hour link to connect a social account'), clearly distinguishing it from sibling create tools like create_brand and create_upload_link. The purpose is 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 provides clear context on when to use the tool (to connect a social account) and explains the optional brand_id and platform parameters with their effects. It doesn't explicitly exclude alternatives, but the purpose is distinct enough.
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 50 MB). The file is kept in the account's PostWire media storage for 30 days. Returns the page url and an upload_id for checking the upload's status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the minimal annotations by disclosing important behavior: the link is single-use, valid for 24 hours, accepts specific formats up to 50 MB, stores the file for 30 days, and returns both a page URL and an upload_id. This gives the agent a clear model of side effects and lifecycle without contradicting 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?
Three focused sentences with no filler. Key facts are front-loaded: the action, the link validity, and the purpose. File formats and size are condensed into a parenthetical, keeping the description scannable.
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 no-parameter tool with no output schema, the description is complete: it explains what the tool does, what constraints apply, and what the caller receives. Nothing an agent needs to select or invoke this tool 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?
The tool has zero parameters, so there is nothing for the description to explain about argument semantics. Per baseline, this is effectively a non-issue; the description still clarifies what the returned upload_id is used for, which is more than required.
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 ('creates') and resource ('single-use link to a PostWire page') and clearly explains the intended purpose: letting a user upload a photo or video. It is specific enough to distinguish itself from siblings like create_connect_link or get_uploaded_file.
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 to use the tool: when the agent needs the user to pick and upload a photo or video from any device. It does not explicitly exclude alternatives or mention sibling tools, but the use case is unambiguous and no conflicting sibling is implied.
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 and X). Nothing is published. Returns { drafts: { : { text, title?, tags? } } } and, if the writer skipped a platform, { missing: [...] }. 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 already declare readOnlyHint and destructiveHint, so the tool is known to be safe. The description adds valuable context beyond annotations: the daily AI limit and the possibility of skipping platforms (returned in 'missing'). It reinforces the non-publishing behavior. No contradictions with 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?
The description is concise and well-structured. It front-loads the main action and adaptation rules, then covers return format and side effects in a second sentence. Every sentence carries meaningful information with no redundancy.
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 the tool has no output schema, the description provides a clear return format including the structure of drafts and the missing array. It explains adaptation per platform, the non-publishing nature, and the daily limit. An agent has enough information to call and interpret the result 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 parameters are already fully documented. The description does not add parameter-specific semantics beyond what the schema provides; it focuses on tool behavior. This meets the baseline for high coverage, adding no extra value for parameters.
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 clearly states the tool writes one draft per platform from a single idea, adapted to each network's rules. It explicitly says 'Nothing is published', distinguishing it from sibling publishing tools like post_to_social. The verb 'Writes' and resource 'draft' are specific, and the scope is well-defined.
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 provides clear context that this tool is for drafting, not publishing, which implicitly differentiates it from siblings. It also mentions the daily AI limit, which is a usage consideration. However, it does not explicitly name alternative tools 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.
Returns the status and link of a published post, by platform and the post id returned when it was published. For TikTok and YouTube it asks the platform for the processing status and returns the public link once there is one. 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. | |
| brand_id | No | Brand whose account published it; omit for the default brand. | |
| platform | Yes | Platform of the post, e.g. "tiktok". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: for TikTok/YouTube it queries the platform for processing status and returns the public link once available; for immediate-publish networks it returns 'published' and the link where the id allows it, including private Telegram channels via t.me/c/<channel>/<message>. This goes beyond the 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?
The description is a single, information-dense paragraph. It front-loads the core purpose and then adds platform-specific details. It could be slightly more structured (e.g., separating the general behavior from platform-specific notes), but it earns its length with useful distinctions.
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 status-checking tool with 100% schema coverage and no output schema, the description is largely complete. It explains what the tool returns (status and link), how it behaves per platform, and the meaning of the id parameter. It doesn't describe the exact shape of the response, but without an output schema that's a minor gap.
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 documents all three parameters. The description adds context about the 'id' being the post id returned at publish time and explains platform-specific behavior, but it doesn't add much beyond the schema for parameter semantics. Baseline 3 is appropriate.
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 clearly states the tool's function: it returns the status and link of a published post, keyed by platform and post id. It distinguishes itself from sibling tools like post_to_social and schedule_post by focusing on retrieval of status/link for already-published posts.
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 explains when to use this tool: to check the status and link of a published post, and it differentiates behavior by platform (TikTok/YouTube vs immediate-publish networks). It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it over publishing/scheduling tools.
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), 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive DNA, and the description adds critical behavioral context: the returned link opens a Stripe payment page, nothing is charged unless the user pays, and existing subscribers see the dashboard plan page. This goes well beyond the annotations and clarifies the external side effects.
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 dense, front-loaded sentences cover the main return content and the critical side-effect behavior without fluff. Every clause earns its place, and the most important information appears first.
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 single-optional-parameter tool with no output schema, the description is complete: it explains what is returned, how the optional parameter changes the result, and what happens when the link is opened. No essential calling information 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 the baseline is 3. The description's parameter-related explanation ('the next plan up when none is given') directly mirrors the schema description for the optional plan field)Skip no additional meaning beyond the 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?
The description states a specific verb and resource: it 'Returns PostWire's paid plans' including price, inclusions, current plan, and a checkout link. It clearly distinguishes the tool as a plan/upgrade helper rather than a general account or post-management tool.
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 conveys the use case: showing plans and obtaining an upgrade/checkout link, with an explicit behavior for omitting the plan parameter. It does not name alternatives or explicit exclusions, but the context is unambiguous enough for an agent to select it appropriately.
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 24 hours 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 declare readOnlyHint=true and idempotentHint=true, so the description need not repeat safety traits. It adds valuable behavioral context: the status transition from 'waiting' to 'done', the 24-hour validity of the media_url, and the fields returned (kind, size, content type). This goes beyond the annotations and helps the agent understand expected behavior.
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 sentence that packs relevant details: the purpose, the statuses, and the returned fields. It is front-loaded with the main purpose and includes necessary specifics without fluff. It is somewhat dense but remains readable and efficient.
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 the simple single-parameter tool with no output schema, the description fully explains what the agent should expect: the possible statuses and the fields returned when done. It also mentions the URL validity period, which is useful. It does not cover error conditions, but that is not critical for this straightforward operation. The description is complete enough for correct invocation.
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% (the upload_id parameter has a description stating it is the ID returned with the upload link). The description reinforces this by saying 'by upload_id' and mentioning the upload link, but adds little new meaning. Since the schema already documents the parameter adequately, a baseline score of 3 is appropriate.
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 clearly states the tool's purpose: it returns the status of a file uploaded via a PostWire upload link, identified by upload_id. It specifies the verb, resource, and how the resource is identified. It also differentiates from siblings like create_upload_link (which creates the link) and get_post_status (which checks post status) by focusing on file upload status.
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: it is used after obtaining an upload_id from an upload link. It explains the polling behavior (waiting vs done) which implies when to call it. However, it does not explicitly state when NOT to use it or compare it to alternatives, though the context is strong enough for an agent to infer its usage.
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 PostWire can publish to and, for each, whether it connects with OAuth or with credentials. 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, covering the safety profile. The description adds one behavioral fact beyond annotations: that no account is needed. This is useful but minimal; it doesn't describe return format or any edge cases, though for a read-only list operation the burden is low.
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 two concise sentences. The core action is front-loaded, and the additional detail about OAuth vs credentials and no-account requirement is placed efficiently without wasted words.
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, no output schema, and annotations covering safety, the description fully specifies what the tool does and what it returns (list of platforms with connection method). It also clarifies the account requirement, so an agent has all needed information to invoke it 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?
The input schema has zero parameters, so schema coverage is trivially 100%. Per rubric, a baseline of 4 applies when no parameters exist; the description adds no parameter-specific information because none 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 states a clear verb ('Lists') and resource ('social platforms PostWire can publish to'), and adds specific detail about the output (whether each connects via OAuth or credentials). This distinguishes it from siblings like list_scheduled_posts, which are clearly about a different resource.
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 explicitly notes 'Does not need a PostWire account,' which signals when this tool is appropriate (e.g., pre-authentication discovery). It does not explicitly list alternatives, but the sibling set is diverse and this tool's purpose is self-evident, so the guidance is sufficient.
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, publishing, done, failed 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 this as read-only, idempotent, and non-destructive, so the description only needs to add behavioral context beyond that. It adds the specific statuses covered and the fields returned, which is meaningful. Pagination and ordering are not mentioned, but that is a minor gap given the strong annotation profile.
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 front-loaded with the verb and resource; every clause adds useful detail (statuses, returned fields, optional time range). There is no filler or redundancy.
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 simple read-only list tool with two optional parameters and no output schema, the description is sufficient: it names the result fields and statuses and points to the optional filters. An agent has enough information to invoke it correctly without additional 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 description coverage is 100%, and both parameters are fully documented with their date-time semantics ('Only posts scheduled before this time' / 'at or after this time'). The description's 'Optional from/to' only restates the schema rather than adding new meaning, 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 ('Lists') with the resource 'the account's scheduled posts' and enumerates the six included statuses, which separates it from sibling tools like get_post_status and cancel_scheduled_post. The returned fields (id, time, platforms, status) further pin down exactly what the operation does.
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: it lists posts across all statuses and mentions the optional from/to filters, so an agent knows when to call it. However, it does not explicitly name alternatives or exclusions (e.g., when to prefer get_post_status), leaving some inference to the agent.
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), 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. When no social account is connected, it includes a one-hour link to connect one.
| 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, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it specifies exactly what content appears (plan, usage limits, brands, connected accounts) and describes conditional behavior (upgrade link when a limit is ≥80%, connect link when no social account). This is rich transparency.
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 three sentences but packs all essential information without redundancy. It fronts the core purpose, then lists contents, then notes conditional additions. Every sentence earns its place; nothing extraneous.
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 burden of explaining return values. It does so comprehensively: plan, usage against limits, brands, connected accounts with details, and conditional upgrade/connect links. An agent can predict the output structure accurately. No gaps.
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 has zero parameters, and the empty schema covers 100% of them. Per the guidelines, the baseline for 0 parameters is 4. The description adds no parameter information because there are none, but it doesn't need to.
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 is specific: 'Shows the signed-in PostWire account' clearly identifies the verb and resource. It expands on what is shown (plan, usage, brands, connected accounts) and mentions conditional outcomes, making it easily distinguishable from sibling tools like list_brands or list_platforms.
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 communicates the tool's scope: it provides an overall account snapshot. No explicit alternatives are mentioned, but none are needed since no sibling duplicates this functionality. The context is unambiguous enough for an agent to know when to call it.
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. Each day counts as one AI draft toward the daily AI limit. Days that do not fit in the plan's monthly post limit are saved as held (never published on the current plan) and are scheduled automatically when the plan is upgraded; the result then also gives that plan, its price and a checkout link. 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.
| 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?
Beyond annotations (readOnlyHint=false, destructiveHint=true), the description discloses extensive behavioral traits: posts are published publicly, each day counts toward an AI limit, days exceeding the monthly post limit become 'held' and auto-schedule on upgrade (with pricing/checkout returned), and queued items can be canceled. These details give the agent a realistic expectation of side effects and resource costs.
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 dense paragraph but front-loads the core action and packs every sentence with relevant facts (refusals, connection requirement, AI limit, held-item handling, return format, cancellation). It is not padded, though breaking it into structured points would improve readability further.
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 covers what the tool returns (queued and held items with id, time, preview) and explains the upgrade behavior and cancellation option. It covers prerequisites, constraints, side effects, and limits, leaving nothing essential missing for an agent to call and interpret 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 coverage is 100%, but the description adds semantic value beyond the schema. It clarifies that 'platforms' excludes video/photo-required options (TikTok, YouTube, Instagram) despite being in the enum, and explains that 'days' interacts with monthly post limits (excess becomes held). This goes beyond basic type/range 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?
The description clearly states the tool's action (writes and queues posts), its resource (one post per day for 1-7 days across multiple platforms), and its scope (published publicly starting tomorrow). It also distinguishes itself from siblings by explicitly refusing video/photo-required platforms, making its purpose 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?
The description provides a key prerequisite ('Every platform must already be connected') and a constraint ('Text only: platforms that require a video or photo are refused'), which helps agents decide when this tool is appropriate. However, it never mentions alternative tools or explicitly states when not to use it (e.g., when video content is needed), leaving that inference to the agent.
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; when the monthly post limit stops a platform, the result also names the plan that raises it, its price and a checkout link.
| 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 JPEG/WebP images), 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 | YouTube visibility. Default: the platform's 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": ["…"] } }. | |
| 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?
Annotations only indicate a destructive, non-read-only operation, so the description carries the behavioral burden. It adds irreversibility, fail-closed behavior when platforms are missing or brand_id is ambiguous, duplicate-payload refusal, and the monthly-limit upgrade response. This goes well beyond what annotations provide.
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 long, but it earns its length given 10 parameters and complex cross-platform rules. The main action and irreversibility are front-loaded, and while the dense clauses could be bulleted, 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?
With no output schema, the description compensates by documenting the exact return shape, error cases, brand ambiguity, connection prerequisites, and plan-upgrade details. An agent has enough information to invoke the tool correctly and interpret failures.
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%, but the description adds platform-specific meaning not inferable from the schema alone: YouTube requires video_url, TikTok accepts video_url or photos, Instagram carousels need two or more media items, and idempotency is tied to same-payload detection. It also clarifies the single-text versus per_platform draft model.
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 action and resource: 'Publishes a post immediately and publicly to the listed platforms' through connected PostWire accounts. It distinguishes itself from sibling scheduling tools by emphasizing immediate publication and irreversibility.
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 to call it: platforms must already be connected, one text can be shared or per-platform drafts used, and media requirements differ by platform. It does not explicitly name schedule_post as the alternative for delayed publishing, but 'immediately' and 'cannot be withdrawn' make the intended use clear.
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 publicly at a future time (run_at, ISO 8601 with timezone, up to 365 days ahead) 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. A queued post can be canceled before it runs.
| 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 JPEG/WebP images), 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". | |
| brand_id | No | Brand whose accounts to use; omit for the default brand. | |
| 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": "…" } }. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutating/destructive behavior (readOnlyHint false, destructiveHint true), and the description adds substantial behavioral detail beyond that: the 365-day lookahead cap, upfront validation instead of late failure, the multi-brand refusal error, the returned payload shape (id, handle, brand), and cancelability. This is exactly the kind of risk-relevant context that helps an agent use the tool correctly.
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?
Four dense sentences, each carrying distinct operational information: core action, preconditions/validation, edge case behavior, and return value plus cancellation. No filler or redundancy, and the most important scheduling distinction is front-loaded.
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 10 parameters, nested objects, and no output schema, this description covers the crucial gaps: what the return value looks like, how errors manifest, what must be verified before calling, and how to undo the action. Combined with the already-detailed schema, an agent has everything needed to invoke schedule_post correctly and interpret its results.
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 schema has 100% description coverage with rich parameter details, so the baseline is 3. The description adds meaningful value on top by specifying the run_at maximum horizon ('up to 365 days ahead') and by explaining the brand_id omission behavior across multiple brands, which the schema does not fully convey. It doesn't need to repeat parameter definitions already in the 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?
The description opens with a specific verb and resource: 'Queues a post to be published publicly at a future time', which clearly separates it from immediate publishing and from cancellation. It emphasizes future scheduling as the core differentiator against siblings like post_to_social and cancel_scheduled_post, so an agent can immediately recognize its role.
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 clearly implies scheduling for future publishing versus immediate publishing, and it lists key conditions for safe use: connected platforms, per-platform media suitability, and the brand ambiguity rule. It doesn't explicitly name 'use post_to_social to publish now', but the future-time framing and connection/refusal guidance give strong contextual direction.
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.
post_to_social2 fields changedInput schema / properties / mediaAdded value: +{
+ "description": "Several images (or images and videos) in one post, in order: an Instagram carousel (up to 10), TikTok photo post (up to 35 JPEG/WebP images), 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? }.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alt": {
+ "description": "Alt text (used by Bluesky, Mastodon and LinkedIn).",
+ "maxLength": 1500,
+ "type": "string"
+ },
+ "title": {
+ "description": "Document title, used by LinkedIn.",
+ "maxLength": 200,
+ "type": "string"
+ },
+ "type": {
+ "description": "Default image.",
+ "enum": [
+ "image",
+ "video",
+ "document"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "description": "Public https URL of the file.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ "maxItems": 35,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / video_url / descriptionPrevious value: -"Public https URL of a video. Required for TikTok and YouTube."New value: +"Public https URL of a video. Required for YouTube; TikTok takes a video or photos."schedule_post2 fields changedInput schema / properties / mediaAdded value: +{
+ "description": "Several images (or images and videos) in one post, in order: an Instagram carousel (up to 10), TikTok photo post (up to 35 JPEG/WebP images), 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? }.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alt": {
+ "description": "Alt text (used by Bluesky, Mastodon and LinkedIn).",
+ "maxLength": 1500,
+ "type": "string"
+ },
+ "title": {
+ "description": "Document title, used by LinkedIn.",
+ "maxLength": 200,
+ "type": "string"
+ },
+ "type": {
+ "description": "Default image.",
+ "enum": [
+ "image",
+ "video",
+ "document"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "description": "Public https URL of the file.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ "maxItems": 35,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / video_url / descriptionPrevious value: -"Public https URL of a video (TikTok and YouTube need one)."New value: +"Public https URL of a video (YouTube needs one; TikTok takes a video or photos)."create_brandcreate_connect_link1 field changedInput schema / properties / brand_idAdded value: +{
+ "description": "Brand to connect it to. Omit for the default brand.",
+ "type": "string"
+}create_upload_linkget_post_status1 field changedInput schema / properties / brand_idAdded value: +{
+ "description": "Brand whose account published it; omit for the default brand.",
+ "type": "string"
+}get_upgrade_linkget_uploaded_filelist_brandsplan_weekget_post_status1 field changedInput schema / properties / id / descriptionPrevious value: -"The id returned by post_to_social for that platform."New value: +"The post id returned when it was published on that platform."post_to_social3 fields changedInput schema / properties / brand_id / descriptionPrevious value: -"Which brand's accounts to use, from my_account.brand_list. Omit to use the default brand."New value: +"Which brand's accounts to use. Omit to use the default brand."Input schema / properties / per_platform / descriptionPrevious value: -"Per-platform drafts, as returned by generate_posts: { \"<platform>\": { \"text\": \"…\", \"title\": \"…\", \"tags\": [\"…\"] } }."New value: +"Per-platform drafts: { \"<platform>\": { \"text\": \"…\", \"title\": \"…\", \"tags\": [\"…\"] } }."Input schema / properties / title / descriptionPrevious value: -"Title, used by YouTube (and Reddit)."New value: +"Title, used by YouTube."schedule_post2 fields changedInput schema / properties / per_platform / descriptionPrevious value: -"Per-platform drafts from generate_posts."New value: +"Per-platform drafts: { \"<platform>\": { \"text\": \"…\" } }."Input schema / properties / title / descriptionPrevious value: -"Title, used by YouTube (and Reddit)."New value: +"Title, used by YouTube."cancel_scheduled_postcreate_connect_linkgenerate_postsget_post_statuslist_platformslist_scheduled_postsmy_accountpost_to_socialschedule_postSchedule, generate and publish social posts to X, LinkedIn, Instagram, Threads and YouTube
Create, schedule and publish social posts to TikTok, Instagram, Facebook and YouTube.
Schedule and publish videos to TikTok, YouTube, Instagram and 5 more networks.
AI-native social media publishing to LinkedIn, Instagram, Threads, TikTok, and X.
Add one secure layer between your agents and this server.
