instagram-mcp-server

Create Media Container

instagram_create_container

Creates an Instagram media container with custom parameters without publishing, letting you use unexposed options or assemble carousels; returns the container ID for later publishing.

Instructions

Low-level escape hatch: create a media container with arbitrary parameters, without publishing it.

Prefer instagram_publish_image / _reel / _story / _carousel, which run the whole flow. Use this when you need a parameter those tools do not expose, or when assembling a carousel from children that were created earlier.

Returns the container ID. Publish it with instagram_publish_container.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "instagram_create_container"
  }
}

Input Schema

Name	Required	Description
`caption`	No	Caption text, up to 2200 characters. Hashtags and @mentions work inside the caption. Instagram counts a maximum of 30 hashtags.
`children`	No	Child container IDs, for media_type=CAROUSEL
`image_url`	No
`video_url`	No
`account_id`	No	Instagram professional account ID. Omit to use the token's own account.
`media_type`	No	Omit for a single image; Instagram infers IMAGE
`extra_params`	No	Any other documented container parameter, passed through verbatim (e.g. cover_url, thumb_offset, share_to_feed, alt_text, product_tags, upload_type).
`is_carousel_item`	No	True when this container is a carousel child

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the write/external-effect profile is covered. The description adds meaningful sequencing context beyond that: the container is created but not published, an ID is returned, and publication is a separate step via instagram_publish_container. It stops short of stating container lifetime/expiry or that retries create duplicate unpublished containers, which would be valuable for a non-idempotent creation call.

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?

Three short blocks with zero waste: the escape-hatch framing and the primary alternative are front-loaded, then the usage condition, then the return value and next step. Every sentence carries distinct information.

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 a no-output-schema tool with 8 mostly optional parameters, the description does the essential work: what it returns (container ID) and what to do next (publish it). It omits container expiry and any note that unpublished containers accumulate against a limit, which for a non-idempotent creation tool is the remaining gap.

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

Parameters3/5

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

Schema description coverage is 75%, so the schema carries most parameter meaning. The description does add one genuinely extra semantic constraint: children must have been "created earlier," establishing the ordering dependency for carousel assembly. However, it says nothing about how extra_params passthrough behaves (validation, precedence over top-level fields) or about the media_type/image_url/video_url combination rules, leaving those to 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?

"Low-level escape hatch: create a media container with arbitrary parameters, without publishing it" names a specific verb (create), resource (media container), and scope (unpublished). The framing as an escape hatch plus the explicit contrast with the higher-level publish tools makes it immediately distinguishable from siblings like instagram_publish_container.

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 gives an explicit default ("Prefer instagram_publish_image / _reel / _story / _carousel, which run the whole flow") and two concrete conditions for choosing this tool instead: a parameter the high-level tools don't expose, or assembling a carousel from pre-existing children. The alternative path and its trigger conditions are stated, not inferred.

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

Deploy Server