Skip to main content
Glama

Edit a scheduled, draft or live post

update_post
Destructive

Change a scheduled or draft post before it goes out, or edit a post that is already live on a channel that supports editing (list_platforms features: today Naver Blog, YouTube and some Facebook posts). Fields: content, mediaIds, accountIds, options, scheduledAt or draft. Fields you leave out keep their current value (on a Naver Blog post, see media below); options you pass replace the whole options object (on a post written directly on the channel they are merged per channel key instead). scheduledAt moves the send time (same rules as publish), null turns it into a draft, and draft: true does the same. A thread (chain) can be changed too while it is scheduled or a draft: content replaces the first item and keeps the later items; threadItems replaces the whole chain (one item collapses it to a single post); passing threadItems to a single post turns it into a chain. Pass id of the first item — later items return 409 thread_piece with rootId. Posts that already went out return post_not_editable on channels that cannot edit a live post. A post written directly on the channel (one a link or id resolved to, origin imported) can be edited on YouTube, on the text of Facebook text, link and photo posts, and on Naver Blog: uplika reads the post from the channel first, so fields you leave out keep the channel's current values. Elsewhere it returns post_not_editable with the reason (list_platforms feature update_imported). A Naver post written in Naver's editor is rewritten from its current source, which uplika reads from Naver's edit screen: text, bold, italic, underline, strikethrough and links are markdown; headings and quotes are markdown only when their text has no style at all; every other block (photos, videos, cards, tables, headings or quotes with a font, and whole text blocks that have colors, sizes or alignment anywhere, several paragraphs each) is one @keep(...) line. A line holding only an invisible U+200B character is blank space at the edge of a text block; leave it to keep the spacing. Send the edited source as content together with sourceVersion. Without it, or when the post changed on Naver since, this returns 409 naver_source_required with the current source and its sourceVersion (get_post also shows sourceVersion, but its content is only the source after uplika has read it once). Keep a @keep line to keep that block where it is, delete it to remove the block; text you write directly next to a @keep text block joins that block, and comes back inside its @keep line on the next read. An unknown id returns 422 naver_keep_unknown. This needs extension 0.7.8 or later (422 extension_outdated otherwise). A published Naver post is rewritten in place (same URL, same logNo) when you pass content, mediaIds or options. On a post that goes only to Naver Blog, the media: references in the new body are the post's media list: when you leave mediaIds out, media the new body does not place is removed from the post and the response note says how many. Pass mediaIds only for media to add at the end of the post without placing it in the body. If the body places more photos or videos than Naver takes (list_platforms), this returns 422 naver_media_over_limit with droppedIds and nothing changes. Naver Blog caps how many posts one ID publishes; when it does, this returns 429 naver_rate_limited with retryAfterSeconds. Do not call again before that, the draft is already in Naver. Naver Blog asks which form to publish with, every post: if options.naver_blog.form is missing this returns 400 naver_form_required with forms (id, name, when). The form is the house style to use when the person has no style of their own, so read the conversation first. If they dictated the structure or you laid it out yourself, pass options.naver_blog.layout: "as-is" and the markdown goes out unchanged. Otherwise show them the forms (naver_layout with forms: "all" lays every one out side by side) and call again with the one they pick. Do not pick for them. If the Naver editor shows a "missing image" error when you open an already-published post for editing, calling update_post on that post rewrites it in place and fixes it; the URL stays the same. A Naver draft (a target whose externalId starts with draft:, from options.naver_blog.draftOnly) is not on the blog: update_post publishes uplika's copy as a new post and, with extension 0.7.2 or later, removes the old draft from Naver's draft box. To publish the draft exactly as it is in Naver, call publish_naver_draft. Editing a post that is already live is asynchronous: pass wait: true to hold the response for the result (up to 75 seconds), or read it with get_post. If the account that published the post was disconnected, this returns 409 account_disconnected; reconnect the same account and the post id comes back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesA publish id (post_…), the post's own id on the channel, or a post link (the URL you would open in a browser to see it). Links work for posts written in the channel's own app too, as long as the account is connected here.
waitNoOnly when editing a post that is already live: hold the response until the edit has gone through or not, up to 75 seconds. Past that it returns while still working, with next telling you to read get_post.
draftNotrue turns a scheduled post back into a draft.
contentNoNew post text.
optionsNoPer-channel settings, same shape as on publish. Replaces the whole object.
mediaIdsNoNew media, in order. Replaces the current set. On a Naver Blog post the body's media: references already are the list, so leave this out unless you add media to the end of the post without placing it.
accountIdsNoNew target accounts, from select_channels. Replaces the current set.
scheduledAtNoNew send time (ISO 8601 with offset, 10 minutes to 365 days out), or null to keep the post as a draft instead.
threadItemsNoReplace the whole chain: [{ content, mediaIds? }], first item is the root. Only while the post is scheduled or a draft, and only for Threads and Bluesky. Leave it out to keep the current items (content then edits just the first one). Exclusive with content.
workspaceIdNoWhich workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again.
sourceVersionNoOnly for a Naver post written in Naver's editor: the sourceVersion that came with the source you edited (from naver_source_required or get_post). It tells uplika the content was made from the post's current source.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / mediaIds / description
      Previous value: -"New media, in order. Replaces the current set."New value: +"New media, in order. Replaces the current set. On a Naver Blog post the body's media: references already are the list, so leave this out unless you add media to the end of the post without placing it."
  2. Changed1 schema field changed
    • addedInput schema / properties / wait
      Added value: +{
      +  "description": "Only when editing a post that is already live: hold the response until the edit has gone through or not, up to 75 seconds. Past that it returns while still working, with next telling you to read get_post.",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / sourceVersion
      Added value: +{
      +  "description": "Only for a Naver post written in Naver's editor: the sourceVersion that came with the source you edited (from naver_source_required or get_post). It tells uplika the content was made from the post's current source.",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / threadItems
      Added value: +{
      +  "description": "Replace the whole chain: [{ content, mediaIds? }], first item is the root. Only while the post is scheduled or a draft, and only for Threads and Bluesky. Leave it out to keep the current items (content then edits just the first one). Exclusive with content.",
      +  "items": {
      +    "properties": {
      +      "content": {
      +        "type": "string"
      +      },
      +      "mediaIds": {
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      }
      +    },
      +    "required": [
      +      "content"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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

Far beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), it discloses that editing live posts is asynchronous (wait up to 75s), that omitted Naver media is removed from the post, that rate limits surface as 429 naver_rate_limited with retryAfterSeconds, and numerous platform-specific error codes. The destructiveHint annotation is consistent with the disclosed media-removal behavior.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is a single monolithic paragraph of extreme length with no headers or breaks, making crucial operational rules (async wait, form requirement, @keep rules) hard to scan. Individually much of the content is useful, but the size and lack of structure are a clear defect.

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?

With 11 parameters, nested objects, no output schema and multiple platform-specific branches, the description covers error codes, prerequisites (extension version), async behavior and edge cases comprehensively. Nothing an agent needs in order to call this correctly 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%, and much of the description reinforces it (options replaces the whole object, threadItems replaces the whole chain, scheduledAt null makes a draft). It goes further with semantics not in the schema, e.g. options.naver_blog.form/layout, sourceVersion and @keep line handling, which meaningfully aid correct invocation.

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 opening sentence gives a specific verb (Change/Edit) on a specific resource (scheduled/draft/live post) and immediately bounds scope by channel capability ('on a channel that supports editing'). It is readily distinguishable from siblings like publish, publish_naver_draft and get_post, which are named within the text.

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?

Alternatives are named with the conditions that select them: use publish_naver_draft 'to publish the draft exactly as it is in Naver', check list_platforms features, and read get_post to poll async results. It also gives explicit exclusions ('posts that already went out return post_not_editable') and process guidance ('Do not pick for them').

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