Skip to main content
Glama

update_draft

Update a post's content, media, platforms and/or tags. Works on draft, scheduled, and pending-review posts (tags alone can be changed on any post). The existing schedule is preserved. Call schedule_post or queue_post to change when a post fires. Posts that are already publishing or posted cannot be edited. Content is saved verbatim with no AI pass: if you are rewriting the copy yourself, call get_brand_voice first so the edit stays in the user's voice and on-brand. If the post has per-channel copies, changing content changes the shared draft only: every channel that carries its own copy keeps it exactly as it is. To give one channel different text, or change a channel's own copy, pass channel_copies; don't make a second post. Pass first_comment to add, change or remove the comment posted under the post once it is live (LinkedIn, Facebook, Instagram), or first_comments to set several, each from its own profile. Pass stage to move the post to another stage of the editorial workflow (the Content board's columns); it can be set on its own, on any post, and follows the app's rules: only legal moves, one step at a time, and holding a post needs a stage_note. Pass author to give the post to someone else on the workspace, or platform_account_ids to change which connected account a channel publishes from (not once the post is out). Pass penciled_at to pencil a draft in at a date and time, move it, or null to clear it. Drafts never post. A penciled time only holds the slot. The words an edit replaces are kept in the post's version history, where the user can restore them in DemandBird.

Input Schema

NameRequiredDescriptionDefault
idYesPost ID to update
tagsNoReplaces the post's tags; pass [] to remove them all. Omit to leave them as they are. Works on any post, including one already published. For a post imported from the platform, use tag_published_post. Tag names for the post, as they appear on the Content page (e.g. ["Launch", "Case study"]). Matched to the workspace's existing tags ignoring case; a name that doesn't exist yet is created if the user may manage tags, otherwise nothing is saved and the reply lists the tags that exist.
stageNoMove the post to this editorial stage. Legal moves only: needs_writing → drafting; drafting → internal_review or client_review; internal_review → client_review or revision_requested; client_review → revision_requested or ready_to_schedule; ready_to_schedule → done. Any open stage can go to on_hold or rejected, and most can go back to drafting. A refused move says which moves are legal. Moving to client_review invites the post's pending client reviewers; on_hold takes it off the calendar.
authorNoOptional: who the post belongs to. A teammate's name, or 'me'. Omit to leave it as it is. Only people who can see everyone's posts may name someone else, and that person must be able to see this workspace.
imagesNoImages, a video, or one PDF to attach (replaces existing media). For ANY image beyond a thumbnail, call upload_image FIRST to get a presigned S3 URL, upload via the returned curl command, then pass the s3_key here. Inline `data` is only for tiny images (≤50 KB); `file_path` is dev-only. A PDF posts as a LinkedIn document (a swipeable carousel): LinkedIn only, one per post, never alongside images or video.
contentNoNew post content (replaces existing)
youtubeNoYouTube-specific options. Required platform inputs: a video must be attached via `images` (the upload tool accepts video MIME types). If `title` is omitted, it is derived from the first line of content (truncated to 100 chars).
platformsNoUpdated target platforms. Instagram needs an image or video on the post: upload one with `upload_image` (or make one with `generate_image`) and pass its s3_key in `images`.
stage_noteNoWhy the post is moving. Required for on_hold, so the writer knows what to fix.
penciled_atNoOptional: pencil the draft in at a date and time, ISO 8601 (e.g. '2026-10-20T09:00'; no offset means the workspace's posting zone). Drafts never post. A penciled time only holds the slot. It stays a draft: nothing is scheduled or queued, and the queue skips that slot. A date with no time is refused. schedule_post with no `scheduled_at` books it at that time. Pass null to clear it.
first_commentNoOptional: a comment DemandBird posts under the post, from the same profile, once the post is live (often a link or a call to action kept out of the post itself). LinkedIn, Facebook and Instagram only here. Stored verbatim. Pass {"text": ""} to remove it. Omit to leave it as it is.
channel_copiesNoOptional: a channel's own text, keyed by platform, e.g. {"twitter": "..."} for an X version of a LinkedIn post. That text publishes on that channel instead of the shared `content`; every other channel keeps what it had. Stored verbatim. A channel named here is added to the post's platforms. Pass "" for a channel to remove its copy (it then publishes the shared content). Use this, never a second post, to give one channel different text.
first_commentsNoOptional: up to 5 comments DemandBird posts under the post once it is live, in order, each on its own delay and, if `comment_as` is set, from its own profile or page (a teammate adding their thoughts). Replaces every first comment on the platforms it covers; [] removes them all. Stored verbatim. Use this or `first_comment`, not both. Omit to leave the comments as they are.
platform_account_idsNoOptional map of platform => connected_account_id (numeric id from `list_connected_accounts`): which account each platform publishes from. Example: {"linkedin": 42}. Each platform must already be one the post publishes on, and each id a channel of this workspace that matches the platform, or nothing is saved. On a scheduled post the schedule moves to the new account too. Refused once the post is published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare non-read-only, non-destructive, closed-world. The description adds substantive behavior: schedule is preserved, content saved verbatim with no AI pass, edits preserved in version history and restorable, per-channel copies are untouched by a shared-content edit, and a penciled time holds the slot without scheduling. That is exactly the context annotations cannot carry.

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 purpose and editability rules before the parameter-by-parameter guidance. Dense but every clause carries a constraint or an alternative. Slightly overlong as one unbroken block; splitting the per-parameter guidance would improve scanability.

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 14-parameter mutation tool with nested objects and no output schema, the description covers editability limits, side effects, scheduling interactions, workflow-stage rules, and failure modes. Nothing an agent needs to invoke it safely is missing.

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 already 100%, so the baseline is 3; the description earns above that by explaining cross-parameter interactions the schema treats in isolation — content vs channel_copies, first_comment vs first_comments mutual exclusivity, stage_note being required for on_hold, and penciled_at vs schedule_post. Small gap: it says less about platforms/images than the schema does, relying on the schema there.

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 set ("Update a post's content, media, platforms and/or tags") and immediately scopes which post states are editable. It explicitly distinguishes itself from schedule_post, queue_post, and tag_published_post, so an agent can route correctly without opening 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 Guidelines5/5

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

States when-not (already publishing or posted cannot be edited), when-to-use alternatives (schedule_post/queue_post to change timing, get_brand_voice before rewriting copy), and the exact condition for channel_copies vs a second post. Every branch of the decision is spelled out.

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