Skip to main content
Glama

Edit an unpublished post

update_post
DestructiveIdempotent

Update a post's content, platforms, scheduled time, attached media, or thread reply segments. Only works on unpublished posts (drafts, scheduled, queued, and pending).

Any field you omit is preserved as-is. Pass media_urls: [] to clear all attached media; pass new media_urls or video_url to replace it. For already-published posts, you'll need to delete and re-create.

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": {
      "post_id": "<post_id>"
    },
    "name": "update_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
tiktokNoFor TikTok. See create_post.
contentNoNew post text. Omit to keep existing content.
post_idYesThe post ID (UUID) to update.
segmentsNoNew thread reply segments (up to 24; see create_post). Pass an empty array to remove existing thread replies and revert to a single post. Omit to keep existing segments.
variantsNoA different version per network; format on create_post. Here an object replaces every variant; pass null or {} to remove them. Omit to keep them (a network you drop from platforms loses its variant).
platformsNoNew platform list. Omit to keep existing platforms.
video_urlNoNew video URL to attach to the main post. Replaces existing media. Omit to keep existing media unchanged.
media_urlsNoNew media for the main post (URL strings or {url, alt}; see create_post). Replaces existing media. Pass an empty array [] to remove all media. Omit to keep existing media unchanged.
first_commentNoNew first comment (posted as a reply right after the post; see create_post). Pass an empty string to remove it. Omit to keep the existing one.
scheduled_forNoNew scheduled time, ISO 8601. With a timezone offset or Z, e.g. 2026-11-04T09:00:00-05:00 or 2026-11-04T14:00:00Z (a time without one is rejected). Must be in the future. Omit to keep the existing schedule.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes further and states precisely what gets destroyed and how: omitted fields are preserved, `media_urls: []` clears media, an empty segments array reverts a thread to a single post, and new media/video_url replaces existing. It also discloses the scheduling constraint (must be future-dated and timezone-qualified) and the irreversible nature of editing published posts.

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 purpose and scope, then edit semantics, then the escape hatch for published posts — a sensible order with no filler sentences. Some of the media/clear guidance duplicates the schema's per-parameter descriptions, which is the only redundancy.

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

Completeness4/5

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

For a 10-parameter, nested, destructive mutation with no output schema, the description covers the critical unknowns: state gating, partial-update semantics, and explicit clearing behavior. It is slightly short on what happens when platforms is changed without variants (the schema notes a dropped network loses its variant, but the description does not reinforce it) and does not mention sibling alternatives.

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 coverage is 100% and each parameter's own description already states the omit-to-keep and empty-to-clear rules, so most of the description's parameter prose restates structured data. It adds one small generalization ("Any field you omit is preserved as-is") that ties the per-field rules together, but no new syntax, format, or precedence guidance beyond the schema.

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

Purpose4/5

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

The description opens with a specific verb and resource plus the exact editable facets: "Update a post's content, platforms, scheduled time, attached media, or thread reply segments." It also carves out scope by post state (unpublished only), which separates it from publish_draft/approve_queued_post. It never names the closest sibling, reschedule_post, so an agent must infer which tool to use for a time-only change.

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?

Clear when-to-use and when-not-to-use: works on drafts, scheduled, queued, and pending posts, and for published posts "you'll need to delete and re-create," which routes the agent to delete_post/create_post. The gap is the overlap with reschedule_post and split_thread, which are plausible alternatives for a subset of these fields and are not mentioned.

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