Instagram Data

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

Annotations already establish readOnlyHint and openWorldHint, so the description need not restate safety. It adds material context beyond the annotations: the exact response contents and the credit cost ('Cost: 1 credit'), which is important for an agent budgeting calls. It doesn't cover rate limits or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler: purpose first, return contents second, cost last. Every sentence carries information the agent needs.

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

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

With no output schema, the description compensates by naming the returned fields and the related reels, and it discloses cost. For a single-parameter read tool with annotations covering safety, nothing essential is missing.

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

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

Schema coverage is 100% for the single id parameter, so the baseline is 3. The description goes beyond the schema's 'Numeric audio id' by explaining provenance ('Audio ids come from reels'), which meaningfully helps an agent construct a valid call.

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

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

The description gives a specific verb+resource ('Get an Instagram audio track') and enumerates the returned fields (title, artist, duration, preview URL) plus the associated reels. It does not explicitly name the sibling instagram_audio_search as an alternative, so it stops short of the top score.

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

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

It supplies one genuinely useful usage hint: 'Audio ids come from reels,' telling the agent how to obtain the required id. However, it never says when to prefer this over instagram_audio_search or instagram_reels, which is the natural selection question for this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds non-obvious operational context the annotations do not: the fixed cost of 3 credits and the fact that returned ids are meant to be passed to /v1/audio.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with zero filler: purpose, matching mode plus handoff, then cost. Every sentence carries information an agent needs.

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

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

For a single-parameter read tool with annotations covering safety, the description covers purpose, matching mode, downstream use, and cost. The only gap is that it doesn't sketch the shape of results (e.g., id/title/artist fields), and there is no output schema to fill that in.

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

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

Schema description coverage is 100% for the single 'q' parameter, so the baseline is 3. The description adds only marginal meaning by narrowing intent to title/artist matching, without syntax or format detail beyond the schema.

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

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

States a specific verb+resource ('Search Instagram music and sounds') and immediately narrows the query mode to title or artist. It also distinguishes itself from the sibling instagram_audio by describing this tool's output as ids to hand off to that endpoint.

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

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

Gives clear context for when to use it (finding songs/sounds by title or artist) and names the downstream consumer (/v1/audio) so the agent knows the workflow position. It stops short of explicit when-not-to-use guidance or naming alternative search tools such as instagram_search or instagram_reels_search.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful context beyond that: the full set of possible states (ok/not_found/private/deactivated/memorialized/age_restricted/restricted_minor) and the 1-credit cost. Missing auth/permission notes, but this is a strong disclosure layer over the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and result states, and the cost line is a useful trailing note. The second sentence ("Does this handle exist, and is it public?") is a near-verbatim restatement of the first and does not earn its place, costing it a point.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the possible states, plus cost. For a simple one-parameter read tool this is close to complete; it lacks only notes on auth requirements or rate limits.

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

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

Schema description coverage is 100% and the single username parameter is fully documented in the schema (handle with or without @, URL accepted). The description adds only the "exact match" constraint, so it sits at the baseline rather than adding real parameter detail.

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

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

States a specific verb and resource ("Check if an Instagram handle exists and is public") and the enumerated result states make the scope unambiguous versus data-fetching siblings like instagram_profile or instagram_media. It does not explicitly name the sibling tools it differs from (e.g. instagram_search, which does fuzzy matching), so it stops short of a 5.

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

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

"Exact match only, so a typo never resolves to someone else" implicitly tells the agent this is not the tool for discovery/lookup-by-partial-name, and the credit cost signals a lightweight validation call. However, no explicit when-to-use or when-not-to-use guidance is given relative to instagram_username or instagram_search.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds two pieces of behavior not in the annotations: results are cursor-paginated ('Page with cursor') and each call costs 3 credits. It does not describe return shape or reply ordering, so it is useful-but-partial given the low annotation bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and compact overall, with the cost note placed last. 'Replies under one comment' is mildly redundant with the opening sentence, costing a bit of tightness.

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

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

