instagram-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., separate publish tools for image, video, reel, carousel, story; separate comment management tools). However, 'account_info' and 'get_profile' both return profile data with overlapping descriptions, causing potential confusion.
Naming Consistency4/5
The majority follow a consistent verb_noun pattern (list_, add_, get_, publish_, etc.). Minor deviations include 'account_info' (noun_verb), 'business_discovery' (noun_noun), and 'publishing_limit' (gerund_noun), but these are not overly disruptive.
Tool Count4/5
29 tools is on the higher end for a single domain, but each tool covers a distinct part of the Instagram Graph API (accounts, publishing, insights, comments, DMs, hashtags, mentions). The scope justifies the count, though it could be slightly trimmed.
Completeness4/5
The tool set covers most major Instagram API operations: account management, publishing (multiple formats), insights, comments, hashtags, mentions, and DMs. Missing update/delete for media and limited user search, but core workflows are well-covered.
Average 3.6/5 across 29 of 29 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on June 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It only notes a requirement but does not state that this is a read-only operation, returns a list, or any pagination details. The output schema likely provides structure, but behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence + requirement note), but it lacks front-loading of key information and fails to structure essential details like parameter roles or usage context.
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 two parameters, the description only covers the tool's purpose and a prerequisite. It does not explain the 'account' parameter's role (e.g., filtering by account ID) or the returned data structure, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter ('limit' or 'account'). The agent gains no insight into what these parameters control beyond the raw 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 verb 'List' and the resource 'Instagram DM conversations', which is distinct from sibling tools like 'get_messages' that handle individual messages.
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?
Only a prerequisite (Meta App Review) is mentioned. There is no guidance on when to use this tool vs alternatives like 'get_messages' or 'send_message', nor any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It fails to disclose whether the operation is read-only (implied but not stated), any rate limits, pagination behavior, or the definition of 'recent'. The term 'tags edge' is vague and not explained.
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 a single sentence that front-loads the core purpose. However, it is too concise to the point of omitting useful context. Score 4 for efficiency but not 5 due to lack of completeness.
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?
Given the existence of an output schema, the description need not explain return values, but it lacks context about the scope of 'recent', pagination, and how this tool relates to many siblings. The description is minimal and does not fully equip an agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the parameters. While 'limit' and 'account' are somewhat self-explanatory, the description should add value by specifying defaults, constraints, or behavior (e.g., 'account defaults to current account'). It adds nothing 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 uses a specific verb 'List' and clearly identifies the resource as 'recent media where the account is @-mentioned'. It also mentions 'tags edge', which hints at a unique endpoint, distinguishing it from sibling tools like 'list_media' or 'get_hashtag_media'.
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 does not provide any explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context like 'use this to find mentions, not for general media listing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the basic action and a permission constraint but lacks details on pagination, error handling, rate limits, or what happens with invalid conversation IDs. With no annotations, more behavioral disclosure is needed.
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?
Two concise sentences with no wasted words. Could be slightly improved by grouping information more logically, but it's effectively brief.
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 (so no need to describe return values), the description omits parameter guidance and behavioral context for a 3-parameter tool. Incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about parameters like limit, account, or conversation_id. The agent must rely solely on the schema, which lacks 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 "Read messages in a DM conversation," specifying the verb and resource. This distinguishes it from sibling tools like send_message (write) and list_conversations (list conversations, not messages).
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?
Only provides a prerequisite (requires Meta App Review), no guidance on when to use this tool versus alternatives like list_conversations or search tools. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states 'Live profile snapshot' implying real-time data but does not disclose authentication needs, rate limits, or side effects. It lacks any behavioral context beyond the basic function.
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 sentence that front-loads the key purpose and data fields. Every word earns its place; no unnecessary content.
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?
Given the output schema exists, return values are covered. However, the parameter semantics are missing, and there is no usage guidance or transparency. For a simple read tool with one parameter, the description is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'account' with no description (0% coverage). The tool description does not explain how to specify the account (e.g., by ID or username) or the meaning of null/default. This is insufficient for an agent to correctly populate the 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 it retrieves a live profile snapshot for one account, listing specific fields like username, name, followers, media count. It is a specific verb-resource combination and distinguishes from siblings like list_accounts and get_profile by specifying 'live' and the data fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, limitations, or exclusions. The description only states what it does, not when to choose it over sibling tools like get_profile or business_discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects such as whether the default overwrites previous, persists across sessions, or affects other tools. This is insufficient for a state-changing operation.
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, focused sentence with no extraneous information. Every word contributes to understanding the tool's core function.
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?
Given the presence of an output schema, the description does not need to explain return values, but it fails to mention how the tool handles invalid labels or confirmation of success. For a mutation tool, this is incomplete.
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?
With 0% schema description coverage, the description must explain the 'label' parameter. It only says 'account' but not what format or where to find valid labels, leaving the agent without necessary context.
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 sets a default account for omitted `account` arguments. It is specific with verb 'set' and resource 'default account', but does not differentiate from sibling tools like 'account_info' or 'list_accounts'.
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 when avoiding repeated `account` arguments, but provides no explicit guidance on when not to use it or alternatives, leaving the agent to infer context.
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?
Discloses that available metrics vary by Graph API version and that mismatches cause informative errors. However, with no annotations, it does not state whether the operation is read-only, destructive, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences providing key information without redundancy. The first sentence is a clear summary, followed by parameter details and a helpful behavioral note. Could be slightly more structured but is efficient.
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?
Covers the tool's purpose, parameter options, and a behavioral caveat. However, omits the 'account' parameter entirely and does not differentiate from similar analytics tools, leaving gaps in completeness.
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?
Adds meaning to 'metrics' and 'period' parameters beyond the schema, including defaults and allowed values. The 'account' parameter is not described, and the schema has no descriptions (0% coverage), so the description partially compensates but misses one parameter.
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?
Clearly states it provides account-level analytics (reach, impressions, profile views, follower count). Differentiates from per-media tools like get_media_insights by specifying 'account-level', though not explicitly contrasting with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings such as get_media_insights or get_audience_insights. Only implicit through the 'account-level' phrasing.
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?
With no annotations provided, the description carries the full burden. It discloses the destructive action of removing the account and deleting its token from the keychain, which is valuable transparency. However, it does not describe error conditions, reversibility, or what happens if the account is currently in use.
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 conveys the core action and a key side effect with no irrelevant information. Every word is purposeful.
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?
Given the tool has only one parameter and an output schema, the description covers the main action and side effect but lacks explanation of the parameter 'label'. The presence of an output schema reduces the need to describe return values, but the parameter gap makes this merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'label' with no description, and the schema description coverage is 0%. The tool description does not explain what the 'label' parameter represents (e.g., the account identifier), leaving the agent to infer its meaning.
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 'Remove' and clearly identifies the resource as 'configured account', with additional detail about deleting the stored token. It distinguishes the tool from siblings like add_account, account_info, and set_default_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to use account_info instead) or when not to use it. The description does not mention preconditions or context for safe usage.
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?
With no annotations, the description carries the burden. It discloses the edge options and a rate limit, adding value beyond the schema. However, it does not explicitly state whether the operation is read-only, or describe error/response 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 three sentences, front-loaded with the core action. Every sentence adds substantive information without redundancy or fluff.
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?
Given the parameters, output schema, and siblings, the description covers core functionality, prerequisites, and a rate limit. However, it lacks explanation of the account parameter and does not fully distinguish from similar media retrieval tools, leaving gaps for an agent.
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?
Schema description coverage is 0%. The description only partially documents parameters: it explains edge values and implies a limit range (1-100), but does not describe hashtag_id or the account parameter. This is insufficient for a 4-parameter tool with no schema descriptions.
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 'Get recent or top media for a hashtag id' and specifies the edge parameter values. It identifies the resource and action, but doesn't explicitly differentiate from sibling tools like list_media or get_media.
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 context on obtaining the hashtag_id from search_hashtag and mentions the 30-unique-hashtags per 7 days rate limit. However, it does not explicitly state when to use this tool over alternatives or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'PUBLIC https' but does not explain side effects, authentication needs, rate limits, or what happens upon publish. The constraint on parameters is included but not deep 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 a single sentence with no wasted words, front-loading the main action. It is concise, though slightly cryptic with 'PUBLIC https'. Still, it earns its place.
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 the existence of an output schema, the description omits important context such as the purpose of the account parameter, the meaning of 'PUBLIC https', prerequisites, and return value details. For a tool with 3 parameters and no schema descriptions, this is insufficient.
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?
With 0% schema description coverage, the description must compensate. It adds the constraint 'Exactly one of image_url / video_url' which clarifies mutual exclusivity, but does not explain the account parameter, default behavior, or format requirements. This provides minimal added 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 the tool publishes a Story, distinguishing it from sibling tools like publish_image, publish_video, publish_reel, and publish_carousel. It specifies the content type (image or video) and the constraint of exactly one media parameter.
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 when to use this tool (for stories, not other post types) but does not explicitly state when not to use it or name alternatives. The 'PUBLIC https' phrase is ambiguous and does not clarify usage context.
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?
Discloses toggle behavior (hide=false unhides) but lacks details on permissions, side effects, or return format.
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?
Very concise two sentences, front-loaded with purpose, no wasted words.
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?
Inadequate for a mutation tool with 3 parameters and no param descriptions; missing account context and output details.
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?
Does not explain the account parameter or provide meaningful context for comment_id or hide beyond the basic toggle.
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?
Clearly states the action (hide/unhide) and resource (comment), and distinguishes from sibling tools like delete_comment.
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?
No explicit guidance on when to use vs alternatives; does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only lists output fields but omits critical details like pagination, ordering, whether hidden comments are returned, authentication requirements, and rate limits.
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 a single, efficient sentence. However, it could benefit from additional structure or details without losing conciseness.
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?
Given the presence of an output schema and 3 parameters with no descriptions, the description only partially covers what agents need. It lacks parameter explanations and behavioral context, making it adequate but incomplete.
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?
Schema coverage is 0%, yet the description does not explain the purpose of 'limit' or 'account' parameters. Only 'media_id' is obvious from context. The description adds minimal value beyond 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 clearly states the verb 'List' and resource 'comments on a media object', and enumerates returned fields. It distinguishes from sibling tools like reply_to_comment or delete_comment.
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 purpose is clear enough to deduce when to use this tool (to retrieve comments), but it lacks explicit guidance on when not to use it or alternatives for specific filtering.
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?
No annotations are provided, so the description must cover behavioral traits. It discloses return fields but does not mention authentication needs, rate limits, error handling, or whether the operation is read-only. Basic transparency but significant gaps.
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 a single 18-word sentence that is front-loaded with the main action. It is concise but the list of fields could be more structured; still, no unnecessary words.
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?
Output schema exists, reducing need to explain return values. However, missing usage guidelines, parameter semantics for 'account', and behavioral details. Adequate but incomplete given sibling tools and no annotations.
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?
Schema description coverage is 0%, so the description must explain parameters. It mentions media_id but does not explain the optional 'account' parameter at all, leaving ambiguity for the agent.
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 returns full fields for one media object by id, listing specific fields (caption, type, permalink, like/comment counts). It unambiguously distinguishes from siblings like list_media which returns multiple objects.
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 fetching a single media object by id but provides no explicit guidance on when not to use it or mention of alternatives like list_media, get_media_insights, or other sibling tools.
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?
No annotations provided, so description carries full burden. It correctly identifies the operation as read-only and lists returned fields. However, it does not disclose behavior when the optional 'account' parameter is null (likely returns own profile) or any failure cases. Adequate but lacks nuance.
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?
Single sentence, front-loaded with action and resource, no redundant text. Every word earns its place.
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 is simple and has an output schema. The description covers the purpose and returned fields. However, the lack of parameter guidance (especially the default behavior) is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'account' parameter at all. With one optional parameter and no explanation of its purpose or default behavior, the description fails to add value 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?
Description clearly states 'Return the account's public profile fields' and lists specific fields (followers, follows, media count, bio, website). Verb 'Return' and resource 'public profile fields' are precise, and the tool is distinct from siblings like account_info or list_accounts.
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?
Description does not explicitly state when to use this tool versus alternatives (e.g., account_info). Usage context is implied: use when you need public profile fields. No exclusions or conditions are provided.
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?
No annotations are provided, so the description carries the burden. It explains the rolling 24h window and daily cap, making it clear this is a read-only quota query. However, it does not mention that it is non-destructive or specify the output format (but output schema exists).
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 with no unnecessary words. It front-loads the key information ('Remaining posts') and is immediately understandable.
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 output schema exists and the tool is simple with one optional parameter, the description covers the core purpose well. It lacks parameter guidance but is otherwise complete for an informational tool. Could mention default behavior when account is null.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the optional 'account' parameter at all. With 0% schema description coverage, the description should explain how the parameter affects the tool's behavior, but it fails to do so.
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 returns remaining posts in the rolling 24h publishing quota, referencing Instagram's daily cap. This distinguishes it from sibling tools that perform actual publishing or account management.
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 before publishing to check quota, but does not explicitly state when to use it or provide alternatives. No exclusion criteria or context on 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?
With no annotations provided, the description carries the full burden. It discloses that the tool never returns tokens (a security trait), but does not mention authentication requirements, side effects, or rate limits. The behavioral disclosure is partial but non-harmful.
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 focused sentence with no fluff. It front-loads the purpose and includes a critical behavioral note. Every word earns its place.
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 is simple with no parameters and an output schema likely covering the return format. The description identifies the return fields and a key security trait. It is complete enough for a basic list operation, though it could mention that it reflects the current configuration state.
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 does not need to add parameter-level meaning. Baseline for zero parameters is 4, and the description does not address parameters unnecessarily.
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 "list", identifies the resource "configured Instagram accounts", and specifies the returned fields (labels, ig_user_id, default flag). It also adds a distinguishing behavioral note about not returning tokens, clearly differentiating it from sibling tools like add_account or account_info.
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 alternative tools like account_info or healthcheck. It does not suggest prerequisites or when not to use it, relying solely on the tool name and sibling context for usage clues.
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?
No annotations provided. Description covers char limit and return id, but lacks details on authorization, whether it edits existing replies, rate limits, or side effects. Adequate but could be richer.
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?
Two concise sentences conveying essential information. No redundancy, front-loaded with verb and resource.
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 operation and presence of output schema (even if not shown), description provides key info: char limit and return id. Could mention that comment must be on user's own media. Overall adequate for a straightforward 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?
Schema coverage is 0%, so description must compensate. It adds char constraint for message and notes return value, but does not explain account parameter or what comment_id must refer to. Partial compensation.
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?
Description clearly states 'Reply to a comment' with verb and resource. It also adds constraints (message <= 2200 chars) and return value (new comment id). Distinguishes from sibling tools like hide_comment or delete_comment.
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?
No explicit instructions on when to use this tool vs alternatives like send_message. Does not mention prerequisites (e.g., need to own the media or have permissions). Usage is implied but not clarified.
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?
Without annotations, the description carries the burden of behavioral disclosure. It reveals it is a mutation (sends a message), requires app review, and has a time window constraint. However, it does not disclose error behavior, rate limits, or success confirmation.
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 highly concise with two sentences and one line, front-loading the core purpose. Every sentence adds value without redundancy, making it efficient for an AI agent to parse.
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?
The description covers key contextual aspects (what the tool does, prerequisites, limitation), but omits parameter details for text and account, and does not mention return values despite an output schema existing (though not shown). The complexity of the tool warrants more complete guidance.
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?
Schema description coverage is 0%, so the description must explain all parameters. It only explains recipient_id (as IGSID) and fails to describe text and account parameters. This leaves two of three parameters undocumented, insufficient for effective tool invocation.
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 'Send a DM', which is a specific verb-resource pair. Among sibling tools, only this one sends direct messages, ensuring no confusion with reply_to_comment or other communication 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 description provides important prerequisites (Meta App Review, 24-hour window) and a key limitation (paid message tag not handled). However, it does not explicitly mention when to use this tool over alternatives or provide guidance on handling paid messages.
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?
No annotations are provided, so the description carries the full burden. It explicitly states the action is permanent and irreversible, which are critical behavioral traits for a deletion tool. It does not cover authorization specifics or rate limits, but the core behavior is disclosed.
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 a single focused sentence that begins with the key action. It is concise and front-loaded, but could be improved by including brief parameter guidance without adding much length.
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 deletion tool, the description covers the main behavioral trait (irreversibility) and ownership. However, it lacks information about error conditions, output (though an output schema exists), and does not explain parameters, leaving some gaps in completeness.
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?
Schema coverage is 0%, and the description does not mention or explain the parameters (comment_id and optional account). While parameter names are somewhat self-explanatory, the description fails to add value beyond the schema, such as clarifying the purpose of the optional account 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 the tool's purpose: 'Permanently delete a comment you own (or a comment on your media). Irreversible.' It specifies the verb (delete), resource (comment), and ownership conditions. This distinguishes it from sibling tools like hide_comment or get_comments.
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 context on when to use the tool (comments you own or on your media) and implies irreversibility. However, it does not explicitly mention when not to use it or alternative approaches like hiding instead of deleting.
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 no annotations, the description carries full transparency burden. It discloses the follower floor requirement, how errors are surfaced, and that parameters like metric, breakdown, and timeframe can be overridden. It does not mention rate limits or side effects, but the read-only nature is implicit.
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 front-loaded with the core purpose and is three sentences long. The second sentence is dense with API specifics, but every sentence adds value. It is efficient for the complexity of the tool.
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 output schema exists, the description does not need to detail return values. It covers main purpose, prerequisite, and parameter behavior. It lacks mention of authentication or permissions, but these are implied by the account parameter context. Overall, sufficient for a tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains several parameters (metric, metric_type, breakdown, timeframe) and their possible values. However, it omits explanation for 'period' and 'account', and the details are somewhat buried in API version notes. Moderate value added 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 the tool retrieves follower demographics by age, gender, country, and city. It uses a specific verb ('get') and resource ('audience insights'), and distinguishes itself from sibling tools like get_account_insights by focusing on demographics.
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 a key prerequisite (>=100 followers) and mentions error handling, but does not explicitly guide when to use this tool over alternatives like get_account_insights or business_discovery. Usage context is implied but not fully stated.
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?
With no annotations provided, the description carries full burden for behavior disclosure. It states the core action but lacks details on side effects, authentication needs, or rate limits. For a simple lookup, this is adequate but not comprehensive.
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?
Single sentence of 13 words, front-loaded with purpose and usage. No 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 simple task and presence of output schema, the description is largely complete. It explains the workflow dependency, though the 'account' parameter remains unexplained.
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?
Schema coverage is 0%, so description must compensate. It does not explain the 'account' parameter (optional, default null) beyond the schema, leaving ambiguity about its role.
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 'resolve', the resource 'hashtag name', and the output 'Graph id', and explicitly links to a sibling tool 'get_hashtag_media', distinguishing its role.
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 tells when to use the tool ('needed before get_hashtag_media'), providing clear context, though it does not explicitly mention alternatives or 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?
No annotations are provided, so the description carries the full burden. It states the tool is read-only and only works for Professional accounts, which are key behavioral facts. It also describes the effect of the with_media and media_limit parameters. However, it omits details like error handling (e.g., if username is not found or account is not professional), rate limits, or authentication needs, leaving some gaps.
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 three sentences long, each serving a distinct purpose: main functionality, read-only/account type context, and parameter behavior. It is front-loaded with the primary action and wastes no 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?
For a tool with 4 parameters, no schema descriptions, and no annotations, the description provides good coverage of core behavior, usage context, and key parameter semantics. The presence of an output schema reduces the need to explain return values. However, it does not address edge cases or the purpose of the 'account' parameter, which could confuse an AI agent.
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 has 0% description coverage, so the description must compensate. It explains username (by mentioning 'by username'), with_media (pulls up recent posts), and media_limit (pulls up to that many posts). However, the 'account' parameter (optional, default null) is not explained, leaving its purpose unclear. Overall, partial coverage with some missing info.
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 it retrieves public profile and optionally recent media for any business/creator account by username, and explicitly distinguishes it from personal accounts. It also mentions 'read-only competitor/prospect research,' which defines its purpose and differentiates it from sibling tools like get_profile (personal accounts) and list_media (which may lack business focus).
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 specifies when to use the tool ('competitor/prospect research') and the constraint that it only works for Professional accounts, not personal. This provides clear context and implies it should not be used for personal accounts. However, it does not explicitly mention alternatives among siblings (e.g., get_profile for personal profiles), which slightly reduces clarity.
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?
No annotations provided, so the description covers behavior differences between post types but lacks disclosure on read-only nature, rate limits, or side effects.
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?
Two concise sentences that are front-loaded and contain no extraneous information.
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?
Reasonably complete given the tool's complexity; explains the key parameter behavior and output context, though missing details on account and media_id format.
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?
With 0% schema coverage, the description explains the metrics parameter well (comma-separated, defaults, type-dependent) but does not address account or media_id 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 clearly states 'Per-post analytics' with specific metrics listed, distinguishing it from sibling tools like get_account_insights and get_audience_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?
It explicitly explains that metrics defaults suit feed posts and that for reels/stories, different metrics must be passed explicitly, providing clear 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?
Discloses ordering (newest first), limit range (1-100), and default (25). No annotations provided, so description carries burden. Does not explain behavior when account is null or pagination, but provides key constraints.
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?
Two efficient sentences front-loaded with purpose and ordering, then parameter detail. No 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?
Covers core behavior and limit constraints. Output schema exists for return format. Lacks explanation of account parameter and usage context vs siblings, but adequate for a simple listing 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?
Adds meaning for 'limit' with range and default, compensating for 0% schema coverage. However, 'account' parameter is not explained; description says 'for the account' but doesn't clarify if it's optional or what null means.
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?
Clearly states the verb 'list', resource 'media (posts/reels)', scope 'for the account', and ordering 'newest first'. Distinguishes from siblings like get_media (specific item) or publish 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?
Implies usage for retrieving recent account media, but no explicit guidance on when to use vs alternatives like get_media or search_hashtag. No exclusions or when-not-to-use 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?
No annotations provided, so description carries the burden. It explains the creation process: child containers, then parent, then publishing. Adds constraints on URL format. Could mention rate limits or permissions.
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?
Three concise sentences: purpose, constraint, process. No redundancy, every sentence adds value.
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?
Covers main process and constraints. Output schema exists, so return values are not needed. For 3 parameters and a multi-step action, sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description adds meaning for image_urls (must be public https), but lacks detail for account and caption. Partially compensates for schema gap.
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?
Clearly states it publishes a multi-image carousel with 2-10 images, distinguishing it from siblings like publish_image, publish_video, etc. Includes specific verb (publish) and resource (carousel).
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?
Specifies that image_urls must be public https URLs, but does not explicitly provide when-to-use or when-not-to-use compared to other publish tools. Implicitly understood 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?
Discloses async processing and timeout behavior. No annotations exist, so description carries full burden, which it meets adequately.
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?
Two concise sentences, no filler, front-loaded with core action.
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?
Explains async behavior and URL constraint, but missing descriptions for account and caption. Output schema exists, so return values are covered.
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?
Only video_url is described (must be public HTTPS). Account and caption parameters have no description in schema or description, leaving agents uninformed.
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 action ('Publish a video to the feed') and distinguishes from siblings like publish_image and publish_reel.
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?
Provides key conditions: URL must be public HTTPS, and async processing with polling up to 90s. Lacks explicit when-to-use vs siblings but context is clear.
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?
No annotations provided, so description carries full burden. Discloses that image_url must be publicly accessible HTTPS URL, caption max 2200 chars, and that the two-step Graph flow is handled internally. Misses potential side effects like error handling or rate limits, but covers key behavioral traits.
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?
Three sentences, no wasted words. Front-loaded purpose, then constraints, then implementation detail. Efficient and to the point.
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?
Despite having an output schema (not shown), description does not mention return values. However, for a mutation tool with 3 parameters, it covers essential constraints and distinguishes from 20+ sibling tools. Missing explanation of the optional account parameter.
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 description must compensate. Explains image_url requirements (public HTTPS) and caption length limit. However, the 'account' parameter is left unexplained, which reduces completeness.
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 publishes a single image to the feed, differentiating it from siblings like publish_video, publish_carousel, etc. The verb 'publish' and resource 'single image' are specific.
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?
Provides key constraints (public URL, caption limit) and notes internal two-step flow, but lacks explicit guidance on when to use this tool versus other publishing tools (e.g., publish_carousel or publish_story). Usage context is implied but not explicitly 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?
With no annotations provided, the description adds important behavioral context: asynchronous processing with polling up to 90 seconds, and the effect of share_to_feed. However, it does not cover permissions or rate limits.
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 three sentences with no redundant information. It starts with a clear main action followed by critical constraints and optional details, all front-loaded.
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 async nature, key parameter constraints, and optionality. It assumes the output schema explains return values. Missing explanations for 'account' and 'caption' parameters prevent full completeness.
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 schema has 0% description coverage, so the description must compensate. It explains video_url, share_to_feed, and cover_url but does not cover 'account' or 'caption'. This covers 3 of 5 parameters, providing partial but incomplete 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 explicitly states 'Publish a Reel', using a specific verb-resource combination. It further distinguishes from sibling tools like publish_image, publish_video, and publish_story by focusing on Reels and noting key constraints.
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 includes a prerequisite (video_url must be a public https URL) and explains the behavior of share_to_feed. While it does not explicitly name alternatives or when-not-to-use, the purpose clarity sufficiently differentiates it from siblings.
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 no annotations, the description carries the full burden. It discloses that tokens are stored in the macOS keychain or a secure file and are never echoed back or logged, which is important security behavior. It does not mention error handling or idempotency.
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 parameter details in a list format and a security note at the end. It is front-loaded with the core purpose. Slightly verbose but each sentence adds value.
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 presence of an output schema, the description does not need to explain return values. It covers behavior, parameters, and security adequately for a configuration tool. Some details about default behavior or errors are missing.
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 explains each parameter: label, access_token, ig_user_id, app_secret, and make_default, including their types and optionality. This adds significant meaning beyond the raw 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 stores an Instagram Business/Creator account for use by every tool, which is a specific verb-resource combination. It distinguishes from siblings like list_accounts, remove_account, and set_default_account by focusing on creation/registration.
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 that this tool is a prerequisite for other tools, but does not explicitly state when not to use it or suggest alternatives. However, the context of sibling tools makes its purpose clear.
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?
No annotations provided, so description carries full burden. Describes live GET, checks performed, and return value (ok=false with hint). Could be slightly more detailed on what 'token backend' and 'Graph reachability' entail, but overall adequate.
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?
Two concise sentences in first paragraph, a clarifying second sentence in second paragraph. Front-loaded with purpose. Every sentence adds value. No unnecessary words.
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 no parameters, the description covers purpose, behavior, safety, and return format. Output schema exists (context indicates) but description mentions 'ok=false' hint, which covers expectations. Complete for this simple 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?
No parameters in schema, so baseline 4. Description adds context about what the tool does (checks) beyond the empty schema, which is appropriate. No need for parameter details.
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?
Description clearly states the tool verifies MCP configuration (accounts, token backend, Graph reachability). Specific verb 'verify' and resource 'MCP health'. Distinguishes from siblings which are for account management, posting, etc.
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?
Explicitly states it's safe to call anytime and never mutates. Provides clear context for when to use. Does not explicitly mention alternatives or when not to use, but given the sibling tools, it's implicitly clear.
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 MCP server](https://glama.ai/mcp/servers/adelaidasofia/instagram-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adelaidasofia/instagram-mcp)

Score Badge

Copy to your README.md:

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

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/adelaidasofia/instagram-mcp'

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