Skip to main content
Glama
FastSocialCo

instagram-data-mcp

by FastSocialCo

instagram_comment_replies

Read-only

Retrieve replies to a specific Instagram comment, paging through nested threads with a cursor to review full comment conversations.

Instructions

Get replies to an Instagram comment. Replies under one comment. Page with cursor.

Cost: 3 credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoPost, reel or IGTV URL. Pass this or shortcode.
cursorNonext_cursor from the previous page of the same request.
shortcodeNoThe code in the post URL (instagram.com/p/<code>/).
comment_idYesid of a comment from /v1/comments.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds two useful behavioral facts: pagination via cursor and a billing cost of 3 credits. It does not disclose rate limits or result caps, so it adds moderate value over the annotations.

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?

Three short, front-loaded fragments with no filler. 'Replies under one comment.' is slightly redundant with the first sentence, keeping it just short of a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, single-required-param tool with no output schema, the definition covers purpose, paging, and cost adequately. It omits return-shape hints and any explicit relationship to instagram_comments, leaving a small but real 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 100%, so all four parameters (url, cursor, shortcode, comment_id) are documented in the schema itself. The description only echoes cursor paging and adds nothing about parameter format or precedence, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (get replies to an Instagram comment) and clarifies scope with 'Replies under one comment.' It implicitly distinguishes itself from instagram_comments (top-level comments) but never names that sibling explicitly, so differentiation rests on inference.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of the natural alternative (instagram_comments) for fetching the parent comments. The reader must infer that this tool is for drilling into a comment thread after obtaining a comment_id.

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