Antwork

publish_post

Destructive

Publish one post, several, or every version of one now, and wait for the platforms to answer (about half a minute).

A post whose earlier publish failed is retried (requeued about a minute out, retried: true). Every post first passes the same checks: character limit, required media and settings, a connected account. One post answers with its live url; several come back per post in posts with publishedCount, and a post that cannot go is reported on its own while the rest still publish (at most 10 per call). Still processing answers pending with checkAfterSeconds: one get_post after it, no polling. A TikTok post answers tiktok_choices_needed until the user has answered each choice; never answer for them.

Args: post_ids: The posts to publish. campaign_id: Every version of one post (its campaignId from create_post) instead. post_id: One post; the same as post_ids=[post_id]. workspace_id: Workspace ID or name. Optional if user has only one workspace. tiktok_settings: A TikTok post's settings, as the user answered the tiktokChoices a first call returned: {privacyLevel, allowComment, allowDuet, allowStitch, commercialContent: {enabled, yourBrand, brandedContent}, userConsented: true}, or {useLast: true, userConsented: true} once the user said yes to the lastUsed settings offered. Keyed by post id for several posts; a flat useLast applies to every TikTok post in the call. Only the user's own answers for this post. routine_id: The Autopilot routine this run is for: its mode decides whether it may schedule or publish.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "publish_post"
  }
}

Input Schema

Name	Required	Description
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`post_id`	No
`post_ids`	No
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`routine_id`	No
`campaign_id`	No
`workspace_id`	No
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.
`tiktok_settings`	No

Output Schema

Name	Required	Description	Default
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / routine_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Routine Id"
+}

Changed1 schema field changedOct 26, 2026

changedInput schema / required

Previous value: -[
-  "context",
-  "llm_model"
-]New value: +[]

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / tiktok_settings

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Tiktok Settings"
+}

First observedOct 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=true, openWorldHint=true; the description adds substantial context beyond that: ~30s blocking wait, failed publishes requeued about a minute out with retried:true, per-post failure isolation so the rest still publish, a hard cap of 10 per call, and a pending/checkAfterSeconds contract with an explicit no-polling rule. It also forbids answering TikTok choices on the user's behalf, which is important safety behavior not encoded anywhere else.

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 the action and the wait cost, then layered: retry behavior, validation, response shapes, limits, then per-argument notes. The tiktok_settings enumeration is long but each clause carries decision-relevant information; only minor tightening would be possible.

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

Completeness5/5

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

For a 9-parameter, destructive, open-world publishing tool, the description covers timing, limits, retry semantics, partial failure, and the multi-turn TikTok consent flow. An output schema exists, so return values needn't be documented, and the description still gives just enough of the response shape to let the agent plan its next call.

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

Parameters4/5

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

Schema coverage is 33%, so the description must carry the load on tool-specific params, and it does: post_ids vs post_id vs campaign_id mutual exclusivity is spelled out, workspace_id optionality is explained, and tiktok_settings gets detailed shape guidance (privacyLevel/allowDuet/allowStitch, useLast, keyed by post id, userConsented) well beyond the permissive additionalProperties object in the schema. It leaves context, llm_model, and conversation_id unmentioned, though those already have schema descriptions.

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 (publish) and resource (post), plus the exact scope variants: one post, several via post_ids, or every version of one via campaign_id. The agent can distinguish it from create_post/schedule_post by the 'now' framing and the campaign-version semantics without opening the sibling schemas.

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

Usage Guidelines4/5

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

Clearly frames this as the immediate-publish path and warns that routine_id's mode decides whether a run may schedule or publish, which is real routing guidance. It does not explicitly name schedule_post as the alternative when the user wants a future time, so the when-not guidance is implied rather than stated.

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

All Antwork tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.