Skip to main content
Glama
ig-studio-mcp

ig-studio-mcp

by Luffy610

publish_image

Publishes a single photo to an Instagram feed only after returning a preview and receiving user confirmation, preventing accidental posts.

Instructions

Publish a single photo to the user's Instagram feed. Public and immediate.

Use only when the user explicitly asks to post. ALWAYS call with confirm=false first: that returns a preview (image URL, exact caption, warnings) and sends nothing. Show it to the user and call again with confirm=true only after they approve.

Args: image_url: Public URL of a JPEG that Instagram can download (no login or expiring link). Max 8 MB, aspect ratio between 4:5 and 1.91:1, width 320-1440 px. caption: Post text. Max 2,200 characters, 30 hashtags, 20 @mentions. confirm: false = preview only (default); true = publish.

Returns: executed, summary, container_ids, and media_id + permalink once published. Limits: a capped number of API posts per rolling 24 hours (see get_publishing_limit). Publishing usually takes seconds but can take up to ~5 minutes while Instagram processes it.

Input Schema

NameRequiredDescriptionDefault
captionNo
confirmNo
image_urlYes

Output Schema

NameRequiredDescriptionDefault
notesNo
actionYes
captionNo
summaryYes
executedYesFalse = preview only; nothing was sent to Instagram
media_idNoID of the published post
permalinkNo
image_urlsYes
container_idsNoMedia containers created (children first)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations flag the write nature (readOnlyHint=false, idempotentHint=false, openWorldHint=true) but say nothing about visibility or timing; the description adds that the post is 'Public and immediate', that confirm=false sends nothing, that a rate cap applies per rolling 24 hours, and that publishing can take up to ~5 minutes. These are exactly the side-effect details an agent cannot infer from the structured fields.

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 purpose, then the gating condition and the confirm protocol, then per-argument detail — a clean progression with no filler sentences. It is on the long side, but the length is driven by genuinely load-bearing constraints rather than repetition.

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 an open-world, non-idempotent mutation with three params, the description covers preconditions, the safety protocol, parameter bounds, return shape (executed, summary, container_ids, media_id, permalink), rate limits, and latency. An output schema exists but the description's summary of returns and the partial-failure semantics is still additive rather than redundant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does: image_url is constrained to a publicly downloadable JPEG with 8 MB, 4:5–1.91:1, and 320–1440 px limits; caption has character/hashtag/mention caps; confirm is defined as preview-only (default false) versus publish. None of this appears in 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?

States a specific verb and resource ('Publish a single photo to the user's Instagram feed') with scope qualifiers 'Public and immediate'. The word 'single' distinguishes it from publish_carousel without needing to open either 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?

Explicitly restricts use to 'only when the user explicitly asks to post' and prescribes a mandatory two-phase protocol: call with confirm=false, show the preview, then call with confirm=true after approval. It also routes the agent to get_publishing_limit for quota questions, naming the exact sibling.

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