No output schema exists, so the description carries the return-value burden; it discloses pagination and credit cost, which is most of what an agent needs for a read-only call. It omits any indication of result ordering or volume, which keeps it from a 5.

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

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

Schema description coverage is 100%, with each of the four parameters documented in-schema, so the baseline is 3. The description only restates the cursor-based paging already implied by the cursor parameter and adds no new parameter meaning (e.g., how url/shortcode/comment_id interact).

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

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

States a specific verb and resource ('Get replies to an Instagram comment') and clarifies scope with 'Replies under one comment,' which lets an agent separate it from instagram_comments. It never names a sibling alternative explicitly, so it stops short of a 5.

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

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

Usage is only implied: the second sentence narrows the scope to replies belonging to a single comment, which hints at when to use it versus a post-level comments tool. There is no explicit when/when-not statement or named alternative.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuine behavioral detail beyond them: ordering (newest first), the returned fields, the pagination limitation ('no cursor'), and a cost of 3 credits. This is useful context that structured fields do not carry, though it omits auth/prerequisite notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, followed by return fields, pagination constraint, and cost. Three compact sentences with no filler; slightly terse but every sentence earns its place.

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

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

For a read-only, 2-param tool with a fully documented schema and no output schema, the description covers ordering, page semantics, return content, and cost. The only meaningful gap is not clarifying the boundary with instagram_comment_replies, but overall it is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents url and shortcode (including the 'pass this or shortcode' mutual option). The description adds no syntax or format meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get comments on an Instagram post') and enumerates the returned fields. It does not, however, name or distinguish itself from the sibling instagram_comment_replies, so an agent must infer that replies are fetched elsewhere. Clear but lacks sibling differentiation.

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

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

The description implies usage by noting it returns 'one page of the most recent comments' and that there is 'no cursor: one page per call,' which tells the agent pagination is not available. However, it never states when to prefer this tool over instagram_comment_replies or instagram_post, nor any exclusions.

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

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

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the pagination contract, the 422 private_account error, and a credit cost. That is useful behavior beyond the annotations, though it doesn't cover rate limits or partial-failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the purpose, then pagination, then failure mode, then cost. Every sentence carries distinct information and nothing repeats the schema.

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

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

With no output schema, the description still describes the return shape (a page of accounts plus total follower count, next_cursor for continuation) and the one error path, so an agent has everything needed to call and iterate correctly.

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

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

Schema coverage is 100%, so the baseline is 3, and the description raises it by explaining the cursor round-trip ('Pass next_cursor back as cursor') and confirming the public-account constraint that governs the user_id/username pair.

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

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

States a specific verb+resource: retrieving one page of the accounts that follow a public account, plus the total follower count. An agent can distinguish it from instagram_following by the 'follow' direction, though no sibling is named explicitly.

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

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

Explains pagination mechanics ('Pass next_cursor back as cursor... null means no more pages') and the private-account failure mode, which is genuine usage guidance. It never states when to choose this over instagram_following, instagram_likers, or other account-listing siblings.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds valuable context: pagination behavior (next_cursor, null means no more pages), an error case (private accounts return 422), and cost (3 credits). This goes beyond the annotations, though it doesn't cover all potential behaviors like rate limits beyond cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tight and front-loaded: purpose first, then pagination details, error case, and cost. Every sentence is informative and earns its place.

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

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

With no output schema, the description explains the return shape ('one page of the accounts... with the total') and key behaviors like pagination and errors. It is complete enough for correct invocation, though minor details like exact response structure or rate limits beyond cost are omitted.

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

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

Schema description coverage is 100%, so the schema fully documents the three parameters. The description reinforces cursor usage and mentions the null pagination signal, but adds little semantic detail beyond what the schema already provides. Baseline 3 is appropriate.

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

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 accounts an account follows.' It distinguishes from the sibling 'instagram_followers' by making the direction explicit (accounts the target follows, not followers). No ambiguity about what the tool returns.

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

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

