Skip to main content
Glama

Change a draft. Changing what would be posted voids its approval

updateDraft
Destructive

Change a draft. Changing what would be posted voids its 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": {
      "id": "<id>",
      "rev": "<rev>"
    },
    "name": "updateDraft"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDraft ID or stable workspace post number, such as "#38" or "38".
revYesThe rev you read. A stale rev is refused (rev_conflict).
bodyNoThe exact platform body: x_post or linkedin_post {text, media?: [{media_id, alt}]}; x_thread {posts: [{text, media?}, …]}. The full schema also includes LinkedIn documents, cards, TikTok and slideshows. The API validates the complete body.
kindNoChange between compatible post kinds; send the complete body in the new kind's shape.
metaNoDesk notes, never posted or approved: notes and warnings (string arrays) for the reviewer, when (a timing note).
titleNoA title for the desk. Never posted.
optionsNoTwo or three text and media versions for the owner to pick when approving; null removes them. Shared fields stay in body.
post_atNoWhen to post it, once approved for scheduling. RFC 3339 with a UTC offset (Z or ±HH:MM), like 2026-10-26T09:00:00-07:00.
archivedNo
workspaceNoLeave out for the token's workspace (ws_…).
agent_noteNoA short plain-text note from the agent to the owner: why this post, its sources, what you're unsure of. Shown as one paragraph (line breaks fold into spaces) above the preview in the approval sheet, the desk and the in-chat preview, and frozen into the approval snapshot with the draft, so the approval records the note the owner saw. Never posted or sent to any platform. Changing it doesn't void an approval. Blank or null removes it.
body_patchNoPartial edit: omitted fields stay, null removes optional fields. media_add appends uploaded {media_id, alt}; media_from imports and appends. Thread posts is one patch per current part. Not with body/options/kind changes. Media edits invalidate prior approval; updateDraft returns approval_effect and the re-request call.
connection_idNoThe selected account: an active connection's id from GET …/connections for the kind's platform. Video-platform drafts never infer it, even with one account. Draft-only saves may omit it; checks and posting approval require it. TikTok mode:approve review alone may keep null and creates no upload job.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / id / description
      Added value: +"Draft ID or stable workspace post number, such as \"#38\" or \"38\"."
    • changedInput schema / properties / id / pattern
      Previous value: -"^drf_[a-z0-9]{16}$"New value: +"^(?:drf_[a-z0-9]{16}|#?[1-9]\\d*)$"
  2. Changed1 schema field changed
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "x_post",
      -  "x_thread"
      -]New value: +[
      +  "x_post",
      +  "x_thread",
      +  "pinterest_image",
      +  "pinterest_carousel"
      +]
  3. Changed2 schema fields changed
    • changedInput schema / properties / connection_id / description
      Previous value: -"The account it posts as: an active connection's id from GET …/connections, for the kind's platform."New value: +"The selected account: an active connection's id from GET …/connections for the kind's platform. Video-platform drafts never infer it, even with one account. Draft-only saves may omit it; checks and posting approval require it. TikTok mode:approve review alone may keep null and creates no upload job."
    • changedInput schema / properties / kind / description
      Previous value: -"Turn an X post into a thread or back; send the body in the new shape with it."New value: +"Change between compatible post kinds; send the complete body in the new kind's shape."
  4. Changed1 schema field changed
    • addedInput schema / properties / body_patch
      Added value: +{
      +  "description": "Partial edit: omitted fields stay, null removes optional fields. media_add appends uploaded {media_id, alt}; media_from imports and appends. Thread posts is one patch per current part. Not with body/options/kind changes. Media edits invalidate prior approval; updateDraft returns approval_effect and the re-request call.",
      +  "type": "object"
      +}
  5. First observed

TDQS

C2.9/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral information beyond that: edits that change the posted content silently void an existing approval, which is exactly the kind of side effect an agent must know before mutating. It stops short of covering rev-conflict refusal or what the call returns, but those live in the schema.

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?

Two short sentences with the consequence front-loaded right after the action, and no filler. The second sentence is identical to the tool title, so it is near-duplicated metadata rather than new content, which keeps this just under top marks.

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

Completeness3/5

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

For a destructive 13-parameter mutation with nested bodies, no output schema, and approval lifecycle consequences, the description covers purpose and the single most important side effect but omits return behavior, permission or connection requirements, and the partial-edit path. The unusually rich schema closes most of those gaps, leaving the description minimally adequate.

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 92%, so the parameter documentation already carries the load — rev staleness, body_patch scope, options cardinality, and the approval_effect return are all spelled out per-property. The description adds no parameter meaning of its own, so the baseline of 3 applies.

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

Purpose2/5

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

Tautological: description restates name/title.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no named alternatives (checkDraft, requestApproval, createDraft), and no statement of when not to call it. The only conditional content is the approval-voiding caveat, which is a side effect rather than routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources