Skip to main content
Glama
Sign In
posterly-mcp-server

posterly-mcp-server

by awpthorp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_post

DestructiveIdempotent

Edit scheduled or draft social posts to change captions, media, schedules, settings, accounts, or thread replies, and to pause, resume, or manage client approvals.

Instructions

Change a scheduled or draft post. DESTRUCTIVE WRITE. Edit (default): caption, media, schedule, post_type, settings, account_id, or thread_posts; overwrites the existing post; cannot edit published or currently publishing posts. account_id moves the post to another account you can use in the same workspace and on the same brand, and the platform follows that account. thread_posts replaces an X or Threads reply chain with at least two non-empty parts, and the first part becomes the caption. If a client has already approved the post, a caption edit reopens caption approval, a media or thumbnail edit reopens asset approval, and a reschedule, account change, thread edit, or settings change reopens both. status (scheduled, paused, or draft, with scheduled_at when scheduling a draft): pause, resume, or move back to draft; send it on its own. release_id (with optional group_id): set or repair external release/group IDs; send it on its own. approval_action (request, approve, request_changes, or reject): change client approval. Only a workspace owner or admin may do this. The actor is the API key user, never a brand guest. request emails the brand reviewers. approve, request_changes, and reject are team-side decisions. request_changes needs approval_note. Optional approval_axis is asset or caption; omit it for both. Send approval_action on its own.

REQUIRED BEFORE CALLING: Show the user a side-by-side of the CURRENT post (caption, scheduled time, media, status) and the PROPOSED change, and get explicit confirmation ("yes update it", "apply those changes") before calling. Do not auto-edit posts based on a general instruction - each change needs its own confirmation.

Input Schema

NameRequiredDescriptionDefault
statusNoChange the post status instead of editing it. Send with post_id (and scheduled_at when scheduling a draft) only.
captionNoNew caption/text content
confirmYesMust be true after explicit user confirmation of the proposed change.
post_idYesThe post ID to update
group_idNoWith release_id only: an external group/campaign ID.
media_urlNoNew media URL. Posterly storage URLs are used as-is; third-party URLs are copied into posterly storage first. Short-lived signed URLs must still be live when this tool runs.
post_typeNoNew post type: text, image, video, carousel, reel, story, story_series, document, photo, or cover_photo
account_idNoMove this unpublished post to another account you can use in the same workspace. The account must belong to the post brand. The platform follows the new account.
media_urlsNoNew media URLs for carousel, handled like media_url.
release_idNoSet an external release ID instead of editing the post. Send with post_id and optional group_id only.
scheduled_atNoNew scheduled time (ISO 8601, e.g. 2026-03-10T09:00:00Z)
thread_postsNoReplace an X or Threads reply chain. At least 2 non-empty parts. The first part becomes the caption.
approval_axisNoWith approval_action approve, request_changes, or reject: which axis to decide. Omit for both. Not allowed with request.
approval_noteNoNote stored with the approval change. Required for request_changes.
reel_cover_urlNoCover image URL for a reel.
approval_actionNoChange client approval instead of editing the post. Send on its own.
platform_settingsNoPlatform-specific settings to merge into the post. Prefer this over raw metadata.
reel_cover_methodNoHow the reel cover is chosen, e.g. an uploaded image or a frame offset.
reel_thumb_offsetNoFrame offset in milliseconds to use as the reel cover.
instagram_settingsNoInstagram-specific updates. Distinguish caption @mentions, native media user_tags, and collaborators. Native media tags work with eligible direct or Meta-linked accounts; collaborators require an eligible Meta-linked account. Call list_platforms with view=schema and account_id first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.55.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower, yet the description still adds substantial non-obvious behavior: which approval stages get reopened by caption vs media vs schedule/account/thread edits, that account_id must be same workspace and same brand, that the platform follows the new account, and that the actor is the API key user rather than a brand guest. This is context no annotation or schema could convey.

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?

Purpose and destructive warning are front-loaded and every sentence carries operational information, but the middle section is one dense run-on paragraph that restates several per-parameter rules already present in the schema descriptions, making it harder to scan than it needs to be. Mode grouping (edit / status / release_id / approval_action) is present but buried in prose rather than segmented.

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 20-parameter, nested, multi-mode destructive mutation this description covers permissions, preconditions, mode exclusivity, side effects on approval state, and the mandatory confirmation workflow. It has no output schema and does not state the return shape, but the only thing an agent must know before invoking is covered.

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 description coverage is 100%, so the baseline is 3, but the description goes further by explaining cross-parameter invariants: account_id relocates the post and changes the platform, thread_posts replaces a reply chain and its first element becomes the caption, approval_axis omitted means both axes, and approval_note is required only for request_changes. What it does not add is any detail on the large nested platform_settings/instagram_settings objects, which are left to the schema.

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 first sentence names a specific verb and resource ("Change a scheduled or draft post") and immediately labels it a destructive write, and the following sentences enumerate the four distinct operating modes (edit, status, release_id, approval_action). An agent can distinguish update_post from create_post, delete_post, and validate_post without opening any schema.

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?

Explicit boundaries are given: cannot edit published or currently publishing posts, each of the four modes must be sent on its own, and only a workspace owner or admin may change approval. The "REQUIRED BEFORE CALLING" block spells out the confirmation protocol (side-by-side diff plus explicit user 'yes') and forbids auto-editing from a general instruction, which is exactly the when/when-not guidance an agent needs.

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

Deploy Server

Other Tools