Skip to main content
Glama
Sign In
instagram-mcp

instagram-mcp

by IvanBBaev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Post an Instagram image or carousel

instagram_post_image

Publish a single image or 2–10 image carousel to Instagram in one call: create containers, wait for processing, then publish. Preview by default; resume with resumeContainerId to avoid duplicates.

Instructions

Publish a single feed image, or a 2–10 image carousel, in one call: create the container(s), wait for processing, then publish. Preview (the default) performs nothing. If processing exceeds the poll budget the result is status=in_progress with a resume_container_id — re-run with apply:true and resumeContainerId to finish (never create a new post, which would duplicate it). Image format, byte size, and dimensions are validated by Instagram on fetch, not here.

Input Schema

NameRequiredDescriptionDefault
applyNoSet true to actually perform this write. Omitted (or false) returns a non-mutating preview of exactly what would happen and calls nothing, unless IG_WRITE_MODE=apply is configured. An explicit false always forces preview.
accountNoName of the configured account profile to operate as (multi-account). Omit to use the default profile (IG_ACTIVE_PROFILE).
captionNoCaption text (≤ 2200 characters, ≤ 30 hashtags, ≤ 20 @mentions — counted as a client-side guard). Instagram renders @mentions and #hashtags.
userTagsNoUser tags for a single feed image (not carousels): handles with optional 0–1 x/y.
imageUrlsNoPublic HTTPS JPEG image URL(s) Instagram will fetch. One URL posts a single feed image; 2–10 URLs post a carousel album. Required unless resuming. Format/size/dimensions are unverifiable before Instagram fetches them.
locationIdNoInstagram location Page id to tag on the post.
resumeContainerIdNoResume a container from a previous apply that returned status=in_progress: pass its resume_container_id to finish publishing instead of creating a new post (avoids a duplicate). When set, the media inputs are ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.8.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / imageUrls / items / pattern
      Added value: +"^ *[Hh][Tt][Tt][Pp][Ss]:\\/\\/"
    • addedInput schema / properties / locationId / pattern
      Added value: +"^[A-Za-z0-9_-]{1,64}$"
    • addedInput schema / properties / resumeContainerId / pattern
      Added value: +"^[A-Za-z0-9_-]{1,64}$"
    • removedInput schema / properties / userTags / items / additionalProperties
      Removed value: -false
  2. First observedv0.7.0

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: the write is gated behind an opt-in apply flag with a non-mutating preview default, the poll budget can end in status=in_progress with a resume_container_id, and the duplication hazard of re-creating on resume is called out. It also discloses that format/size/dimension validation happens on Instagram's fetch rather than client-side, which is exactly the kind of non-obvious behavior an agent needs.

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 preview behavior, then the resume path — three tight sentences with no filler. Minor redundancy: 'Preview (the default) performs nothing' restates the apply parameter's schema text and is slightly awkwardly phrased.

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, so the description carries the return-value burden and does so: it names status=in_progress and resume_container_id, the two fields an agent must branch on. Combined with the thorough schema and annotations, nothing material about correct invocation 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 baseline would be 3, but the description adds cross-parameter semantics the schema documents only in isolation: the apply+resumeContainerId combination that finishes an in-progress publish, and the fact that resuming supersedes media inputs. The apply-to-post and resume-to-finish relationship is the key invocation contract and is spelled 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?

States a specific verb (publish) and resource (single feed image or 2–10 image carousel) and describes the full workflow it encapsulates: create container(s), wait, publish. This lets an agent distinguish it from the lower-level siblings instagram_create_media_container / instagram_publish_media and from instagram_post_reel / instagram_post_story by media type.

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?

Explains the preview-vs-apply default clearly and gives explicit recovery guidance ('re-run with apply:true and resumeContainerId', 'never create a new post, which would duplicate it'), which is genuinely actionable. It stops short of explicitly routing the agent to sibling tools (e.g., which tool to use for reels/stories or when to drop to the container-level primitives), leaving that to name inference.

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