Usage is implied by the purpose, but there is no explicit guidance on when to use this versus the sibling 'instagram_followers' or other profile-related tools. No when-not conditions are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful context beyond annotations: the cost (1 credit) and that results are paged via cursor. However it does not disclose page size or rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero waste: purpose, return content, pagination, and cost are all front-loaded and unambiguous.

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

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

With no output schema, the description usefully indicates what comes back (recent posts and total post count) and that it pages via cursor. It omits page size limits and any indication of ordering, but is otherwise sufficient for a simple read tool.

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

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

Schema description coverage is 100%, so the schema already documents 'tag' (with/without #) and 'cursor' (next_cursor from previous page). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get posts for an Instagram hashtag') and clarifies the return content (recent posts plus total post count). It is distinguishable from siblings like instagram_place_posts or instagram_search by resource, though it does not explicitly name which sibling to use instead.

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

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

There is no explicit when-to-use guidance or comparison against the many adjacent siblings (instagram_search, instagram_tagged, instagram_place_posts). 'Page with cursor' implies pagination but the description never states conditions, prerequisites, or exclusions.

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

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

Annotations only cover the readOnly/openWorld safety profile, so the description usefully adds that responses carry signed CDN URLs and, notably, the credit-cost model with per-account caching semantics. It stops short of describing pagination or item limits, but the billing behavior is genuinely value-adding beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in the first sentence, with a short elaboration on payload, then the cost note. Slight redundancy between the opening sentence and the 'Every photo and video' clause, but nothing is wasted overall.

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

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

With no output schema, the description compensates by stating the return payload (photos/videos with signed CDN URLs) and the cost model. For a single-parameter read tool this is nearly complete, missing only pagination or volume expectations.

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

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

Schema description coverage is 100% and the id parameter is fully documented there, including the optional 'highlight:' prefix and source endpoint. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the items in one highlight') and elaborates that the contents are photos and videos. It implies a distinction from the plural sibling instagram_highlights but never names or explicitly contrasts with it, leaving the boundary to inference.

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

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

No explicit when-to-use, when-not, or named alternative is given; the agent must infer this is the drill-down after instagram_highlights. The billing note ('first time for an account; more free for 15 minutes') is practical context but describes cost, not selection guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond them: the exact return shape (title, cover image, item count), the fact that items require a follow-up call, and a concrete cost of 3 credits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero filler: purpose, return shape, and cost/routing all front-loaded. Every sentence earns its place and nothing is repeated from structured fields.

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

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

With no output schema, the description correctly compensates by naming the returned fields and explaining that item-level data lives behind another endpoint. Cost is disclosed as well; only pagination or rate-limit behavior is left unstated, a minor gap for a single-argument read tool.

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

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

There is one parameter and schema coverage is 100%, so the schema fully documents username including @ handling and URL acceptance. The description adds nothing about this parameter (the 'pass an id' line concerns a different endpoint), which is the expected baseline when the schema carries the load.

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

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

States a specific verb and resource ('Get Instagram story highlights') and enumerates what is returned (title, cover image, item count), so the agent knows exactly what this call produces. It also explicitly separates itself from the singular sibling instagram_highlight by noting that an id must be passed to /v1/highlight for the items.

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

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

Provides explicit routing: use this tool for the highlight list, then pass an id to /v1/highlight for items — a clear alternative path that disambiguates the plural/singular sibling pair. It stops short of contrasting against instagram_stories or stating any preconditions, which keeps it out of the 5 range.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the analysis window (latest 12 posts), the pinned-post exclusion rule, and a 2-credit cost. It does not cover caching, rate limits, or failure modes, but with annotations present this is above the bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the identity and outputs, followed by the scope/exclusion caveats and cost. No filler or restated name/title.

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

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

There is no output schema, so the description carries the burden of describing returns, and it does so concretely (engagement mean/median, cadence, format mix, best hours, percentile). For a one-parameter read tool it is nearly complete; only error/empty-account behavior is unaddressed.

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

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

With a single parameter and 100% schema description coverage, the schema fully documents the username input including '@' handling and URL acceptance. The description adds no parameter detail beyond that, so baseline 3 applies.

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

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

The description names a specific analytic resource (Instagram engagement rate) and enumerates exactly what is computed: mean/median engagement, posting cadence, format mix, best posting hours, and a benchmark percentile. It is clearly distinguishable from generic siblings like instagram_profile or instagram_posts in substance, though it never names an alternative to route against.

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

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

Usage is implied (reach for this when you want engagement/cadence analytics) and the 'latest 12 posts' scope is stated, but there is no explicit when-to-use vs when-to-use-something-else guidance relative to siblings such as instagram_profile or instagram_posts. The cost note hints at a selection tradeoff but does not spell one out.

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

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

Annotations only cover read-only and open-world safety, but the description adds substantial behavioral detail beyond them: results are a sample, the total like count is included, there is exactly one page with no cursor, and the call costs 3 credits. This is exactly the kind of context an agent needs to set expectations and manage budget.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences plus a one-line cost note, with the core purpose front-loaded and the sampling limitation immediately after. Every sentence earns its place with no redundancy.

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

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

With no output schema, the description carries the return-value burden and does so by describing both the sample of likers and the total like count. Combined with the annotation-covered safety profile and fully documented params, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so url and shortcode are already documented with an example and an explicit 'pass this or shortcode' relationship. The description adds nothing about parameter formats, so the baseline 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('accounts that liked an Instagram post') with the exact scope of the result. This clearly distinguishes it from siblings like instagram_followers, instagram_comments, and instagram_likers' nearest neighbors without needing to open any schema.

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

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

The description implies when-not-to-use by warning it returns only a sample and one page per call, which is useful context for an agent deciding whether it needs a full list. However, it never names an alternative tool or the condition that would route the agent elsewhere, so usage guidance is only implied.

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

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

Annotations only cover safety (readOnly, openWorld), and the description adds substantial behavioral context beyond them: URLs are signed Instagram CDN links that expire after a few hours, quality is best-available, and the call costs 1 credit. These are exactly the traits an agent cannot infer from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: what you get, what the URLs are, and the cost. Front-loaded with the payload description and no wasted wording; the cost line is discrete and useful for a credit-metered tool.

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

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

With no output schema, the description correctly explains the return value (per-slide direct file URLs in best quality) and warns about expiry. Parameters are optional and fully covered by the schema. Minor gaps remain, such as whether one call handles all slide types uniformly, but nothing essential to invoking it is missing.

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

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

Schema description coverage is 100%, and both parameters are documented with an example URL and an explanation of the shortcode. The description adds nothing beyond that, so the baseline of 3 applies since the schema does the heavy lifting.

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

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

States a specific verb and resource: returns download URLs for a post, reel or carousel, and clarifies the payload is direct image/video file URLs for every slide. An agent can tell this is a media-fetch tool rather than a metadata tool. It does not explicitly distinguish itself from the many siblings (e.g. instagram_post, instagram_reels), so it stops short of a 5.

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

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

Usage is implied rather than stated: you call this when you need downloadable files instead of metadata. There is no explicit when-to-use/when-not guidance, no mention of when to prefer this over instagram_post or instagram_reels, and no note on the url-vs-shortcode choice in the description itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds two useful facts beyond that: the credit cost (3 credits) and the concrete set of fields returned, which is meaningful because there is no output schema. It does not cover rate limits or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded lines: purpose and returns first, id sourcing second, cost last. No filler, no redundancy with the schema.

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

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

For a read-only, single-parameter lookup with no output schema, the description compensates by listing the returned fields, and annotations cover the read-only nature. Remaining gaps (pagination, error cases, cost implications in bulk) are minor given the tool's simplicity.

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

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

Schema coverage is 100% with a single, well-described id parameter, so the baseline would be 3. The description adds value by pointing to /v1/search as the source of valid ids, which helps the agent understand what value belongs in the field rather than just its type.

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

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

States a specific verb and resource ('Get an Instagram location') and enumerates the returned fields (name, category, address, city, phone, website, post count), which makes the tool's scope concrete. It does not explicitly contrast itself with the closest sibling, instagram_place_posts, so it falls short of a 5.

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

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

Gives actionable context for obtaining the required argument: 'Find ids with /v1/search.' This tells the agent how to get a valid input rather than leaving it to guess. No explicit when-not-to-use or sibling routing against instagram_place_posts, so not a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the concrete 'Cost: 1 credit' fact, which is genuinely useful, but 'Page with cursor' largely restates the schema's own cursor parameter description ('next_cursor from the previous page'). Net new behavioral context is limited to the credit cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded with the action first, and the cost note is cleanly appended. The second sentence ('Recent posts geotagged at a location') is a near-redundant restatement of the first, which is the only minor waste.

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

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

For a low-complexity, 2-parameter read tool with no output schema, the description covers purpose, pagination, and cost adequately. It says nothing about the shape or ordering of returned posts, which is a modest gap given there is no output schema to fall back on.

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

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

Schema description coverage is 100%: 'id' is documented as a numeric location id with an example and 'cursor' as the next_cursor from the previous page. The description adds no syntax or format detail beyond this, so the baseline 3 for schema-carried semantics applies.

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

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 posts tagged at an Instagram location') and names the scoping concept (geotagged at a location), which separates it from generic post tools like instagram_posts or instagram_media. It does not explicitly contrast with nearby siblings such as instagram_place or instagram_hashtag, so it stops short of a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. An agent must infer from the resource noun that this differs from instagram_place (place details) or instagram_tagged, which is left implicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value beyond that with the credit cost and an explicit enumeration of returned fields (likes, comments, views, caption, owner, media URLs) — important since no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and resource, then the payload and cost. Slight redundancy between the title 'Get one Instagram post or reel' and the opening sentence, but nothing wasteful.

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

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

With no output schema, listing the returned fields is exactly the compensation needed, and the cost note is useful. The main gap is the absence of any routing guidance relative to the many instagram_* siblings, but for a simple read tool this is close to complete.

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

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

Schema description coverage is 100%, and the schema itself explains that url and shortcode are alternatives ('Pass this or shortcode'). The description adds nothing about parameter form or the either/or relationship, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (one Instagram post or reel), and the singular scope is implied against the plural instagram_posts sibling. It does not explicitly name that sibling or contrast with instagram_media, so the differentiation is only implicit.

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

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

There is no when-to-use or when-not-to-use guidance. An agent must infer that this is for a single post versus instagram_posts, instagram_media, or instagram_reels, and the description never states that inference or any preconditions.

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

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

Annotations already cover the read-only and open-world safety profile, and the description adds real behavioral context beyond that: fixed page size of 12, returned fields, pinned-first then newest ordering, private-account edge case (empty list + is_private: true), cursor pagination, and a stated cost of 1 credit. Only error/failure behavior is left unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely dense and front-loaded: purpose first, then pagination/page contents, ordering, edge case, paging mechanism, and cost. 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.

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

With no output schema, the description must describe returns and largely does: fields per post, ordering semantics, and the private-account response shape. It is complete enough to call and interpret results, though it does not cover rate-limit or error outcomes.

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

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

Schema coverage is 100% with self-documenting cursor/user_id/username fields and an example for username, so the schema carries the load. The description only adds that cursor drives pagination, which is baseline-level value over the schema.

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

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

States a specific verb ('Get') and resource ('recent Instagram posts'), and the '12 per page' and ordering details make it recognizable as the profile-feed listing tool. However it never explicitly contrasts itself with close siblings like instagram_post, instagram_media, or instagram_tagged, so the agent must infer the boundary.

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

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

Usage is implied rather than stated: 'Page with cursor' signals a paginated fetch, and the private-account note implies a pre-check. There is no explicit when-to-use or when-to-prefer-a-sibling guidance (e.g. instagram_post for a single post, instagram_reels for video-only).

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

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

Annotations cover readOnly and openWorld, and the description adds the 'public account' access constraint plus a credit cost, which is genuinely useful behavioral context. However it omits failure behavior for private/suspended accounts and doesn't mention rate limits beyond the flat cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: purpose first, payload second, cost last. No filler, no repetition of the title, and front-loaded with the key information.

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

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

For a read-only profile lookup with no output schema and full schema coverage, the description gives enough: what it returns, the account-type constraint, and the cost. Only the omission of private-account failure semantics and sibling routing keeps it from a 5.

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

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

Schema coverage is 100% and the schema already explains that user_id and username are alternatives ('Pass this or user_id') and that handles/URLs work. The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Get an Instagram profile') and enumerates the exact data returned (follower/following/post counts, bio, links, category, verification, profile picture), which distinguishes it from siblings like instagram_username or instagram_user_id (resolution) and instagram_followers (list).

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

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

The description implies usage by scoping to 'any public account' and clarifying the return payload, but it never explicitly says when to use this versus instagram_username/instagram_user_id (ID resolution) or instagram_insights (metrics). With 27 siblings, an explicit alternative would have been valuable.

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

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

With readOnlyHint and openWorldHint already given, the description adds real value: the public-account restriction, the fields returned, cursor-based pagination behaviour, and a 1-credit cost. The cost and pagination notes go beyond the annotations and are actionable, though access/permission failure modes are unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: purpose first, then returned data, then pagination and cost. No filler, and the most decision-relevant information leads.

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

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

There is no output schema, so the description correctly enumerates the returned fields, and it covers paging and cost. It is nearly complete for a read tool; only the public-account failure behaviour and any rate limiting are left implicit.

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

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

Schema coverage is 100% and each parameter is documented in-schema, including the cursor's origin and the user_id/username alternative. The description restates pagination via cursor but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource (get an account's reels) and scopes it to the reels tab of a public account, which implicitly separates it from the sibling instagram_reels_search. It also enumerates what the reels contain, but never names an alternative sibling outright.

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

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

