AutoPoster AI

Update Post

autoposter_update_post

Edits an existing draft, scheduled, pending_approval or declined post in place: text, title, visibility, media, first comment / thread, or schedule time. Only the fields you pass change. Posts already published or being processed cannot be edited. If the API key cannot publish directly, an edited scheduled post goes back to pending_approval.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "postId": "<postId>"
    },
    "name": "autoposter_update_post"
  }
}

Input Schema

Name	Required	Description
`title`	No	Optional title. Used by YouTube, Pinterest and WordPress; ignored elsewhere.
`postId`	Yes	The post ID from autoposter_list_posts.
`content`	No	New post text.
`mediaIds`	No	New ordered list of media IDs from autoposter_list_media. Replaces the current media; [] removes all.
`timezone`	No	Optional IANA timezone for scheduledAt. Defaults to the post's timezone, then UTC.
`visibility`	No	Optional audience for TikTok posts (default PUBLIC_TO_EVERYONE). Ignored on other platforms.
`scheduledAt`	No	New ISO timestamp or local datetime, e.g. '2026-10-05T14:00:00'. Must be in the future.
`firstComment`	No	Optional first comment posted on the post right after it publishes (e.g. links or hashtags). Supported on platforms with comment support such as X, Facebook, Instagram, LinkedIn, Threads, Bluesky, Mastodon, Telegram, Discord.
`threadComments`	No	Optional thread: follow-up texts posted in order after publishing, each replying to the previous one. If firstComment is also set, these come after it. On X this makes a tweet thread.

Output Schema

Name	Required	Description
`postId`	Yes	Post ID.
`status`	Yes	Post state after the update.
`message`	No	Status message.
`success`	Yes	Whether the post was updated.
`scheduledAt`	No	Scheduled time in UTC.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses three non-obvious behaviors: the update is partial ("Only the fields you pass change"), so omitted fields are preserved rather than cleared, and the editability state machine. Most valuable is the workflow quirk that an edited scheduled post falls back to pending_approval when the API key lacks direct publish rights — an outcome an agent could not predict from structured fields.

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

Conciseness5/5

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

Three tight sentences: capability first, partial-update semantics second, state restriction and status side effect last. Every clause carries decision-relevant information and nothing is repeated from the schema.

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 mutation with only one required field, an output schema, and full annotation coverage, the description supplies what structure cannot: which post states are mutable, that updates are partial, and the pending_approval fallback. Nothing essential to calling it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so parameter meaning is already fully carried by the schema (including the [] clears media rule and the timezone fallback chain). The description's field list only restates the schema's own coverage; it adds no syntax, format or interaction detail beyond it, so the baseline 3 applies.

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?

The description names a specific verb (edits), the resource (an existing post), the exact set of editable states (draft, scheduled, pending_approval, declined) and the mutable fields (text, title, visibility, media, first comment/thread, schedule time). That state enumeration alone distinguishes it from autoposter_publish_draft, autoposter_schedule_post and autoposter_delete_post without opening any schema.

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?

It gives a clear negative rule — posts already published or being processed cannot be edited — which is exactly the boundary an agent needs before calling. It stops short of explicitly routing to siblings (e.g. use autoposter_publish_draft to publish, autoposter_create_upload_link for new media), so an agent must infer the alternative path.

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

All AutoPoster AI 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.

Resources

Need Help?