Skip to main content
Glama

Update post

update_post
Destructive

Edit an existing draft/scheduled post without deleting it. You may change its base content, target platforms, status, scheduled time, per-platform settings, and/or APPEND media from public https URLs via mediaUrls. Set publishNow=true to publish using server time; it consumes monthly quota but no deferred queue slot, even when that queue is full. It re-validates the complete final content/media/platform state. Appending does not replace unfinished upload slots: inspect get_post and use delete_media for that specific reservation first only when the user's task authorizes abandoning it. Before changing platforms, call list_connections and copy each target's platformId verbatim. Published/failed posts and posts already being published are not editable. Scheduling re-validates the complete final content/media/platform state; omitting a field keeps its current value.

Input Schema

NameRequiredDescriptionDefault
statusNoNew status: 'draft' or 'scheduled'. publishNow=true schedules immediate publication; omit status or use 'scheduled'. Combining it with 'draft' is rejected.
contentNoOptional replacement base post text. On X and Threads, long content auto-splits into a chain; a standalone --- line between paragraphs sets a break, and media attach only to the first part. Threads parts are limited to 500 characters; the connection needs threads_manage_replies, and THREADS_PERMISSION_REQUIRED means reconnect in Publora Channels. Thread part and numbering settings are not API/MCP inputs. After partial publication, inspect get_post and never recreate or resubmit the whole chain. For an unknown outcome, check the live account before further action. Updates every target without an explicit platform-specific override. An empty string is allowed for a draft; scheduling still enforces each platform's content/media rules.
mediaUrlsNoOptional array (max 10) of public https URLs of images/videos to APPEND to this post. Same rules as create_post: direct file URLs only; jpeg, png, gif, webp, tiff, avif, mp4, mov, webm; images ≤25MB, videos ≤150MB.
platformsNoOptional replacement target platform array. Call list_connections first and copy its platformId values verbatim. This replaces the whole set; [] is allowed only while the post remains a draft.
publishNowNoSet true to publish this draft or scheduled post immediately using server time and trigger publication processing. Reserves monthly publication quota but no deferred queue slot. Omit scheduledTime and status; a future time or status 'draft' is rejected. False or omitted retains existing editing/scheduling behavior. Inspect get_post for asynchronous publication progress.
postGroupIdYesPost group ID
firstCommentNoReplace the first comment (object) or clear it (null). Legacy single first comment under your own post. Supported: linkedin (profiles and Pages), twitter, threads, bluesky, mastodon; other targets are skipped. Best effort: read firstCommentResult via get_post. Cannot be combined with firstComments or added after publishing.
firstCommentsNoReplace all first comments (array of up to 3), or clear with null or []. Up to 3 ordered first comments under your own post, each { text, platforms?, delaySeconds? }. delaySeconds is an integer 0–86400; omitted means 0. The next comment runs only after the previous one posts, on a scheduler tick; a failed comment stops later ones. Platform types (not connection keys) and text limits follow firstComment. Best effort, no blind retries. Read per-target firstCommentResults via get_post. Cannot be combined with firstComment or added after publishing.
scheduledTimeNoNew ISO 8601 date-time with UTC Z or offset. Choose a future time within the schedule horizon returned by account_context. With publishNow=true, omit this field; a future scheduledTime is rejected. Inspect returned warnings and effective scheduledTime; a quota error requires changing the request or queue state before retrying.
idempotencyKeyNoOptional retry key. Reusing it with the identical request prevents repeated media appends and replays the original response.
platformSettingsNoMerge per-platform options (same shape as create_post). Per-platform options keyed by platform. Example: { instagram: { coverUrl: 'https://.../cover.jpg' }, youtube: { title: 'My video', tags: ['topic'] }, tiktok: { viewerSetting: 'SELF_ONLY' }, twitter: { replyTo: 'https://x.com/user/status/123' } }. Also supports telegram.disableNotification/disableWebPagePreview/protectContent, threads.replyControl, linkedin.repostParentUrn/repostVisibility. For TikTok photos, tiktok.autoAddMusic lets TikTok choose music; no track selection or preview. Unknown platforms or fields are rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / platformSettings / description
      Previous value: -"Merge per-platform options (same shape as create_post). Per-platform options keyed by platform. Example: { instagram: { coverUrl: 'https://.../cover.jpg' }, youtube: { title: 'My video', tags: ['topic'] }, tiktok: { viewerSetting: 'SELF_ONLY' }, twitter: { replyTo: 'https://x.com/user/status/123' } }. Also supports telegram.disableNotification/disableWebPagePreview/protectContent, threads.replyControl, linkedin.repostParentUrn/repostVisibility. Unknown platforms or fields are rejected."New value: +"Merge per-platform options (same shape as create_post). Per-platform options keyed by platform. Example: { instagram: { coverUrl: 'https://.../cover.jpg' }, youtube: { title: 'My video', tags: ['topic'] }, tiktok: { viewerSetting: 'SELF_ONLY' }, twitter: { replyTo: 'https://x.com/user/status/123' } }. Also supports telegram.disableNotification/disableWebPagePreview/protectContent, threads.replyControl, linkedin.repostParentUrn/repostVisibility. For TikTok photos, tiktok.autoAddMusic lets TikTok choose music; no track selection or preview. Unknown platforms or fields are rejected."
    • addedInput schema / properties / platformSettings / properties / tiktok / properties / autoAddMusic
      Added value: +{
      +  "description": "Photo Direct Post only. Opt in with true to let TikTok automatically choose music; Publora cannot select or preview a specific track. False disables music and is allowed when switching to video. Omission preserves existing behavior. Videos never send this parameter.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations supply the safety profile (destructiveHint=true, readOnlyHint=false, idempotentHint=false), and the description adds real behavior beyond them: quota consumption with publishNow, that it consumes no deferred queue slot, full re-validation of final content/media/platform state, append-vs-replace semantics for media, and that idempotencyKey prevents duplicate appends. No contradiction with the annotations.

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 the routing rules, and most sentences carry genuine constraints. However it is dense and repeats itself — 'It re-validates the complete final content/media/platform state' appears twice almost verbatim, and the platform/status cross-rules duplicate 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 an 11-parameter, nested-object mutation tool with no output schema, the description covers non-editable states, quota effects, async publication progress via get_post, media reservation handling, and platform-ID sourcing. An agent has everything needed to call it correctly or abort.

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% and the schema already documents append-vs-replace for mediaUrls/platforms, publishNow cross-field rules, and status constraints, so most of the description's parameter talk is repetition. It adds a little global PATCH semantics ('omitting a field keeps its current value') and the unfinished-upload-slot caveat, but not enough to exceed the baseline.

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+resource+scope: 'Edit an existing draft/scheduled post without deleting it', which instantly separates it from delete_post and create_post. It further names the exact field surface it can change, so an agent knows precisely what the tool owns.

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 routing: call get_post to inspect, delete_media to clear a specific reservation, list_connections before changing platforms, and states when NOT to use it (published/failed/in-flight posts are not editable). This is a complete when/when-not/alternatives map.

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