Usage is implied: pass a user_id or username, page with cursor, works only for public accounts. There is no explicit when-to-use guidance or comparison to instagram_reels_search, so the agent must infer the choice.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds two genuinely non-obvious behaviors: the 3-credit cost per call and cursor-based pagination, which an agent must know to budget and to retrieve more than the first page.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical purpose and cost are front-loaded, but the fragment 'Reels matching a keyword' restates the first sentence verbatim in content and earns nothing. The telegraphic fragments read as truncated rather than tight.

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

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

No output schema, but annotations cover the safety profile and the schema fully documents both parameters. With cost and pagination disclosed, the description is adequate for a two-parameter search tool; result shape and page-size limits remain unstated.

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

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

Schema description coverage is 100% (q = 'Search text.', cursor = 'next_cursor from the previous page'), so the schema already carries the parameter meaning. 'Page with cursor' adds a paging cue but no format or syntax beyond the schema — baseline 3.

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

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

States a specific verb and resource: 'Search Instagram reels by keyword.' Clear enough to distinguish from the user-scoped instagram_reels and the general instagram_search, though it never names those siblings or states the distinction explicitly.

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

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

No when-to-use guidance and no exclusions relative to instagram_reels, instagram_search, or instagram_audio_search. The only procedural hint is 'Page with cursor,' which addresses iteration, not tool selection.

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

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

