Skip to main content
Glama

Publish your own post to Instagram

publish_post
Destructive

Publish the user's own image(s) + caption to their connected Instagram account RIGHT NOW — story, feed post, or 2-10 image carousel. On the Free plan each post counts toward the plan's monthly posts (5 per rolling 30 days, shared with AI stories and scheduled posts); on Pro these posts don't count toward it. A light daily anti-abuse bound applies on every plan. On the Free plan a short '✨ Posted with pith.day' line is appended to feed/carousel captions (the response's finalCaption shows exactly what was posted; Pro removes it). Stories publish the image as-is and Instagram ignores story captions. Requires a connected account (connect_instagram). Timeouts are safe: pass a random idempotency_key on the first call, and if the call times out, call again with the same key OR the returned draft_id — nothing double-posts. Scheduling is not supported here — posts go out immediately.

Input Schema

NameRequiredDescriptionDefault
handleNoInstagram handle (with or without @). Omit for your default account.
slidesNoCarousel slides (2-10), each with image_url or image_base64.
captionNoThe caption, verbatim (feed/carousel; stories ignore captions).
contextYesExplain why you are calling this tool and how it fits into the business owner's goal for their Instagram presence. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include personal data, credentials, or the text of a draft. Example (20 words): "Reviewing the pending drafts before approving today's story, checking the caption matches the photo the owner expects."
draft_idNoResume a previous publish_post call: skips uploads, never double-posts.
image_urlNoPublic https image URL (story/feed). Exactly one of image_url/image_base64.
post_typeNoWhere to publish. Default feed.feed
image_base64NoRaw image bytes, base64-encoded, ≤8MB decoded (story/feed).
idempotency_keyNoRandom 8-64 char key (letters/digits/_/-). Reuse it on a timeout retry so the same post is resumed instead of re-created. Strongly recommended.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: plan quota accounting (5/30 days on Free, shared with AI stories and scheduled posts), the appended '✨ Posted with pith.day' branding line and how to detect it via finalCaption, story caption behavior, and a detailed idempotency/timeout recovery contract (same key or draft_id never double-posts). This is unusually rich behavioral disclosure for a mutation tool.

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-loads the core action and then layers constraints in a logical order (quota, branding, connection, retry, scheduling). Dense and largely waste-free, though the plan-quota and branding details make it longer than strictly needed to invoke the tool correctly.

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?

No output schema exists, yet the description still tells the agent where to confirm the final posted caption (response.finalCaption) and how to recover from timeouts. Prerequisites, side effects, and retry semantics are all covered, so nothing needed for a correct call 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 100%, so the baseline is 3, but the description adds genuine meaning on top: it explains the retry relationship between idempotency_key and draft_id and clarifies that captions are posted verbatim and ignored for stories, which the schema only hints at.

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?

States a specific verb (publish) plus resource (image(s)+caption to Instagram) and enumerates the three supported output shapes (story, feed, carousel). An agent immediately knows what the tool produces and at what scope, without needing the schema.

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

Usage Guidelines4/5

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

Gives clear conditions: posts go out immediately, scheduling is explicitly not supported here, and a connected account is required via connect_instagram. However it never names publish_draft, the obvious sibling for publishing an already-generated draft, leaving the agent to infer which of the two to pick.

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