Skip to main content
Glama
thenavidm

ScrapeCreators MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Comments

instagram_comments

Fetches comments on public Instagram posts or reels, returning text, timestamps, reply counts, and commenter details with cursor pagination; optionally includes first-page replies.

Instructions

Retrieves comments on a public Instagram post or reel. Each comment includes the comment text, creation timestamp, reply count when Instagram provides it, and commenter details such as username, user ID, verification status, and profile picture URL. child_comment_count can be null when Instagram does not expose the count publicly. Set include_replies=true to fetch the first page of replies for every returned comment. This adds replies, replies_cursor, and has_more_replies to each comment. This option always costs 15 credits because Scrape Creators makes a separate Instagram replies request for every comment in the response. It is possible that no replies are returned, but you will still be charged 15 credits because those reply lookups were performed. This option is much slower than a normal comments request and may time out at 29 seconds. Supports cursor-based pagination to load additional comment pages. Potentially consumes paid API credits; requires confirm=true. Read-like POST requests do not publish to social platforms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL of the post or reel to get comments from
cursorNoThe cursor to get more comments. Get 'cursor' from previous response.
accountNoNamed private ScrapeCreators account; selects credentials, not a remote account ID.
confirmNoMust be true for the specific approved credit-consuming research call.
include_repliesNoSet to true to include replies for every returned comment. This always costs 15 credits because each comment requires a separate Instagram replies request. You will still be charged 15 credits if no replies are returned. This is much slower and may time out at 29 seconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorld=true) by disclosing the credit-consuming nature, the confirm=true requirement, the fixed 15-credit cost of include_replies even when no replies come back, the slower runtime and 29-second timeout risk, and that child_comment_count can be null. This is exactly the kind of cost/failure-mode disclosure 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-loads purpose and return fields, then the cost/timeout warnings. Some sentences duplicate the schema's include_replies description, but the repetition is on a high-stakes cost point, so it mostly earns its space.

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?

With no output schema, the description still names the returned fields and the optional replies fields, plus pagination and credit/timeout behavior. An agent has everything needed to decide and call correctly.

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 the schema already documents all five parameters, including the cost warning on include_replies. The description's parameter discussion largely restates the schema rather than adding syntax or format meaning, 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 ('Retrieves comments on a public Instagram post or reel') and enumerates the returned fields, so an agent knows exactly what it gets. It is also clearly distinguishable from siblings like instagram_comment_replies or instagram_post_reel_info.

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?

Gives clear operational context: cursor pagination for more pages, and the include_replies option with its cost/speed tradeoff, which implicitly routes agents who want replies. It never explicitly names an alternative tool (e.g. instagram_comment_replies) or states when not to use this one, so it falls short of a 5.

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