Annotations already cover the read-only, open-world nature, but the description adds two real behavioral traits: the shape of results (hashtags carry post counts, places carry location ids) and an explicit cost of 1 credit, which is quota information not available in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded with purpose, with cost isolated at the end. The second sentence partially restates the first, which is minor redundancy but not harmful.

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

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

With no output schema, the description usefully sketches the return shape (accounts, hashtags with counts, places with ids), which is the key missing structured information. Pagination or result-count limits are not addressed, leaving a small gap.

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

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

There is a single parameter with 100% schema coverage, including a description, maxLength, and example, so the schema already carries the meaning. The description adds nothing about the query syntax or matching behavior, making 3 the baseline.

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

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

The description states a specific verb (search) and the exact resource types returned (accounts, hashtags, places), which distinguishes it from instagram_audio_search and instagram_reels_search. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the resource list.

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

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

Usage is only implied: the three result categories hint that this is the discovery entry point before using instagram_username, instagram_hashtag, or instagram_place for details. There is no explicit when-to-use statement or named alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a useful cost disclosure ('Cost: 1 credit'), which is real context beyond the annotations, but nothing about rate limits, latency, or result shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences plus a cost line, fully front-loaded with the core purpose first. No padding or redundancy.

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

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

For a simple read-only lookup with annotations covering safety, 100% schema coverage, and no output schema, the description supplies everything needed to call it: purpose, relatedness semantics, and cost. Only minor gaps remain, such as expected result volume.

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

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

