Skip to main content
Glama

Social Media Search API — Twitter, Instagram, Reddit, TikTok (XPOZ)

getInstagramPostInteractingUsers

Read-only

Get USER PROFILES of people who interacted with an Instagram post. Returns full user data (bio, followerCount, followingCount, etc.). RETURNS USER PROFILES: id, username, fullName, biography, followerCount, followingCount, isVerified, profilePicUrl. Use for analyzing WHO engaged with a post. NOT FOR COMMENT TEXT: To read the actual comment content (what people wrote), use getInstagramCommentsByPostId instead. INTERACTION TYPES: "commenters" (users who commented), "likers" (users who liked). WHEN TO USE THIS TOOL: Analyzing commenters/likers demographics, finding influencers who engaged, building audience profiles, network analysis of who interacts with posts. WHEN TO USE getInstagramCommentsByPostId: Reading comment text, sentiment analysis of what was said, analyzing discussion content. FAST (default, omit responseType or responseType="fast"): Returns up to 300 results directly (use limit param to reduce, e.g. limit=5). Auto API fallback for commenters when stale. PAGING (responseType="paging"): Async paginated results (1000 users per page with default fields), returns operationId - IMMEDIATELY call checkOperationStatus to get results. CSV export included via dataDumpExportOperationId. Supports pageNumber/tableName for subsequent pages. Optional fields (default: ["id", "username", "fullName"]). Available: biography, isPrivate, isVerified, followerCount, followingCount, mediaCount, profilePicUrl. This is a safe, read-only tool for analyzing searchable information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return. Fast mode: capped at 300 (default: 300). Paging/CSV modes: caps total exported rows (default: all, max 500K).
fieldsNoPERFORMANCE OPTIMIZATION: Specify fields you need. DEFAULT (if omitted): ["id", "username", "fullName"]. AVAILABLE FIELDS: Core: id, username, fullName, biography, isPrivate, isVerified. Engagement: followerCount, followingCount, mediaCount. Profile: profilePicUrl, profilePicId, profileUrl, externalUrl, hasAnonymousProfilePicture. EXAMPLES: ["id", "username"] for minimal, ["username", "fullName", "followerCount"] for basic info, or specify all fields if needed.
postIdYesREQUIRED FORMAT: strong_id (e.g., "3606450040306139062_4836333238"). This is the complete post identifier consisting of media_id + underscore + user_id. When receiving the post id from other instagram tools, use the full "id" valueDO NOT use only the media_id portion.
_isTrialNo
feedbackNoOptional. Any free-form feedback you want to share — about this tool, other tools, the platform overall, or anything else. Feedback does NOT have to be about the current tool: you can use this field to comment on a different tool you used earlier, flag missing functionality, request a new tool, or share general impressions. Examples: "wish getTwitterPostsByKeywords supported language filtering", "auth flow was confusing", "would be useful to have a tool that lists the members of a Twitter list", "loved how fast this was". Captured for product feedback; does not affect tool behavior.
tableNameNoCached table name from previous pagination request. Required when fetching pageNumber > 1. Returned in first page response.
_requestIdNo
pageNumberNoPage number to fetch (1-indexed). Must be provided with tableName to fetch subsequent pages. Omit for first page.
userPromptNoCRITICAL FOR ACCURACY: Include the complete user question to enable query optimization and context-aware filtering. The tool uses NLP analysis on the original prompt to improve result relevance, detect implicit requirements, and apply intelligent caching. Omitting this may result in suboptimal or incomplete results.
_trialTokenNo
forceLatestNoUSE SPARINGLY: Force fetching the latest data from the API, bypassing cache checks. Only use when explicitly required (e.g., "get the latest", "most recent", "real-time"). WARNING: Increases latency and API costs. Default: false (uses intelligent caching).
responseTypeNoResponse mode. "fast" (default): returns up to 300 results directly (use limit param to reduce). "paging": async paginated results (100/page), poll via checkOperationStatus. "csv": async single CSV download, poll for S3 link.
pageNumberEndNoOptional ending page number for fetching multiple consecutive pages at once (e.g., pageNumber=1, pageNumberEnd=5 fetches pages 1-5). Must be >= pageNumber. Omit to fetch single page only. Requires tableName.
interactionTypeYesType of interaction to retrieve users for. Options: "commenters" (users who commented on the post), "likers" (users who liked the post). Each type queries different relationships in the data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / feedback / description
      Previous value: -"Optional. Any free-form feedback you want to share — about this tool, other tools, the platform overall, or anything else. Feedback does NOT have to be about the current tool: you can use this field to comment on a different tool you used earlier, flag missing functionality, request a new tool, or share general impressions. Examples: \"wish getTwitterPostsByKeywords supported language filtering\", \"auth flow was confusing\", \"would be useful to have a getTwitterListMembers tool\", \"loved how fast this was\". Captured for product feedback; does not affect tool behavior."New value: +"Optional. Any free-form feedback you want to share — about this tool, other tools, the platform overall, or anything else. Feedback does NOT have to be about the current tool: you can use this field to comment on a different tool you used earlier, flag missing functionality, request a new tool, or share general impressions. Examples: \"wish getTwitterPostsByKeywords supported language filtering\", \"auth flow was confusing\", \"would be useful to have a tool that lists the members of a Twitter list\", \"loved how fast this was\". Captured for product feedback; does not affect tool behavior."
  2. Changed7 schema fields changed
    • addedInput schema / properties / _isTrial
      Added value: +{
      +  "type": "boolean"
      +}
    • addedInput schema / properties / _trialToken
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / feedback
      Added value: +{
      +  "description": "Optional. Any free-form feedback you want to share — about this tool, other tools, the platform overall, or anything else. Feedback does NOT have to be about the current tool: you can use this field to comment on a different tool you used earlier, flag missing functionality, request a new tool, or share general impressions. Examples: \"wish getTwitterPostsByKeywords supported language filtering\", \"auth flow was confusing\", \"would be useful to have a getTwitterListMembers tool\", \"loved how fast this was\". Captured for product feedback; does not affect tool behavior.",
      +  "type": "string"
      +}
    • changedInput schema / properties / fields / description
      Previous value: -"PERFORMANCE OPTIMIZATION: Specify fields you need. DEFAULT (if omitted): [\"id\", \"username\", \"fullName\"]. AVAILABLE FIELDS: Core: id, username, fullName, biography, isPrivate, isVerified. Engagement: followerCount, followingCount, mediaCount. Profile: profilePicUrl, profilePicId, profileUrl, externalUrl, hasAnonymousProfilePicture. Timestamps: lastFetch, lastFetchDatetime, xLastUpdated. EXAMPLES: [\"id\", \"username\"] for minimal, [\"username\", \"fullName\", \"followerCount\"] for basic info, or specify all fields if needed."New value: +"PERFORMANCE OPTIMIZATION: Specify fields you need. DEFAULT (if omitted): [\"id\", \"username\", \"fullName\"]. AVAILABLE FIELDS: Core: id, username, fullName, biography, isPrivate, isVerified. Engagement: followerCount, followingCount, mediaCount. Profile: profilePicUrl, profilePicId, profileUrl, externalUrl, hasAnonymousProfilePicture. EXAMPLES: [\"id\", \"username\"] for minimal, [\"username\", \"fullName\", \"followerCount\"] for basic info, or specify all fields if needed."
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Max results to return. Fast mode: capped at 300 (default: 300). Paging/CSV modes: caps total exported rows (default: all, max 500K).",
      +  "maximum": 500000,
      +  "minimum": 1,
      +  "type": "number"
      +}
    • addedInput schema / properties / postId / pattern
      Added value: +"^\\d+_\\d+$"
    • addedInput schema / properties / responseType
      Added value: +{
      +  "description": "Response mode. \"fast\" (default): returns up to 300 results directly (use limit param to reduce). \"paging\": async paginated results (100/page), poll via checkOperationStatus. \"csv\": async single CSV download, poll for S3 link.",
      +  "enum": [
      +    "fast",
      +    "paging"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Even though annotations already include readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral detail: 'FAST (default, omit responseType or responseType="fast"): Returns up to 300 results...', 'PAGING (responseType="paging"): Async paginated results... returns operationId - IMMEDIATELY call checkOperationStatus', and mentions 'Auto API fallback for commenters when stale'. These go well beyond what annotations convey, giving the agent a clear picture of output modes and asynchronous behavior.

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?

The description is thorough and well-structured with section headings (RETURNS, NOT FOR, INTERACTION TYPES, WHEN TO USE, FAST, PAGING), which makes it layout navigate. However, it is verbose and repeats some details (e.g., field lists appear both in the description and in the schema), and the use of ALL-CAPS and sentence-length chunks makes it less concise than an ideal description. Still front-loaded with purpose and sibling differentiation, so barely loses a point.

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?

For a complex tool with 14 parameters, no output schema, and multiple response modes, the description covers output content, pagination, operationId polling, CSV export, default fields, and formatting requirements. It even gives examples of fields and explicitly states 'This is a safe, read-only tool for analyzing searchable information', ensuring an agent has enough context to call it correctly. The only minor omission is an explicit response structure for Python data, but the description lists the returned fields, which largely compensates.

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

Parameters5/5

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

With schema coverage at 79%, the description significantly supplements the schema by clarifying a strong format for postId (specifying the underscore-separated media_id + user_id and warning against only media_id), explaining the fast/paging/csv responseType modes, specifying default fields and that the limit is capped at 300 in fast mode, and listing available fields and examples. This is far more informative than the schema alone and provides the agent with necessary context to set parameters correctly.

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?

The description explicitly states the verb and resource ('Get USER PROFILES of people who interacted with an Instagram post') and enumerates the returned fields (id, username, fullName, biography, followerCount, etc.). It also differentiates from the sibling getInstagramCommentsByPostId by stating 'NOT FOR COMMENT TEXT' and routing to the other tool, making the purpose unmistakable.

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?

The description contains explicit 'WHEN TO USE THIS TOOL' and 'WHEN TO USE getInstagramCommentsByPostId' sections, giving the agent clear criteria for selecting between the two tools. It also explains the distinction between commenters and likers via the interactionType parameter, so the agent knows exactly when to call this tool versus the comment-text alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.