Antwork

update_post

Destructive

Change a draft or scheduled post; returns it as saved, with its links.

On a published post, text alone changes the live post on LinkedIn, Facebook, Mastodon, Telegram, Discord, Google Business Profile, Pinterest and Slack (needs the publish scope). People already see it: show the user the new text and get their yes first. Other platforms cannot edit a live post.

account_id moves the post to another account (its platform follows). The same idea on another account with its own copy is a new draft. post_ids makes the same change on up to 50 posts in one call (e.g. status: "draft" unschedules them all): only status, hashtags, goal, campaign_id, pinterest_board_id, slack_channel and platform_options; each post answers in posts, and one that fails does not stop the rest. updates changes up to 50 posts each its own way (new text, a new time) in one call; to schedule drafts each at its own time, schedule_post(schedules=...).

Args: post_id: The post ID to update. text: New post text. account_id: A different social account id to publish to. hashtags: Appended to the text as #tags, counted in its limit (YouTube: video tags, unless platform_options.tags). A list, or a string split on commas (on spaces if it has none). goal: Updated goal. status: "draft" or "scheduled". "draft" on a scheduled post unschedules it. "scheduled" sends it as schedule_post does (approval workspaces: pending_approval), so only once the user approved it; to propose a time, send scheduled_for alone. scheduled_for: ISO 8601 datetime. On a draft it only proposes the time (it stays a draft); it moves a scheduled post, or schedules with status "scheduled", which needs the publish scope. campaign_id: Grouping id shared by related drafts. pinterest_board_id: Pinterest only, an id from boards in get_post_context. slack_channel: Slack only, a channel id or #name from slackChannels in get_post_context. platform_options: Settings to change, merged into the post's own (keys as in create_post); null resets one to the platform default. Pinterest also takes newBoardName, which creates that board and sets it. TikTok settings are set by the user at settingsUrl. workspace_id: Workspace ID or name. Optional if user has only one workspace. post_ids: Several posts to change the same way, instead of post_id. repeat: Make a scheduled or published post again on a rhythm: {"every": 2, "unit": "week", "count"?: 5, "until"?: ISO}. "pause", "resume" or "stop" change an existing repeat or evergreen post. Paid plans; not TikTok. Each post made goes through every scheduling check; a refused one is skipped (lastSkip). evergreen: true puts the post in its account's evergreen queue, re-sent into empty posting slots (posting.slots), least recently sent first; false takes it out. evergreen_per_week: Evergreen posts per week on that account (default 3). variants: Alternate texts rotated per repeat, so X and Threads' duplicate rule does not skip them. updates: One entry per post instead of post_id/post_ids: {post_id, text?, scheduled_for?, account_id?, hashtags?, goal?, status?, campaign_id?, pinterest_board_id?, slack_channel?, platform_options?}, each checked as a one-post call; no repeat or evergreen.

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": "update_post"
  }
}

Input Schema

Name	Required	Description
`goal`	No
`text`	No
`repeat`	No
`status`	No
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`post_id`	No
`updates`	No
`hashtags`	No
`post_ids`	No
`variants`	No
`evergreen`	No
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`account_id`	No
`campaign_id`	No
`workspace_id`	No
`scheduled_for`	No
`slack_channel`	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.
`platform_options`	No
`evergreen_per_week`	No
`pinterest_board_id`	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 / updates

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

Changed4 schema fields changedNov 7, 2026

addedInput schema / properties / evergreen

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Evergreen"
+}

addedInput schema / properties / evergreen_per_week

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Evergreen Per Week"
+}

addedInput schema / properties / repeat

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

addedInput schema / properties / variants

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Variants"
+}

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / slack_channel

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

Changed5 schema fields changedNov 2, 2026

addedInput schema / properties / post_id / anyOf

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

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

addedInput schema / properties / post_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Post Ids"
+}

changedInput schema / required

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

Changed1 schema field changedOct 26, 2026

changedInput schema / required

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

First observedOct 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds substantial context the annotations cannot: live edits are publicly visible so the user must confirm first, bulk calls are partially fault-tolerant ('one that fails does not stop the rest'), approval workspaces yield pending_approval, repeat requires a paid plan and skips refused posts via lastSkip, and evergreen behaves as a least-recently-sent queue.

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 highest-risk facts (live-post edit warning, approval requirement) before the long Args block, and almost every sentence carries operational weight. It is nonetheless dense and long, with some clauses (e.g. the YouTube hashtag aside) that could be tightened.

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 21-parameter mutation tool with no required fields, the definition covers platform-specific constraints, scope requirements, bulk semantics, scheduling side effects, and repeat/evergreen behavior. An output schema exists, so omitting return-value detail is appropriate.

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 14% schema description coverage across 21 parameters, the description carries the burden and does: it explains hashtag appending and limit counting, that scheduled_for alone merely proposes a time on drafts, that platform_options merge (null resets to default) and accept newBoardName, that post_ids only honors a whitelisted subset of fields, and the shape of each updates entry. The only undocumented params (context, llm_model, conversation_id) are described in the schema itself.

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 its scope ('Change a draft or scheduled post') and states the return shape ('returns it as saved, with its links'). It also implicitly separates itself from create_post and schedule_post by noting that 'scheduled' behaves 'as schedule_post does'.

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?

Gives explicit when/when-not rules: text alone edits live posts only on the listed platforms and 'other platforms cannot edit a live post'; account_id moves rather than copies; post_ids vs updates select different bulk modes; and it routes elsewhere for the related task ('to schedule drafts each at its own time, schedule_post(schedules=...)'). It also names the prerequisite (publish scope) and the approval requirement.

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.