Schema description coverage is 100%, so both user_id and username are fully documented in the schema, including the 'pass this or user_id' mutual-exclusion hint. The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Find similar Instagram accounts') and adds a clarifying gloss: accounts Instagram considers related to this one. An agent can tell it apart from instagram_search or instagram_top_accounts, though siblings aren't named explicitly.

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

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

No when-to-use or when-not-to-use guidance. It never says whether this requires an existing account context or how it differs from other discovery tools like instagram_search or instagram_top_accounts, leaving selection to inference.

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

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

Annotations only cover readOnly and openWorld; the description goes beyond them by disclosing the 24-hour recency window, the returned media types, expiring signed CDN links, and a 3-credit cost. That is meaningful operational context an agent needs before calling, though it omits failure behavior for private/nonexistent accounts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short fragments, front-loaded with purpose, then output characteristics and cost. Every clause carries information; no filler.

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

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

With no output schema, the description usefully characterizes the return payload (image/video URLs, expiring CDN links) and notes the cost. It is close to complete for a single-param read tool, lacking only error/edge-case behavior.

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

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

Schema coverage is 100% and the schema itself documents the username format (with/without @, profile URL accepted). The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb and resource ('View Instagram stories') plus a distinguishing scope ('last 24 hours by a public account'). No sibling tool covers stories, so an agent can route here unambiguously.

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

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

