aicut

Publish a prepared post

publish_post

Destructive

Sends a post staged by prepare_post, or schedules it. Irreversible: the post goes out under the user's own name and cannot be taken down from aicut. It is for a post the user has confirmed: either in chat, after a question that named the account, the text, the visibility and any scheduled time (a bare 'yes' confirms only when that question about this post was the message immediately before it), or in the publish card opened by review_post. A card confirmation arrives as a chat message that includes the id of the post the card staged from the user's choices; that is the post_id to send. The caption, visibility and disclosure are fixed when the post is prepared and cannot be changed here. schedule_at is the one field that can differ from what the user approved: it changes the publish time, so set it only when the user asked for a different time after confirming. WHEN: after prepare_post, once the user has chosen and confirmed. IT NEVER ANSWERS posted, and that is the truth, not a delay: TikTok answers publishing (the platform downloads the video itself, which can still fail); YouTube and Instagram answer submitted (aicut's poster has it, nothing is confirmed); a scheduled post answers scheduled. Poll get_post_status until posted or failed; never tell the user their video is live on the strength of this call. SCHEDULING: schedule_at sets or moves the time, null sends a post prepared for later now. A scheduled TikTok or Instagram post waits in aicut (the scheduler fires every due post at once, so a schedule can be REFUSED with retry_after_seconds meaning 'move it at least this many seconds later'); a scheduled YouTube post is uploaded at once as private and published by YouTube, so it stays scheduled with a post_id you can hand the user. THE POSTING LIMITS, so you can pace a batch instead of discovering them: per CONNECTED ACCOUNT, tiktok 5/min and 13/24h, youtube 2/min and 10/24h, instagram 4/min and 45/24h. Both windows are ROLLING (the 24h one does not reset at midnight). Over the limit you get a 429 (post_rate_limited or daily_post_limit) with retry_after_seconds: respect it, and do not prepare a second post or use a second account to get around it. A slot is taken only by a call that reaches the platform, so every refusal raised before that point is FREE (a 400, 404, 409 already_published / post_expired / consent_required / video_not_ready, a 403 insufficient_scope, a TikTok preflight failure): fix it and retry at once. prepare_post is a separate meter (5/min, 100/24h per connected account). Scheduling spends the same allowance, counted around the scheduled time. 403 insufficient_scope = the user's connection lacks the social:publish permission: not a bad video_id or account_id, and a retry cannot fix it. Tell them to disconnect and reconnect aicut at https://www.aicut.pro/account/settings#connections (the full steps are in prepare_post's REFUSALS), then STOP. A 403 here posted NOTHING: the request never reached the platform, so say plainly that the video did not go out.

Input Schema

Name	Required	Description	Default
`post_id`	Yes	The `id` returned by `prepare_post`.
`schedule_at`	No	ISO-8601 time to publish at, at least 10 minutes ahead; overrides what `prepare_post` recorded. Null sends the post now. Omit to keep the prepared time.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say destructive/not-idempotent/open-world; the description adds what is actually destroyed (post goes out under the user's name, cannot be removed from aicut), that the caption/visibility/disclosure are frozen, the exact per-platform call outcomes (`publishing`, `submitted`, `scheduled`, never `posted`), rolling per-account rate limits with counts, which refusals are free vs. slot-consuming, and that a 403 published nothing. This is far beyond the annotation payload and consistent with it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the irreversibility warning, and every block is labelled (WHEN, SCHEDULING, THE POSTING LIMITS) so it scans well. It runs long and repeats the 403 story twice (once in the scope paragraph, once in the closing sentence), which is more redundancy than the complexity strictly requires.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating every status the call can return and what each means, plus the error codes and their remediation. Nothing an agent needs in order to call this correctly and report honestly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds meaning: `post_id` is the id from `prepare_post` or from the card confirmation message, and `schedule_at` should only be set when the user asked for a different time after confirming, with null meaning send now. It explains the intent behind the parameter, not just its type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Sends a post staged by `prepare_post`, or schedules it") and immediately distinguishes itself from the two siblings that could be confused with it, `prepare_post` and `review_post`. An agent knows exactly which step in the publish pipeline this is.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit WHEN section: after `prepare_post`, once the user has chosen and confirmed, with a precise definition of what counts as confirmation (named account/text/visibility/time, bare 'yes' only when immediately preceded, or a card message carrying the post id). It also names the required follow-up (`get_post_status`) and forbids workarounds on rate limits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All aicut tools Inspect

Try in Browser