Antwork

schedule_post

Destructive

Schedule one post, several, or every version of one to publish automatically at scheduled_for.

Every post first passes the same checks as publish_post. Several posts come back per post in posts with scheduledCount; one that cannot be scheduled is reported on its own and the rest still go (at most 10 per call). schedules gives up to 25 posts each its own time in one call; next_slot gives each post its account's next free posting slot in turn. A cadence the user asks for ("3 a day", "an hour apart") is set once with update_workspace(account_posting=...), and every send then holds it.

Args: scheduled_for: ISO 8601 datetime (e.g. "2026-04-01T10:00:00Z"), in the future (Free: up to 30 days ahead; paid plans: any time); or "next_slot": the account's next free posting slot (posting.slots, shown by get_post_context), named in the answer's slot (no slots: the soonest allowed time, slotFallback). post_ids: The posts to schedule. 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: As publish_post's. schedules: Instead of the above: [{post_id, scheduled_for, tiktok_settings?}], each scheduled as a one-post call, in order. 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": "schedule_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.
`schedules`	No
`routine_id`	No
`campaign_id`	No
`workspace_id`	No
`scheduled_for`	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"
+}

Changed5 schema fields changedNov 9, 2026

addedInput schema / properties / scheduled_for / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / scheduled_for / default
```
Added value: +null
```
removedInput schema / properties / scheduled_for / type
```
Removed value: -"string"
```

addedInput schema / properties / schedules

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Schedules"
+}

changedInput schema / required

Previous value: -[
-  "scheduled_for"
-]New value: +[]

Changed1 schema field changedOct 26, 2026

changedInput schema / required

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

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.7/5.0

Behavior5/5

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

Goes well beyond the supplied annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) by disclosing partial-failure semantics (a post that cannot be scheduled is reported on its own and the rest still go), the 10-per-call cap, the 25-post cap for `schedules`, per-post results via `posts`/`scheduledCount`, and the routine_id mode gate.

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

Conciseness4/5

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

The opening paragraph is front-loaded with scope and batching behavior, and the Args block is proportional to an 11-parameter tool. Some clauses are very dense (the scheduled_for entry packs format, horizon, sentinel value, and fallback into one line), which costs readability without adding waste.

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

Completeness5/5

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

For a destructive, open-world mutation tool with 11 optional parameters, the definition covers plan-based limits, per-post error isolation, ordering, and routine-mode gating. Even though an output schema exists, the description still names the key return fields an agent must reason about (`posts`, `scheduledCount`, `slot`, `slotFallback`), leaving nothing blocking a correct call.

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?

With only 27% schema description coverage across 11 parameters, the description compensates heavily: ISO 8601 format and example, future-only constraint, Free-plan 30-day horizon versus unlimited paid plans, the `next_slot` special value with its `slot`/`slotFallback` resolution rules, and the campaign_id-as-versions shortcut. The three undocumented parameters (context, llm_model, conversation_id) are analytics/plumbing fields already self-described in the schema.

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

Purpose5/5

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

Opens with a specific verb and resource plus the full scope of what can be scheduled: "Schedule one post, several, or every version of one to publish automatically at `scheduled_for`." It also distinguishes itself from the nearest sibling by stating that every post passes the same checks as publish_post, so an agent can tell scheduling apart from immediate publishing.

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?

The Args block effectively acts as selection guidance: it tells the agent which of post_id / post_ids / campaign_id / schedules to use in each situation, and warns that each schedule entry is dispatched as a one-post call in order. It lacks an explicit "use publish_post instead when the user wants it live now" exclusion, which is the one remaining routing gap.

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.