Usage is implied by the resource itself, but there is no explicit when-to-use guidance or routing against alternatives such as instagram_media or instagram_highlight. The 'public account' qualifier hints at a precondition without stating it as one.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds two pieces of non-annotation context: results are limited to public posts by other accounts, and each call costs 1 credit — a real behavioral constraint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short lines, zero filler, purpose front-loaded and the cost constraint isolated for easy scanning.

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

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

No output schema, so the description should carry the return-shape burden, which it partially does by defining what a 'tagged' post is. Pagination is handled by the schema's cursor field, but auth requirements are never mentioned.

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

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

Schema coverage is 100%, so user_id/username/cursor are fully documented in the schema. The description adds nothing about parameter semantics (e.g., that user_id and username are interchangeable alternatives), so the baseline 3 applies.

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

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

States a specific verb and resource ('Get posts an account is tagged in') and clarifies the semantics as 'Public posts by other accounts that tag this account.' This implicitly distinguishes it from instagram_posts (the account's own posts), but it never names a sibling explicitly.

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

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

No when-to-use guidance, no conditions, and no alternatives named. An agent must infer from the name alone that this is the right tool versus instagram_posts, instagram_media, or instagram_comment_replies.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely non-obvious behavior: data is refreshed daily, it is free (0 credits) but requires any API key, and use is bound by CC BY 4.0 with mandatory credit and source link — an obligation an agent would otherwise not know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and its data provenance, and the attribution constraint is stated early. The trailing 'Cost: 0 credits.' duplicates the earlier 'Free (0 credits)', which is mild waste but not enough to undercut an otherwise efficient description.

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

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

With no output schema, the description carries the return burden and does so: ranked accounts, 1/7/30-day follower changes, country, category and projected milestones are all named. Combined with cost, auth and licensing notes, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% and every parameter (sort, limit, offset, window, country, category) is already documented in the schema with enums and examples. The description only loosely echoes the available dimensions ('1, 7 and 30-day follower changes, country, category and projected milestones'), adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource: 'biggest notable public Instagram accounts ranked by followers,' with daily updates, follower-change windows, country, category and milestones. This is a leaderboard/chart tool, clearly distinguishable from the per-user siblings (instagram_followers, instagram_profile) without opening any schema.

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

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

Gives clear operating context: free at 0 credits, requires any API key, and mirrors a public chart page. It does not, however, name an alternative or state when not to use it (e.g. vs instagram_search or instagram_profile for a specific account), so the agent must infer selection from the leaderboard framing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful cost context ('Free (0 credits)'), but does not describe return format, rate limits, authentication needs, or what 'usage' includes. With annotations present, this is adequate but shallow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded, with no wasted words. However, the first sentence merely restates the title, and the second is a cost note. It is concise but minimally informative.

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

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

The tool is simple and annotations cover read-only behavior, but there is no output schema and the description does not explain what the usage result contains. For a tool named 'usage', an agent can infer some meaning, but the description stops short of describing return values or scope.

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

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

The input schema has zero parameters, so there are no parameter semantics for the description to clarify. Per the baseline for parameterless tools, this score is appropriate. The description need not document any arguments.

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

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

The description gives a vague sense of purpose: retrieving the user's monthly usage. It does not state a specific verb or distinguish itself from the many sibling Instagram tools, and it largely repeats the title. An agent can infer the general area but not the exact resource returned.

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

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 instagram_check or instagram_insights. It mentions cost ('Free (0 credits)') but does not explain context, prerequisites, or exclusions. The description offers no usage decision support.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a billing/rate signal ('Cost: 1 credit') and states the returned value is a numeric id, which the rubric treats as credit-worthy context beyond structured fields. It does not cover failure behavior when a handle cannot be resolved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and short, with the cost note sensibly placed last. Slight waste in the opening sentence, which restates the tool title verbatim before adding the 'numeric user id' clarification.

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

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

With no output schema, the description correctly states what is returned (a numeric user id), and the parameter contract is fully covered by the schema plus annotations. Remaining gaps are minor: unresolved-handle behavior and any differentiation from the instagram_username sibling are absent.

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

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

Schema description coverage is 100% and the schema already explains that user_id and username are alternatives ('Pass this or user_id'), including an example handle. The description adds no format or syntax detail for either parameter, so the baseline 3 applies. A minor unexplained oddity remains: why a user_id input is accepted by a tool whose job is to produce one.

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

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

States a specific transformation (username → numeric user id) and clarifies the output: 'The numeric user id for a handle.' An agent can tell it is a resolver, not a data-fetching endpoint like instagram_posts or instagram_profile. It does not, however, distinguish itself from the similarly named sibling instagram_username, which an agent might reasonably confuse it with.

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

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

Provides real routing context: 'Most account endpoints also take user_id directly; check, insights, stories and highlights take username only.' This tells the agent when a user id is needed versus when a handle suffices. It stops short of an explicit 'use this tool when...' statement and never names an alternative tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context beyond that: a concrete cost (2 credits) and a freshness guarantee that the returned handle survives account renames.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences plus a cost line, with the useful freshness detail front-loaded. Slightly wasteful in that the opening sentence nearly restates the title, but overall tight.

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

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

For a single-param, read-only lookup whose return value (a username) is self-evident, the description is sufficient: purpose, what it returns, freshness behavior, and cost. No output schema is needed for such an obvious return.

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

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

Schema coverage is 100% and the single user_id param is fully documented with an example. The description only restates 'numeric user id,' adding nothing beyond the schema, so baseline 3 applies.

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

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

The description states a specific verb+resource: converting a numeric Instagram user id to its current handle. It is crisply defined and implicitly distinct from the reverse sibling instagram_user_id, though it never names that sibling to make the direction explicit.

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

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

Usage is only implied: 'the current handle for a numeric user id, which still works after the account renames itself' hints you should prefer this when a cached handle may be stale. There is no explicit when-to-use/when-not framing and no routing toward or away from instagram_user_id.

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