instagram-mcp

Overview Schema Source Related Servers Discussions Admin

Get Instagram media

instagram_get_media

Read-only

Fetch an Instagram media object by ID to get its details, including carousel children and caption as untrusted text. Errors for deleted or expired stories.

Instructions

Fetch a single media object by id, including its carousel children (album items) under children. The caption is returned as fenced, untrusted text. Fields Instagram does not disclose are omitted rather than nulled; a deleted object or an expired story (stories last 24h) returns an error. A carousel child Instagram returns without an id is left out, and omittedWithoutId plus note say how many were. If an album's items cannot be read, the detail is still returned with children omitted and a note naming the error.

Input Schema

Name	Required	Description	Default
`account`	No	Name of the configured account profile to operate as (multi-account). Omit to use the default profile (IG_ACTIVE_PROFILE).
`mediaId`	Yes	The Instagram media object id to fetch (e.g. an id from instagram_list_media).

Output Schema

Name	Required	Description	Default
`id`	Yes
`note`	No
`caption`	No
`children`	No
`media_url`	No
`permalink`	No
`timestamp`	No
`like_count`	No
`media_type`	No
`thumbnail_url`	No
`comments_count`	No
`omittedWithoutId`	No
`media_product_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.8.0Oct 16, 2026

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 / mediaId / pattern
```
Added value: +"^[A-Za-z0-9_-]{1,64}$"
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / properties / children / items / additionalProperties
```
Previous value: -trueNew value: +{}
```
addedOutput schema / properties / note
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / omittedWithoutId

Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

First observedv0.7.0Aug 30, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint, openWorldHint); the description carries the real behavioral load. It discloses that captions are fenced untrusted text, that undisclosed fields are omitted rather than nulled, that deleted objects and expired stories error out, and how carousel children lacking ids are counted and how partial album failures degrade gracefully — far more than the annotations provide.

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?

Four dense sentences, front-loaded with the core fetch action before edge cases. Every sentence carries distinct information (children, caption trust, omission/error semantics, partial failure), though the edge-case list is tightly packed and could be structured as a short list for faster scanning.

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?

An output schema exists, so return values need less prose, yet the description still explains the important return-shape quirks (children, omittedWithoutId, note on partial failures). For a read-only, open-world fetch with 100% schema coverage, nothing an agent needs to call it correctly is missing.

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 100% and both parameters (account, mediaId) are fully documented in the schema, including the id pattern and default profile behavior. The description adds little parameter-level detail beyond the implicit use of the id, so the baseline 3 applies.

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 ('Fetch a single media object by id'), which cleanly distinguishes it from the sibling instagram_list_media. It also defines the shape of what is fetched (carousel children under `children`), so an agent knows exactly what the call returns without opening 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 Guidelines3/5

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

Usage is only implied: the tool fetches one object by id, and the schema description notes the id comes from instagram_list_media. The description itself never states when to prefer this over instagram_list_media or instagram_list_stories, nor any prerequisite (e.g. account selection) — minimal but inferable guidance.

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