Instagram MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
Most tools target distinct resources (posts, reels, stories, highlights, insights, DMs), but get_user_profile can also fetch posts/reels via sections, overlapping with get_user_posts/get_user_reels. transcribe_reel and analyze_reel_with_gemini also have similar scopes, though descriptions clarify their different outputs.
Naming Consistency4/5
The naming is mostly verb_noun (get_user_posts, follow_user, like_post) but has deviations: comment_on_post uses a preposition, analyze_reel_with_gemini includes a service modifier, and get_dm_conversation abbreviates 'direct message' inconsistently with get_direct_inbox.
Tool Count2/5
With 28 tools, this exceeds the 3-15 well-scoped range. The broad Instagram domain justifies many features, but the count feels heavy; for instance, the four insights tools could be consolidated into one parameterized tool, and the transcription/analysis tools add redundancy.
Completeness4/5
The surface comprehensively covers viewing, searching, engaging (like/follow/comment/save), DMs, insights, and content details. Minor gaps exist: no tool to edit/delete posts or comments, and follower/following lists are only available as raw sections from get_user_profile rather than structured data.
Average 4.1/5 across 28 of 28 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations mark destructiveHint=true, but the description describes a simple save action (clicking Save), which is not destructive. This is a direct contradiction between the described behavior and the annotation, severely impairing transparency. The description also does not address any side effects or reversibility.
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 well-structured with a clear purpose statement, behavior explanation, and Args/Returns sections. It is concise but includes the unnecessary ctx mention, keeping it from a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and minimal complexity, the annotation contradiction is unresolved and the description lacks any usage guidance or discussion of side effects. This makes the description incomplete for an agent to safely and correctly invoke the tool.
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?
The description provides useful meaning for post_url with an example and explains collection as optional, compensating for the 0% schema coverage. However, it lists 'ctx' as an argument that is not present in the input schema, which could mislead the agent about the actual accepted parameters.
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 opens with 'Save a post to a collection,' which clearly states the verb and resource. It distinguishes this tool from siblings like like_post or follow_user by focusing on the Save action and optional collection specification.
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?
The description implies usage by stating it navigates to a post and clicks Save, and optionally targets a collection. However, it offers no explicit when-to-use guidance versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the readOnlyHint annotation: it explains the return format (Dict with url, sections as raw text) and instructs the LLM to parse the raw text. It also adds the account availability restriction. This goes beyond what annotations provide, earning a solid score.
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 well-structured with separate sections for args and returns, and the availability note is prominently placed. It is concise but loses a point due to the unnecessary mention of 'ctx' which adds noise and potential confusion.
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 tool with one parameter and an output schema, the description covers the essential return format and parsing expectation. However, it does not clarify what 'profile activity insights' actually contain, nor does it help the agent choose this over related insights tools. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enriches the only schema parameter 'time_range' by specifying allowed values (7d, 30d, 90d) and a default. However, it also documents 'ctx' as an argument, which is not present in the input schema (and additionalProperties is false). This is misleading and contradicts the schema, so the parameter guidance is partially unreliable.
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?
The description states a specific verb and resource: 'Get profile activity insights from Professional Dashboard.' This clearly indicates what the tool does. However, it does not distinguish it from sibling tools like get_business_insights or get_content_insights, which might also provide insight-related data, so it misses the opportunity to differentiate.
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?
The note 'Professional Dashboard is only available for Business and Creator accounts' provides a clear prerequisite and limits when the tool should be used. Yet, it does not explicitly say when to prefer this tool over alternatives or mention any exclusions, so the guidance is only partly useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so no mutation concern. The description adds useful behavioral details like the max_posts limit (default 50) and the presence of a progress-reporting context (ctx), but it does not mention pagination, rate limits, or handling of private accounts. This adds some value but is not rich, fitting the lower bar set by annotations.
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?
The description is well-structured with a one-sentence summary, Args section, and Returns section. Every sentence is informative, no filler. It is appropriately sized for a tool with two parameters, and the front-loaded summary gives immediate clarity.
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?
Given the tool's simplicity, the output schema exists and covers return values, and annotations cover safety, the description is fairly complete. It includes parameter details and return structure. However, it lacks usage guidance and has a minor ctx parameter mismatch, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does: username is described as Instagram username with examples, and max_posts is explained as the maximum to retrieve. However, it also lists 'ctx' as an arg that is not present in the input schema, which is a minor inconsistency but does not detract from the value added for the actual parameters.
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?
The description clearly states the tool gets an Instagram user's posts with structured data. The verb 'get' and resource 'posts' are specific and match the tool name, distinguishing it from sibling tools like get_user_reels or get_user_stories, though it doesn't explicitly name those alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools like get_user_reels or get_user_stories, nor does it specify scenarios where this tool is preferred. The only context is the tool name and sibling list, which are not enough for explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals a key behavioral nuance: the return is a dict with 'sections (name -> raw text)' and the LLM must parse the raw text to extract users and profiles. This alerts the agent to expect non-structured output requiring interpretation, which is valuable and non-obvious.
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 brief and front-loaded with the purpose. The Args/Returns structure is clean and scannable. The only issue is the extraneous 'ctx' line, which adds noise; otherwise the description is appropriately sized and well-organized.
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 simple search tool with only two schema parameters, readOnly/openWorld annotations, and an output schema, the description covers the essential invocation details and return format. It explains the need to parse raw text, which is critical context. The lack of usage alternatives is a gap, but the description still feels complete for the tool's complexity.
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 coverage is 0%, so the description must compensate. It does define query with concrete examples and max_results with a default. However, it also lists 'ctx' as an arg, which is absent from the input schema and excluded by additionalProperties: false. This could lead the agent to pass an invalid parameter, undermining trust in the parameter documentation.
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?
The description opens with 'Search for Instagram users.', clearly stating the verb and resource. It distinguishes from search_locations by resource type, though it doesn't explicitly state whether search matches usernames, full names, or both. Example queries ('john doe', 'photographer') imply free-text search, which helps clarify scope.
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?
The description gives no guidance on when to use this tool versus alternatives like get_user_profile or search_locations. There is no mention of preferred contexts, exclusions, or contrasting sibling tools. The agent gets no help deciding between searching and directly fetching a known user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the operation as read-only and open-world. The description adds useful context by specifying 'active stories' and including return fields like expires_at, which conveys the ephemeral nature of stories. However, it introduces a 'ctx' parameter absent from the input schema, which creates slight ambiguity about invocation 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 well-structured with Args and Returns sections, making it easy to scan. It is concise, though the inclusion of the additional 'ctx' parameter is arguably unnecessary and could be removed to avoid noise.
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 single-parameter, read-only tool, the description covers the core purpose and return shape, especially since an output schema exists. However, it lacks sibling differentiation and contains the unexplained 'ctx' parameter, which prevents it from being fully reliable as a standalone specification.
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?
The input schema provides only a bare 'username' string, and the description adds valuable examples and clarifies it is an Instagram username. However, the description also lists a 'ctx' parameter for progress reporting that is not present in the input schema, which muddies the actual parameter contract and could confuse an agent trying to invoke the tool.
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 opens with a clear, specific statement of what the tool does: 'Get an Instagram user's active stories.' It names the resource and scope ('active stories'), which distinguishes it from sibling tools like get_user_posts and get_user_highlights.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives. The word 'active' implies ephemeral stories, but there is no mention of when not to use it or how it compares to related tools such as get_user_highlights or get_user_reels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (openWorldHint, destructiveHint) already convey that this is a state-changing operation with external side effects. The description adds the behavioral detail that it 'navigates to the post and clicks the Like button,' which explains the mechanism but does not disclose additional side effects like requiring authentication or rate limits. It aligns with the annotations rather than adding substantial transparency beyond them.
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 structured with clear sections and front-loads the purpose in the first sentence. The Args and Returns sections are useful but the Returns section duplicates the output schema, and the ctx parameter adds minor bloat since it's not in the schema. Overall it is concise and readable.
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 simple action like liking a post, the description covers the main aspects: what it does, the URL format, and the return type. However, it does not mention any prerequisites (e.g., login/session) or caveats, and it lacks comparison to similar tools. With the annotations and output schema present, it is reasonably complete but not exemplary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists post_url without any description, so the description's example URL format ('https://www.instagram.com/p/ABC123/') provides essential clarity. The mention of a ctx parameter that is not in the schema introduces slight confusion, but the post_url semantics are well-covered.
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 clearly states the tool's function: 'Like a post' and elaborates with 'Navigates to the post and clicks the Like button.' This is a specific verb+resource that distinguishes it from siblings like unlike_post.
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?
The description does not explicitly state when to use this tool versus alternatives such as unlike_post, nor does it provide exclusion criteria. However, the context implies it is for liking a specific post by URL, which gives some usage guidance. It lacks a clear 'when to use' vs 'when not to use' recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior such as downloading the video (implied by keep_video), generating SRT, and returning a dict with fields. It also mentions ctx for progress reporting. However, it does not explain the download process, temporary files, or any rate limits, and the readOnlyHint annotation might seem at odds with file creation, but not enough to call a contradiction.
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 efficiently structured into Args and Returns sections, with the purpose clearly front-loaded. The inclusion of ctx is slightly extraneous but acceptable; overall, it is compact and readable.
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?
With output schema present, the return value explanation is somewhat redundant. The description covers inputs and outputs but omits prerequisites such as account authorization, privacy settings, or rate limits. It also doesn't clarify what 'etc.' includes or whether transcription requires external services, leaving some gaps for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by explaining reel_url with a full URL example and keep_video with its default. It also documents the internal ctx parameter. This adds meaning beyond the bare schema, though it could provide more details on URL validation or output file naming.
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 clearly states the tool's function: 'Transcribe a single Instagram reel to SRT.' It uses a specific verb ('transcribe') and resource ('single Instagram reel'), and the 'single' qualifier distinguishes it from sibling tool transcribe_user_reels.
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?
While the description specifies it handles a single reel via reel_url, it does not explicitly mention when to use this versus transcribe_user_reels or other transcription tools. The distinction is implied by 'single' but no alternatives are named or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true and openWorldHint=true annotations, the description adds valuable behavioral context: the return structure (url, sections, optional references) and an operational instruction that 'The LLM should parse the raw text in each section.' This helps the agent understand how to handle the output.
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?
The description is well-organized with clear sections (intro, note, args, returns) and is concise—no redundant sentences. Every line contributes to understanding the tool's purpose, restrictions, parameters, and output handling.
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?
Given a single optional parameter, an existing output schema, and annotations, the description covers the essential operational aspects: purpose, account restriction, parameter values, return structure, and a parsing instruction. Minor gaps like error handling or examples are not critical for this simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows time_range with a default, with 0% description coverage. The tool description compensates by specifying allowed values ('7d, 30d, 90d') and the default ('7d'), which is meaningful guidance beyond the schema.
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?
The description clearly states a specific verb ('Get') and resource ('Business/Creator account insights from Professional Dashboard'). While it doesn't explicitly contrast with sibling insight tools like get_audience_insights, the reference to Professional Dashboard provides a distinct scope.
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?
The description gives a clear prerequisite: 'Professional Dashboard is only available for Business and Creator accounts.' However, it provides no guidance on when to use this tool versus the other insight-specific tools (e.g., audience, content, activity), so alternatives are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and openWorldHint=true. The description adds minimal behavioral context (navigates, clicks button) and return format, but does not disclose potential side effects, failure modes, or authorization requirements beyond what annotations imply.
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 concise and well-structured with clear sections (action, args, returns). Every sentence contributes, though including ctx in Args despite not being in the schema is slightly redundant.
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 simple tool with one parameter, the description covers the action, arguments, and return format. It is adequate given the annotations and output schema, though it could mention prerequisites or error conditions for greater completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the username parameter with an example ('e.g., natgeo'). It also mentions ctx for progress reporting, but this is not in the schema. This adds meaning beyond the bare 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?
The description clearly states the tool's purpose: 'Unfollow a user' and explains the mechanism (navigates to profile and clicks Unfollow). This specific verb+resource distinguishes it from sibling tools like follow_user.
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?
The usage is implied through the action name and description, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions (e.g., user must currently be followed). The description does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already indicates destructive behavior. The description adds 'clean up resources,' providing context about side effects, but it does not detail what happens to the session (e.g., whether it logs out, closes browser, or releases credentials). With annotations covering the destructive nature, this is adequate but not overly rich.
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?
The description is a single concise sentence that is front-loaded with the action ('Close') and resource ('Instagram browser session'). Every word earns its place; no fluff or redundancy.
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?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description sufficiently communicates the action. Minor gap: it doesn't state whether the session is invalidated or just closed, but for a close-session tool this is acceptable. Overall, complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no burden of explaining parameter meanings. The schema is trivially complete, and the description adds value by clarifying the action's purpose. Baseline for 0 params is 4.
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 uses a specific verb ('close') and resource ('current Instagram browser session'), clearly distinguishing this from sibling tools which focus on data retrieval or social actions. It also indicates cleanup of resources, which adds scope clarity.
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?
The description implies usage by mentioning 'current session,' but it does not explicitly state when to use this tool versus alternatives (e.g., 'use when you are done with a session'). Since there are no alternative session tools among siblings, the guidance is somewhat implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description aligns by using the verb 'Read'. It goes beyond annotations by detailing the return structure ('Dict with url, sections...') and the one-of parameter requirement, which is useful behavioral context.
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 organized with Args and Returns sections, making it easy to parse, and the opening sentence is concise. It could be slightly shorter by removing the ctx line, but it remains efficient and well-structured.
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?
Given the tool's simplicity, the description covers the key aspects: identification, limit, and return format. It lacks potential edge-case details like what happens if both identifiers are provided, but this is a minor gap.
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?
The input schema has no property descriptions (0% coverage), so the description fills the gap by explaining thread_id, username, and limit, including the default and range for limit. It also mentions ctx, a parameter not present in the schema, which adds completeness.
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?
The description opens with 'Read a specific DM conversation', which clearly states the verb and resource. It doesn't explicitly name sibling tools like get_direct_inbox, but the qualifier 'specific' distinguishes it from list-type tools.
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?
It instructs to 'Provide either username or thread_id to identify the conversation', which is clear guidance on prerequisites. However, it doesn't explicitly say when not to use it or mention alternatives like get_direct_inbox or send_dm, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context by specifying the return structure (url, sections, optional references) and instructing the LLM to parse raw text for locations. No contradiction with annotations.
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?
The description is a well-structured docstring with a summary, args, and returns sections. Every sentence adds relevant information, and there is no redundant filler.
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 simple search tool, the description covers the query parameter, result limit, and response format. The output schema and annotations fill in much of the remaining context, though it could benefit from usage differentiation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining 'query' with examples and clarifying 'max_results' as a default-limited count. It also mentions 'ctx' for progress reporting, adding meaning beyond the bare schema fields.
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 clearly states 'Search for Instagram locations' with a specific verb and resource. It distinguishes itself from sibling tools like 'search_users' by targeting locations as the search subject.
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?
There is no guidance on when to use this tool versus alternatives such as get_location_posts or search_users. The description only lists parameters, leaving the usage context entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and openWorldHint=true, providing safety context. The description adds the behavioral detail that the tool navigates to the post and clicks the Unlike button, which is an implementation detail but not substantive beyond what annotations suggest. It does not disclose idempotent behavior or failure modes when the post is already unliked.
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?
The description is concise, spending one sentence on purpose, one on mechanism, and then structured Args/Returns. It includes an example URL, and every sentence contributes value without waste.
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?
Given the tool's simplicity, the description covers the essential information: what it does, the input parameter, and the return structure. The output schema exists, and annotations provide safety hints, so the description is reasonably complete. The lack of usage guidance and the ctx ambiguity are minor gaps but do not undermine overall completeness for this simple mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only includes post_url, and the description explains it as an Instagram post URL with an example format. This compensates for the 0% schema description coverage. However, the description also lists 'ctx' as an argument that is not present in the schema, which could cause minor confusion.
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 opens with 'Unlike a post,' a specific verb+resource that clearly states the tool's function. It further specifies 'Navigates to the post and clicks the Unlike button,' making the action unambiguous. This distinguishes it from sibling tools like like_post and save_post.
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?
The description does not explicitly state when to use this tool versus alternatives such as like_post or unfollow_user. The context is implied: it's for removing a like from an Instagram post. No prerequisites or exclusions are mentioned, so the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint and destructiveHint, indicating side effects and potential for destructive actions. The description adds valuable context beyond these annotations: it explains that the tool navigates to the post first and that the comment is only posted when confirm_post is True, acting as a safety mechanism. It also discloses the return format, providing additional transparency.
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 well-structured: a clear one-sentence purpose is followed by a process note and an Args/Returns list. Each component adds necessary information, such as the confirm_post requirement and return structure. It is not overly verbose, though the process sentence and the ctx argument could be trimmed for more conciseness.
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?
The description covers the tool's purpose, the key behavioral requirement (confirm_post), all three schema parameters with explanations, and the return value structure. It does not mention error conditions or prerequisites like authentication, but these are not critical for a straightforward comment-posting tool. Given the annotations and sibling context, the description is sufficiently complete.
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?
The schema provides zero description coverage, leaving parameter meanings entirely to the description. The Args section explicitly explains each parameter: post_url with an Instagram URL example, comment as the text, and confirm_post as a mandatory True value to trigger posting. This fully compensates for the missing schema descriptions and goes beyond the parameter names.
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 opens with 'Post a comment on a post,' a specific action on a specific resource. This clearly distinguishes it from sibling tools like like_post or save_post, as commenting is a distinct action. The additional phrase 'Navigates to the post and submits the comment' reinforces the tool's purpose.
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?
The description implies use for posting comments on Instagram posts but does not explicitly compare with alternatives or state when not to use it. It provides a critical usage condition: 'confirm_post must be True for the comment to be posted,' which tells the agent the flag is required for the action to occur. However, no exclusionary guidance or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and openWorldHint=true. The description adds behavioral detail about extracting links from the location grid page, returning structured references, and the shape of the return dict. It does not contradict annotations, and the added context is valuable without being redundant.
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?
The description is well-structured with a headline summary, a usage guidance sentence, and clearly labeled Args and Returns sections. Every part contributes value, with no fluff.
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?
Given the tool's simplicity, the description covers purpose, usage, parameters, and return structure. The Returns section effectively serves as an output schema. Minor omissions like empty-location behavior exist, but overall it is adequate for reliable invocation.
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 coverage is 0%, so the description must compensate. It explains location_id and max_posts well. However, it lists 'ctx' as an argument that is not present in the input schema, which could confuse the agent into passing an invalid parameter.
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 clearly states 'Get posts tagged at a location' and describes extracting post links from the location grid page, providing a specific verb and resource. It also differentiates from get_post_details by directing users to that tool for individual post enrichment.
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?
It explicitly recommends using get_post_details for individual post enrichment, offering an alternative for a specific use case. However, it does not explicitly contrast with other sibling tools like get_hashtag_posts, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, establishing a safe read operation. The description adds useful context about return structure (dict with url and highlights list, each with title, cover_url, highlight_id) and mentions the ctx parameter for progress reporting, which is not in the schema.
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?
The description is concise and well-structured: a one-line purpose, clear Args section, and Returns section. Every sentence earns its place with no filler.
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 single-parameter tool with an output schema implied, the description is largely complete. It covers input, return format, and context. It does not mention potential errors or rate limits, but given the tool's simplicity and annotations, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the 'username' parameter with examples (e.g., 'instagram', 'natgeo') and introducing the 'ctx' parameter. This adds meaning beyond the bare schema type of string.
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 clearly states 'Get an Instagram user's story highlights' – a specific verb and resource. It distinguishes from sibling tools like get_user_stories by specifying 'highlights' rather than stories or posts.
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?
The description implies usage (fetching story highlights for a given username) but provides no explicit guidance on when to choose this over similar tools like get_user_stories or get_user_posts. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral details: it scrapes extra sections, returns raw text, sections may be absent if no content, and unknown sections are surfaced. It does not contradict annotations and offers extra nuance about the scraping behavior that the agent would not otherwise know.
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 well-structured with an Args/Returns format, but it includes a `ctx` parameter that is not present in the input schema, which adds slight confusion. Overall, it is appropriately sized, front-loaded with the core purpose, and every sentence contributes meaning.
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?
The tool has an output schema and the description still explains return structure (dict with url, sections, references) and failure modes (sections may be absent, unknown_sections). It lacks details on rate limits or pagination for large lists like followers/following, but given the read-only and open-world hints, the description is sufficiently complete for an agent to invoke it correctly.
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?
The input schema is bare (no descriptions), so the description's parameter explanations are essential. It clarifies `username` with examples, explains `sections` values and defaults, and documents the `ctx` parameter. This fully compensates for the 0% schema coverage and adds context that the schema cannot convey.
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 opens with 'Get an Instagram user's profile,' a specific verb+resource phrase that clearly distinguishes this tool from sibling tools like get_user_posts or get_user_reels. It also specifies the primary scope (main profile page) and optional sections, leaving no ambiguity about what is retrieved.
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?
The description provides clear instructions on how to use the `sections` parameter and includes examples, plus notes about defaults and unknown_sections. However, it does not explicitly state when to choose this tool over siblings like get_user_posts or get_user_reels. The usage context is implied by the tool's purpose but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, which the description does not contradict. The description adds context by explaining that the tool uses an external API (Gemini), provides speed and cost metrics, and returns structured JSON. It also mentions progress reporting via the ctx parameter. These details give a useful behavioral profile beyond 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?
The description is well-structured with a short intro, speed/cost details, an Args section, and a Returns section. It front-loads the core purpose and uses headings for readability. While slightly longer than necessary, every section adds value and there is no redundant fluff.
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 tool with an output schema and two input parameters, the description provides sufficient context: it explains the analysis types, the return format (JSON dict with structure depending on analysis_type), and operational details like speed and cost. It does not enumerate every possible return field, but the output schema can cover that. The only gap is the undocumented 'ctx' parameter, which could be an internal framework concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully define parameters. It does this well for reel_url (with an example) and analysis_type (with enum values and their meanings). However, it also lists a 'ctx' parameter that is not present in the input schema, which could confuse an agent. This minor inconsistency prevents a perfect score.
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 opens with a specific verb+resource: 'Analyze Instagram reel using Google Gemini 2.0 Flash.' This clearly differentiates the tool from sibling transcription tools by emphasizing the Gemini model, multimodal analysis, and the absence of local transcription. The available analysis types further clarify the tool's scope.
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?
The description provides comparative guidance by stating it is '3x faster than local Whisper' and 'extremely cheap' ($0.00017 per reel), implying it should be used when speed and cost are priorities. It also notes 'without local transcription,' directing users away from local alternatives. However, it does not explicitly name alternatives or state when not to use this tool, so a clear exclusion criterion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior, so the bar is lower. The description adds useful context by specifying the return structure (Dict with url, sections containing raw text, optional references) and mentioning the ctx parameter for progress reporting, which helps the agent understand the tool's behavior beyond annotations.
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?
The description is well-structured with an Args section and Returns section, using minimal sentences. Every piece of information (limit semantics and return format) is relevant and contributes to usability.
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?
Given the simple tool with one optional parameter and an output schema present, the description covers the essential return format and parameter behavior. It lacks details on what 'references' means or authentication requirements, but these are minor gaps given the simplicity and available annotations.
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 0% schema description coverage, the description fully compensates by clearly explaining the limit parameter (maximum conversations to load, range 1-50, default 20). This adds essential meaning beyond the raw schema type and constraints.
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 clearly states the tool lists recent DM conversations from the Instagram direct inbox, using a specific verb ('List') and resource ('DM conversations'). It distinguishes from sibling tools like get_dm_conversation and send_dm by focusing on listing recent conversations.
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?
The description implies usage for browsing recent DMs but does not explicitly mention when to use this tool instead of alternatives like get_dm_conversation or send_dm. No exclusions or alternative recommendations are provided, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true and openWorldHint=true, the description adds context by explicitly labeling the operation as a write operation and requiring confirm_send to actually send. It also describes the return dict. This goes beyond repeating annotations, though it could mention consequences of confirm_send=False.
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?
The description is well-structured with a clear purpose line, a warning about confirm_send, and a concise Args/Returns breakdown. Every sentence serves a purpose without wasted words.
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?
The description covers the core behavior, parameters, and return value, but does not address edge cases like what happens when confirm_send is False or potential errors. Given the output schema exists, this is acceptable, but there is room for more context.
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?
Schema coverage is 0%, but the description provides a detailed Args section explaining each parameter's meaning, including the required confirm_send flag and the internal ctx context. This fully compensates for the schema's lack of descriptions.
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 clearly states the tool's function with specific verb ('Send') and resource ('direct message to an Instagram user'), distinguishing it from sibling tools like get_direct_inbox and get_dm_conversation that read messages.
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?
The description implies usage for sending DMs but does not explicitly mention alternatives or when-not-to-use scenarios. It only notes that confirm_send must be True, which is a safety gate rather than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the bar for transparency is lower. The description adds valuable behavioral context: it downloads reels, runs Whisper via the caption command, and generates SRT files. It also explains the keep_videos flag's effect on cleanup. No contradiction with annotations; it enriches the safety and workflow picture.
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 well-structured with a purpose statement, a process summary, an Args section, and a Returns section. It's slightly longer than necessary and includes a ctx parameter not in the schema, which could cause confusion, but every sentence contributes useful information. Front-loaded and organized.
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 complex tool that downloads, processes, and returns multiple artifacts, the description covers the workflow, parameters, and return structure in detail. It lists all return fields and their types. Missing are potential prerequisites or error conditions, but given its thoroughness and the presence of an output schema, it's nearly complete.
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?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly by documenting username with an example, max_reels with a default and purpose, and keep_videos with its behavior. It even adds ctx (though not in schema) for progress reporting. This fully clarifies the meaning of every schema parameter.
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 opens with a specific verb-resource-output statement: 'Download and transcribe Instagram reels to SRT subtitles.' This clearly distinguishes it from siblings like get_user_reels (which only fetches reels) and transcribe_reel (which handles a single reel). The scope and deliverable are unambiguous.
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?
The description implies its usage context: it processes multiple reels (with max_reels) and produces subtitle files. It doesn't explicitly name alternatives or state when not to use it, but the clear purpose and parameter details provide enough context. No exclusions are mentioned, so it's clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds non-obvious behaviors: sequential processing to avoid rate limits and a performance comparison ('Faster than local transcription'). It also explains the return format, going beyond the structured annotations.
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?
The description is compact and well-structured: a clear goal line, two behavioral notes, and a simple Args/Returns breakdown. Every sentence adds useful context with no filler.
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 3-parameter bulk analysis tool with an output schema and annotations, the description covers purpose, performance trade-offs, rate-limit handling, parameter semantics, and return shape. It is complete for its complexity, relying on the output schema for return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args section must compensate. It provides examples for username, clarifies max_reels as a limit, and explains the default for analysis_type. However, it mentions a 'ctx' parameter not in the schema, which could confuse, and does not elaborate on enum meanings.
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 starts with a specific verb and resource: 'Analyze multiple reels from a user with Gemini.' This clearly distinguishes it from sibling tools like analyze_reel_with_gemini (single reel) and transcribe_user_reels (local transcription).
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?
It states 'Faster than local transcription for bulk analysis,' which implies when to use this over transcribe_user_reels. It also notes sequential processing to avoid rate limits, giving context on handling large batches but does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/open-world hints, but the description adds valuable behavior: navigates to profile, clicks Follow, and sends a follow request for private accounts. It also discloses the return format (Dict with url, status, optional message), going beyond structured annotations.
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?
The description is tight and well-structured: a one-sentence purpose, then a brief explanation of mechanics, followed by clean Args and Returns sections. No fluff, and the key information is front-loaded.
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 simple single-parameter tool with annotations and a clear return description, the description is complete. It covers what happens (including private-account behavior), the parameter, and the return value, satisfying what an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only schema parameter 'username' is fully explained with an example (e.g., 'natgeo'). Schema description coverage is 0%, so the description carries the burden and does so well. However, 'ctx' is mentioned as an argument but is not in the schema (additionalProperties false), which could confuse an agent expecting to pass it.
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 starts with a clear action: 'Follow a user or send a follow request for private accounts.' It specifies the resource (user) and the action (follow), and distinguishes it from siblings like unfollow_user and the various get_* profile tools.
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?
The context is clear: use this to follow a user, with special handling for private accounts (sends a request). It doesn't explicitly exclude alternatives or mention similar tools, but the action is unambiguous and the private-account distinction provides helpful conditional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool extracts post links from a grid page, returns structured references, and supports a max_posts limit, which adds value beyond the readOnlyHint and openWorldHint annotations. It does not discuss pagination behavior or failure modes, but the provided context is sufficient for an agent to anticipate the tool's behavior.
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?
The description is well-structured and appropriately sized: a one-sentence summary, a mechanism explanation, a cross-reference, and a concise Args/Returns section. Every sentence adds information, and the layout is easy to parse.
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?
Given the tool's moderate complexity, the description covers the return structure (url, sections, references, total_posts), the key parameters, and the expected output. The annotations and output schema handle safety and type details, so the description is complete within its role.
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?
Since the input schema has 0% description coverage, the description fully compensates by explaining each parameter: hashtag should be provided without the '#' symbol, and max_posts sets the load limit with a default of 50. It also mentions the ctx parameter for progress reporting, which is absent from the schema but useful for understanding execution.
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 clearly states the verb ('Get'), resource ('posts for a hashtag'), and mechanism ('extracts post links from the hashtag grid page'). It distinguishes from sibling tools like get_user_posts and get_location_posts, and cross-references get_post_details for enrichment, leaving no ambiguity about what this tool does.
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?
The description provides clear context: this tool lists post links from a hashtag grid. It explicitly names get_post_details as the follow-up for individual post enrichment, but does not explicitly state when not to use this tool (e.g., for user-specific posts). Sibling names make this obvious, but the lack of explicit exclusions prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, so the safety profile is covered. The description adds valuable behavioral context by explaining it fetches from the grid page and avoids N+1 rate limiting, plus details the return structure. However, it doesn't disclose potential limitations like pagination or errors, but the annotations and output schema mitigate some of that.
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 well-structured with clear 'Args' and 'Returns' sections, and every sentence provides useful information. It is slightly verbose, especially the 'ctx' line and the detailed return list, but overall it is efficient and scannable. The front-loaded purpose statement is strong.
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?
Given the tool's moderate complexity, the description is complete: it covers purpose, parameter semantics, return format, and usage guidance relative to siblings. The presence of an output schema further reduces the need to describe return values, and the description supplements this with a concise summary of the returned dict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It clearly explains username with examples and max_reels with its default value. However, it lists 'ctx' as an argument that is not present in the input schema, which could confuse an agent into thinking it's a user-supplied parameter. This is a minor inconsistency preventing a perfect score.
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 clearly states the tool's purpose with a specific verb and resource: 'Get an Instagram user's reels with structured data.' It also distinguishes itself from siblings by specifying it returns data from the grid page without navigating to individual reels, and mentions using get_post_details for full engagement data.
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 provides clear context for when to use this tool vs alternatives: it explicitly recommends using get_post_details for full engagement data on individual reel URLs. It also highlights the benefit of avoiding N+1 rate limiting by not navigating to each reel, implying it should be used for efficient bulk listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though readOnlyHint and openWorldHint are present, the description adds valuable behavioral context: it describes the return format (Dict with url, sections, references) and explicitly instructs the LLM to parse raw text to extract audience demographics. This goes beyond the annotations and sets expectations for post-processing.
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?
The description is concise and well-structured: a clear one-line purpose, a relevant availability note, and a compact Args/Returns section. Every sentence adds value, and the format is easy to scan for an AI agent.
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 tool with no input parameters and an output schema (though not shown), the description fully specifies what the agent should expect: the return structure and the need to parse raw text. It also covers an important prerequisite (account type availability), making it complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description lists 'ctx: FastMCP context for progress reporting' as an argument, but this is not reflected in the empty input schema and is likely framework-injected. It adds no confusion about real user parameters since there are none, so the baseline holds.
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 clearly states the tool's function: 'Get audience demographics from Professional Dashboard.' It uses a specific verb and resource, and the scope ('Professional Dashboard') distinguishes it from sibling insights tools like get_business_insights or get_activity_insights.
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?
The description provides clear context by noting that Professional Dashboard is only available for Business and Creator accounts, which helps decide when the tool applies. It does not explicitly mention alternatives or exclusion cases, but the availability note is strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable context beyond that: it discloses the account availability constraint and explains that the return value is a dict with raw text sections that the LLM must parse. This is critical behavioral information for the agent, covering what to do with the output. No contradiction with annotations.
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?
The description is efficiently structured with clear headings for Args and Returns. Every sentence adds value, including the account availability note. The length is appropriate for the tool's complexity.
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 simple read-only tool with one user-facing parameter and an output schema, the description covers the key aspects: what it does, account requirements, parameter options, and return format structure. The main gap is that it does not list specific metrics contained in the content performance data, but that is left to the output schema and the LLM's parsing instructions. This is adequate, though not exhaustive.
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?
The schema has no parameter descriptions (0% coverage), but the description compensates fully for time_range by listing allowed values ('7d, 30d, 90d') and default ('30d'). This gives the agent explicit options. The ctx parameter is mentioned in the description though not in the schema, which might be confusing, but it's clearly an internal context parameter. Overall, the description adds meaningful parameter semantics.
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 clearly states 'Get content performance insights from Professional Dashboard,' using a specific verb and resource. It distinguishes from siblings like get_business_insights and get_audience_insights by focusing on content performance specifically. The note about Business/Creator accounts adds contextual scope.
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?
The description provides a clear context for when the tool is applicable: 'Professional Dashboard is only available for Business and Creator accounts,' which implies an exclusion for other account types. However, it does not explicitly mention alternative tools for other insight types, so while the purpose is clear, the guidance is not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses behavioral traits such as returning structured data, including a 'legacy format' section, and using a FastMCP context for progress reporting. It also details the exact data shape (engagement, audio, sections), which adds significant context about what the tool does and returns, going beyond annotation-only information.
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?
The description is well-structured with clear headers for purpose, returned data, args, and return format. It is front-loaded with the primary purpose, and every line provides useful information without excessive prose. The bullet list and code block make it scannable and appropriately sized for a tool with this level of complexity.
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?
The description is complete for a read-only tool with this complexity. It explains the parameters, return structure, and even notes the legacy format. An output schema exists, but the description adds value by explaining the semantic meaning of fields like engagement and audio. There are no gaps that would leave an agent uncertain about how to invoke or interpret the tool.
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?
The input schema has zero descriptions for parameters, making the description's Args section essential. It explains post_url as 'Full Instagram post URL' and include_comments as 'Whether to include comments in the response'. It also documents the return structure in detail, fully compensating for the low schema coverage. The mention of ctx adds context about the FastMCP framework, providing additional meaning beyond 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?
The description clearly states 'Get detailed post/reel information with structured data', specifying the verb (get), resource (post/reel), and scope (by URL). It lists specific data fields returned, distinguishing it from sibling tools like get_user_profile or get_user_posts, which target different resources (user-level vs. specific post).
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?
The description implies usage by requiring a post_url and detailing the structured output, so the tool's purpose is clear. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The context is clear but lacks explicit when/when-not guidance, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![instagram-mcp-server MCP server](https://glama.ai/mcp/servers/ishan-parihar/instagram-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ishan-parihar/instagram-mcp-server)

Score Badge

Copy to your README.md:

[![instagram-mcp-server MCP server](https://glama.ai/mcp/servers/ishan-parihar/instagram-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ishan-parihar/instagram-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ishan-parihar/instagram-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server