Skip to main content
Glama

Reschedule or edit a post

sprkly_update_scheduled_post
Idempotent

Change the caption, publish time, target accounts or attached media on a post that has not published yet. Posts with status "scheduled", "pending_approval" or "draft" can be edited, and the status never changes here: editing a post that waits for approval does not approve it, and a rejected post stays a draft until you request approval again. A post waiting for approval can only target one account. Refusals carry a code: approval_pending (the caption, media and accounts are locked while it waits for approval; the time can still change), publishing_now (it is going out right now), post_changed (it changed since you read it: read it again), stuck_publishing (it got stuck while going out: send the user to support@sprkly.app), caption_too_long (too long for one of its targets).

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": "sprkly_update_scheduled_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
captionNoReplacement caption. Each platform's own limit applies: X 280, Bluesky 300, Threads 500, Instagram and TikTok video 2,200, LinkedIn 3,000, TikTok photos 4,000, YouTube 5,000 bytes, Facebook 63,206, Telegram 4,096 as text alone and 1,024 with a photo or video. No < or > on YouTube.
post_idYesThe scheduled post id.
alt_textNoReplacement alt text, one entry per media item, in the post's media order after this edit. Use "" for an item with no alt text. Replaces all alt text on the post. Used on platforms that support it.
media_idNoReplacement sprkly media file id. Shorthand for a one-item media_ids.
media_idsNoReplacement media, in slide order. Replaces the whole set, it does not append — pass every slide you want the post to keep. Clears the post's alt text unless alt_text is sent too.
post_typeNoOptional. What the post is for: awareness (show new people who you are and what you sell), educational (teach something useful), proof (show that other people trust you), conversation (get people to reply), conversion (ask people to buy, book or order now), loyalty (for people who already bought). Any other value is refused. Separate from category, which is the topic. Send "" to clear it.
profile_idsNoReplacement target accounts. Platforms are re-derived from them.
scheduled_timeNoNew ISO 8601 publish time. Must be in the future.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / post_type
      Added value: +{
      +  "description": "Optional. What the post is for: awareness (show new people who you are and what you sell), educational (teach something useful), proof (show that other people trust you), conversation (get people to reply), conversion (ask people to buy, book or order now), loyalty (for people who already bought). Any other value is refused. Separate from category, which is the topic. Send \"\" to clear it.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / caption / description
      Previous value: -"Replacement caption. Each platform's own limit applies: Instagram and TikTok video 2,200, TikTok photos 4,000, YouTube 5,000 bytes, Threads 500. No < or > on YouTube."New value: +"Replacement caption. Each platform's own limit applies: X 280, Bluesky 300, Threads 500, Instagram and TikTok video 2,200, LinkedIn 3,000, TikTok photos 4,000, YouTube 5,000 bytes, Facebook 63,206, Telegram 4,096 as text alone and 1,024 with a photo or video. No < or > on YouTube."
  3. Changed1 schema field changed
    • changedInput schema / properties / caption / description
      Previous value: -"Replacement caption, max 2200 characters."New value: +"Replacement caption. Each platform's own limit applies: Instagram and TikTok video 2,200, TikTok photos 4,000, YouTube 5,000 bytes, Threads 500. No < or > on YouTube."
  4. Changed2 schema fields changed
    • addedInput schema / properties / alt_text
      Added value: +{
      +  "description": "Replacement alt text, one entry per media item, in the post's media order after this edit. Use \"\" for an item with no alt text. Replaces all alt text on the post. Used on platforms that support it.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / media_ids / description
      Previous value: -"Replacement media, in slide order. Replaces the whole set, it does not append — pass every slide you want the post to keep."New value: +"Replacement media, in slide order. Replaces the whole set, it does not append — pass every slide you want the post to keep. Clears the post's alt text unless alt_text is sent too."
  5. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses conditional field locking under approval — caption, media and accounts locked while only the time may change — plus a full enumerated refusal-code table with per-code remedies. It also warns that a pending-approval post can only target one account, which is exactly the kind of behavioral constraint annotations cannot express.

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 mutation and the eligibility rule, then the refusal codes in a compact parenthetical glossary — dense but every clause carries information. It is a long block of prose rather than a structured list, which costs some scannability.

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 an 8-parameter state-machine mutation with no output schema, the definition covers preconditions, locking, refusal codes and remedies thoroughly. The only gap is that it never says what a successful edit returns (the updated post? just an id?), leaving the success shape implicit.

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 100%, so the baseline is 3; the description earns more by mapping parameters to state: profile_ids constrained to one account during approval, and caption/media/profile_ids locked while scheduled_time stays mutable. It does not add replacement-vs-append or alt_text invalidation semantics beyond what the schema already spells out.

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 gives a precise verb set (change caption, publish time, target accounts, media) applied to a clearly bounded resource: a post that has not published yet. Eligibility is narrowed to statuses "scheduled", "pending_approval" and "draft", which cleanly separates it from sprkly_delete_scheduled_post, sprkly_schedule_post and the approval tools.

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?

It states both when to use it (the three editable statuses) and when not to (publishing_now, stuck_publishing), and routes the agent onward: re-read on post_changed, send the user to support on stuck_publishing, request approval again for a rejected post. The note that the status never changes here tells the agent this is not the approval path.

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