Skip to main content
Glama
Sign In

Ignix

by social.ignix
OverviewDiscussionsAdmin

Update a post

update_post
Destructive

Edit an existing post (typically a draft or a scheduled one): copy, media, target accounts, schedule. Fields you omit keep their current value. Dates: scheduledFor SCHEDULES the post (a draft becomes scheduled and will be published at that time); to only change the date proposed on a draft and keep it a draft, use suggestedFor.

Input Schema

NameRequiredDescriptionDefault
postIdYes
altTextNoAccessibility alt text per image, keyed by its URL in mediaUrls: {"https://…/a.jpg":"A dog on a red sofa"}. Applied on Instagram feed, Facebook, Threads, X (max 1000), LinkedIn, Bluesky and Pinterest (max 500); ignored elsewhere. Write it for every image you attach — a post without alt text is unreadable to screen readers, and several networks rank it.
contentNo
mediaUrlsNoPublic https URLs of images/videos to attach. THE ORDER MATTERS: it is the carousel order the reader swipes through, and the first one is the cover — the image that shows in the profile grid. Get them from generate_image, generate_video (via get_media_job), upload_media (for a file on the user's machine), import_media (for a url that is already public) or list_library_media.
accountIdsNoIgnix account ids from list_accounts.
publishNowNo
scheduledForNoISO 8601. Schedules the post for this time (a draft becomes SCHEDULED). Omit to keep the current one.
suggestedForNoISO 8601. Only for a draft: changes the date proposed for review and keeps it a draft (nothing gets scheduled).
idempotencyKeyNoOptional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.
networkOptionsNoNetwork-specific options keyed by platform: first comment, collaborators, cover image, privacy, board, flair, TikTok consent… e.g. {"instagram":{"firstComment":"…","collaborators":"user1,user2"},"youtube":{"visibility":"public"},"pinterest":{"boardId":"…"}}. Call get_network_options for the EXACT list each network accepts, with types, accepted values and which ones are required.
perNetworkTextNoDifferent copy per network, keyed by platform, e.g. {"x":"short version","linkedin":"long version"}. Networks not listed use the main content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / scheduledFor / description
      Previous value: -"ISO 8601. Omit to keep the current one."New value: +"ISO 8601. Schedules the post for this time (a draft becomes SCHEDULED). Omit to keep the current one."
    • addedInput schema / properties / suggestedFor
      Added value: +{
+  "description": "ISO 8601. Only for a draft: changes the date proposed for review and keeps it a draft (nothing gets scheduled).",
+  "type": "string"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description still adds real behavior: updates are a partial merge (omitted fields retain their value) and scheduledFor can flip a draft into a scheduled/published state. It does not address what happens when editing an already-published post or whether a republish is required.

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

Conciseness5/5

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

Two compact sentences plus a targeted date clarification, with the core action and partial-update rule front-loaded. No filler, and the scheduledFor/suggestedFor contrast is placed where an agent will read it before touching those fields.

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 11-parameter mutation tool with no output schema, the description covers the editable surfaces (copy, media, accounts, schedule) and the trickiest date semantics. Gaps remain around published-post behavior and required permissions, which matter for a destructive operation.

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 73%, so the schema carries most of the load and a baseline of 3 would apply. The description earns the extra point by contrasting the two easily-confused date parameters (scheduledFor schedules; suggestedFor only re-dates a draft), which is the highest-risk ambiguity in this 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 states a specific verb+resource ('Edit an existing post') and immediately narrows the target to 'typically a draft or a scheduled one'. It also clarifies the patch semantics ('Fields you omit keep their current value'), which an agent cannot infer from the name alone. It stops short of naming sibling tools like schedule_post or attach_media_to_post, so sibling differentiation is only partial.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is given ('typically a draft or a scheduled one') and the scheduledFor vs suggestedFor choice is spelled out, but that is a parameter-level decision, not tool-level routing. Nothing tells the agent when to prefer update_post over schedule_post, unschedule_post, or attach_media_to_post for the same outcome.

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

All Ignix toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources