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 only cover readOnly/openWorld; the description adds real value beyond them by enumerating the possible result states (ok, not_found, private, deactivated, memorialized, age_restricted, restricted_minor), the exact-match matching semantics, and a 1-credit cost. This is meaningful disclosure with no output schema to carry it, though auth/rate-limit behavior is 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?

Front-loaded with the action and tightly sized. The sentence 'Does this handle exist, and is it public?' restates the opening line almost verbatim and is the one piece of 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 and only one parameter, the description carries the key missing piece — the state enum — plus cost and matching rules, which is close to complete for a simple lookup. It could go slightly further by noting that private/not_found results are still billable or by naming the sibling to use for full profile data.

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 parameter already documents the handle format (with/without @, URL accepted). The description's only added meaning is the exact-match constraint, which is more of a result-semantics note than parameter detail, 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 ('Check if an Instagram handle exists and is public') and enumerates the outcome states, so an agent knows exactly what this returns. It does not explicitly differentiate itself from near-neighbors like instagram_profile, instagram_username, or instagram_user_id, which is the only gap.

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 (a cheap existence/publicity probe, reinforced by 'Cost: 1 credit') but never stated as when-to-use vs. instagram_profile or instagram_user_id. The 'Exact match only, so a typo never resolves to someone else' line is a useful caveat but not routing 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 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 cover the safety profile (readOnlyHint, openWorldHint), so the description's job is to add context — and it does: 'top comments' signals that results are a subset, the returned fields are enumerated, and the explicit 'Cost: 3 credits' is a genuinely useful operational disclosure. Pagination behavior is not stated, keeping it short of a 5.

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, all front-loaded with the core purpose first. No filler, though the return-field enumeration and cost line could be merged more tightly.

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 describes what comes back (fields plus total comment count), and it discloses cost. Missing only pagination/limit behavior for a comments endpoint, which likely returns capped results.

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 parameters (url, shortcode) are already documented in the schema, including the either/or relationship. The description adds no format or usage 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?

States a specific verb and resource: 'Get comments on an Instagram post,' and enumerates the returned fields (author, text, time, likes, reply count). It is clearly distinguishable from instagram_comment_replies in practice, but does not name that sibling explicitly to differentiate scope.

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 mention of when to prefer instagram_comment_replies for threaded replies, and no prerequisites. The only implied usage signal is the 'top comments' phrasing, which hints at a partial result.

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 establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds behavior the annotations do not: the public-account restriction, that a total follower count is returned, that pagination is cursor-based and only sometimes available, and an explicit 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?

Short and front-loaded: the operation and scope come first, followed by pagination and cost. The first two sentences overlap slightly ("followers" and "public follower list of a public account"), a minor redundancy rather than bloat.

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 does the necessary work of describing what comes back (follower list plus total count) and how paging works. Cost is disclosed. It omits any auth/access prerequisites beyond "public account," but is complete enough for an agent to call it 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 cursor, user_id and username in detail (including the either/or relationship and @-handling). The description adds only a vague note that paging uses a cursor "where available," so this lands at the baseline for a fully documented 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?

The description gives a specific verb and resource ("Get an account's followers") and adds a meaningful scope constraint: it returns the public follower list of a public account, with the total follower count. That is far clearer than a name restatement, but it never explicitly contrasts itself with the mirror-image sibling instagram_following, which is the main confusable alternative.

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 phrase "of a public account" signals this only works for public accounts, and "where available" hints pagination may not always exist. There is no explicit when-to-use guidance and no mention of when to choose instagram_following or instagram_profile instead.

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 safety (readOnlyHint, openWorldHint), and the description adds genuinely new behavior: the cost (3 credits), the public-account-only visibility limit, the inclusion of a total, and cursor-based pagination. It does not describe rate limits or error behavior, but the added context is solid.

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, front-loaded with the core purpose, then pagination and cost. The telegraphic style ('Page with cursor.', 'Cost: 3 credits.') is efficient, though slightly clipped.

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 mentions the total and cursor paging so the agent knows the return shape is paginated. Combined with the credit cost and public-only scope, it covers what an agent needs to call it 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 cursor, user_id, and username are already fully documented in the schema, including the 'pass this or username' mutual exclusivity. The description adds only the pagination intent behind cursor, 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 accounts an account follows' plus a clarifying restatement of direction ('who a public account follows'), which is enough to separate it from the adjacent instagram_followers tool even though that sibling is not named. Clear but no explicit sibling routing.

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: 'Who a public account follows' signals the public-account scope constraint, and 'Page with cursor' implies iterative calls. There is no explicit when-to-use or when-to-prefer-instagram_followers 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=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 already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond that: the return includes signed CDN URLs and the call costs 3 credits, which is actionable budgeting information an agent cannot infer from 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?

Two short sentences plus a cost line, front-loaded with the core action. Nothing is padded, though the redundant restatement of 'one highlight' in both sentences is slightly 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?

For a single-parameter read tool with no output schema, the description covers what is returned (photos/videos with CDN URLs) and the credit cost. It omits pagination behavior, item limits, and the id's origin, which are the main gaps an agent would still face.

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 0%; the only hint about the 'id' parameter comes from the schema's example value 'highlight:17960293069066406'. The description does not explain the identifier format, where to obtain it, or that it must be a highlight (not media) id, so it fails to compensate for the coverage gap.

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 clarifies the payload as 'Every photo and video inside one highlight'. It is clearly distinct from a listing endpoint, though it does not name the sibling instagram_highlights explicitly to contrast 'one highlight' vs 'all highlights'.

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 guidance. The sibling instagram_highlights (plural) almost certainly lists highlights and would be the prerequisite to obtain the id used here, but the description never says so or explains when to pick this tool over it. Usage is only implied by the word '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 cover read-only and open-world behavior, so the bar is lower; the description adds real value beyond them by disclosing the return fields and a concrete cost ('3 credits'). It stops short of noting rate limits or behavior on empty/private profiles.

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, lead sentence first, return shape second, follow-up third, cost last. Nothing is padded and no sentence is redundant.

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 names what each highlight contains and the cost, which is what an agent needs to plan a call. It is slightly thin on edge cases (users with no highlights, private accounts) but adequate for a two-optional-param 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% and both parameters are fully documented with examples, so the baseline is 3. The description's 'Pass an id' sentence refers to the other endpoint's highlight id, not to this tool's user_id/username, so it adds no new parameter meaning here.

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 then specifies the returned shape (title, cover image, item count). It also routes to the singular sibling instagram_highlight for per-highlight items, so an agent can distinguish the two without opening a 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 an explicit follow-up path: 'Pass an id to /v1/highlight for its items,' which tells the agent when to switch tools. It does not, however, contrast this with sibling listings like instagram_stories or state any precondition (e.g. private accounts).

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 meaningful behavior beyond them: the data window (latest 12 posts), the exclusion rule (pinned posts excluded), and the cost (2 credits). It stops short of auth requirements or rate-limit behavior, but the added constraints are genuinely useful.

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 tool's identity, then a compact enumeration of outputs, then the cost line. Every sentence carries information and nothing is redundant. Slightly dense in the output enumeration but well organized.

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 enumerating the return fields and the data window, which is enough for an agent to know what it will get. Annotations cover the read-only nature. Minor gaps remain around pagination or refresh behavior, but the definition is adequate for correct invocation.

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 both user_id and username fully documented in the schema, including that either can be passed. The description adds no parameter syntax or format detail beyond what the schema already provides, 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 resource and computed outputs: engagement rate (mean/median), posting cadence, format mix, best posting hours, and a benchmark percentile. This computed-metrics role is clearly distinct from siblings like instagram_posts or instagram_profile that return raw content. An agent can identify it without opening the 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 usage ('engagement rate calculator' over the latest 12 posts) but never states when to choose it over siblings or when it is inappropriate. There is no explicit routing to alternatives and no prerequisites. Usage is inferable but not guided.

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 the safety profile (readOnlyHint, openWorldHint), and the description adds valuable context beyond them: results are a sample rather than a complete liker list, a total like count is returned, and the call costs 3 credits. This sampling/partial-result caveat is exactly the kind of behavioral detail an agent needs.

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

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

Three short sentences, front-loaded with the core action, followed by return-shape and cost. Every sentence carries information; nothing is redundant.

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 steps in to say the return is a sample of accounts plus a total like count, and flags the credit cost. This is nearly complete for a simple read tool; only pagination/sample-size limits are 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?

Schema description coverage is 100% and both parameters (url, shortcode) are documented in the schema, including the either/or relationship. The description adds nothing about parameter format or defaults, 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 accounts that liked an Instagram post'), clearly matching the title. It is distinguishable from siblings like instagram_comments or instagram_post, though it does not explicitly name an alternative to disambiguate further.

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 never states when to use this tool versus siblings (e.g., instagram_comments for commenters, instagram_post for post data). No prerequisites or exclusions are given, leaving usage entirely to inference from the name.

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 establish readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavior beyond that: fixed page size (12), newest-first ordering, cursor-based paging, the specific fields returned, and a cost of 1 credit. These are non-obvious traits an agent should know before calling.

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, front-loaded sentences covering purpose, page shape, paging mechanics, and cost with zero filler. 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?

With no output schema, the description usefully enumerates return fields and page size, and annotations cover the safety profile. The one gap is that it never states the request must be scoped to a user (via user_id/username), which matters for a multi-sibling family.

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 cursor, user_id, and username are all documented in the schema itself. The description's mention of paging with cursor adds nothing beyond what the schema already says, 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?

Clear verb+resource: it retrieves a list of recent Instagram posts and specifies the shape of the result (likes, comments, views, caption, media URLs). However it never says whose posts (a specific user's timeline) nor distinguishes itself from close siblings like instagram_post, instagram_tagged, or instagram_media, leaving the agent to infer scope.

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 gives no when-to-use guidance and names no alternatives, despite an unusually dense sibling set (instagram_post, instagram_tagged, instagram_media, instagram_reels). It also never states that a user_id or username is needed to scope the request, which the schema implies but the prose omits.

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 the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new context beyond them: the 1-credit cost and the public-account restriction. It stops short of explaining failure behavior for private or 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?

Two short sentences: purpose and returned fields first, cost last. Zero filler, everything front-loaded.

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 listing returned fields, and the cost/access constraints round it out. Minor gaps remain around error or private-account behavior, but an agent has what it needs 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% — both user_id and username are fully documented, including the '@'-optional handle and URL acceptance. The description adds no parameter-level meaning, 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 exactly what comes back (counts, bio, links, category, verification, HD picture). It does not explicitly differentiate itself from nearby siblings like instagram_username, instagram_user_id, or instagram_check, 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?

Usage is only implied: 'any public account' hints at the public-only constraint, but no when-to-use or when-not-to-use guidance is given, and no alternative (e.g. instagram_username or instagram_check) is named for overlapping needs.

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-annotation context: it is a paid call costing 1 credit, and it discloses the shape of results (hashtags come with post counts, places with location ids). It says nothing about rate limits, pagination, or result caps.

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 what is searched followed by the three result types, with the cost placed last as a secondary note. No filler or repetition; every clause carries 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?

With no output schema, the description helpfully characterizes the returned result types (accounts, hashtags with post counts, places with location ids) and the cost. It is nearly complete for a one-parameter search tool, though it omits any mention of result limits or pagination behavior an agent might need.

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 schema documents q at 100% coverage ('Search text.'), so the baseline is 3. The description adds meaningful semantics beyond that: a single search box that simultaneously matches accounts, hashtags, and places, so the agent knows q is not scoped to one entity type. That is real added value over the terse schema description.

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 its three target resources (accounts, hashtags, places), which lets an agent distinguish this broad unified search from narrower siblings like instagram_hashtag or instagram_place. It does not, however, explicitly name those siblings as alternatives.

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 'One search box, three result types' — an agent can infer this is the entry-point search for all three entity kinds — but there is no explicit statement of when to prefer it over instagram_hashtag, instagram_place, or instagram_profile, and no exclusions given. The cost note hints at a usage consideration but does not provide routing 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 the safety profile is covered. The description usefully adds the credit cost, but says nothing about output shape, count, or rate limits beyond that.

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, purpose front-loaded, cost isolated at the end. Nothing is padded, though the second sentence slightly restates the first.

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 lookup with full schema coverage and no output schema, purpose and cost are sufficient for correct invocation. Only the shape of the returned account list is unstated, which is a minor 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?

Schema description coverage is 100% and both parameters (user_id, username) are fully documented there. The description adds no parameter-level meaning, 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?

Specific verb+resource ("Find similar Instagram accounts") plus a clarifying gloss ("Accounts Instagram considers related to this one") that distinguishes it from follower/following/profile siblings. It does not name an alternative sibling, but the concept is unambiguous.

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?

Offers use cases ("competitor research and influencer discovery") but no when-to-use vs alternatives, no prerequisites, and no exclusions. Usage is implied rather than directed.

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 still adds genuinely useful behavior beyond them: the 24-hour content window, the fact that media is returned as expiring signed CDN links, and a 3-credit cost. It stops short of noting anything about rate limits or failure modes on private 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?

Front-loads the purpose in the first clause, then layers content window, return type, link lifetime, and cost in short fragments. Every fragment carries information, though the staccato sentence fragments read slightly as bullet remnants rather than prose.

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 covers the return shape (image and video URLs) and their expiry. For a 2-param, zero-required tool it could note that at least one identifier must be supplied and what happens for private accounts, but the essentials are present.

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 there, including the 'pass this or user_id' alternative. 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 ('View Instagram stories') with scope qualifiers: public accounts, posts from the last 24 hours. This clearly separates it from most siblings, though it never distinguishes itself from the story-adjacent instagram_highlight/highlights tools, which is the one ambiguity an agent could hit.

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 eligibility conditions (public account, 24-hour window) imply when the tool applies, but there is no explicit when-to-use/when-not or pointer to an alternative such as instagram_highlights for older stories. Usage is inferable rather than 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 and openWorldHint, so the safety profile is covered. The description adds meaningful context beyond that ('public posts by other accounts,' credit cost), but says nothing about pagination behavior or what the returned payload contains. Compared to the calibration baseline for an annotation-covered read tool, this is a solid but modest addition.

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, front-loaded with the core action and data semantics, then use cases, then cost. No filler, though the second sentence slightly overlaps the first.

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, credit-costed read tool with 100% schema coverage, annotations, and no output schema, the description covers scope, purpose and cost adequately. Pagination is only implied by the cursor parameter, which is a minor omission.

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% – cursor, user_id and username are each documented in-schema, including the 'pass this or the other' relationship. The description adds no parameter-level meaning, 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 sharpens it with 'Public posts by other accounts that tag this account,' which separates it from the account's own post feeds. It does not name the sibling it contrasts with (e.g. instagram_posts/media), so differentiation is inferential rather than 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?

The use cases ('UGC, brand mentions and influencer tracking') imply when the tool is relevant, giving implied usage. There is no when-not guidance, no explicit alternative for retrieving an account's own posts, and no note that either user_id or username is required (that detail lives only in the schema).

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, and the description adds the non-obvious operational facts: it costs 1 credit and is usually unnecessary because other endpoints accept both identifier forms. It does not describe the return shape or error behavior on invalid handles, so it is not a 5.

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, value proposition and de-selection advice front-loaded, cost stated last as a trailing note. 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 result as a numeric id, and the cost plus redundancy warning cover the practical decision points. Only minor gap is behavior on an unresolvable handle.

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 schema already documents both parameters including the 'pass this or user_id' contract and the URL/@ tolerance. The description adds only the output-side clarification, 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 transformation (username -> numeric user id) and clarifies the output type ('The numeric user id for a handle'), which distinguishes it from the inverse sibling instagram_username. It does not explicitly name that sibling, so it stops just short of full 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?

Explicitly tells the agent when NOT to use it — 'Every endpoint also accepts either one directly, so you rarely need this' — which is exactly the routing guidance needed given how many siblings accept both forms. Nothing is left 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 already declare readOnlyHint and openWorldHint, so safety and external-dependency behavior are covered. The description adds a real behavioral fact the annotations don't carry: the fixed cost of 3 credits, which matters for deciding whether to invoke it.

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, front-loaded with the operation and followed by the rename nuance and the cost. No filler or repetition.

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 one-parameter, read-only resolver with no output schema, the description covers the operation, the durability of the result, and the credit cost. The only unwritten detail is the concrete return shape, which is minor here.

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 user_id parameter is fully documented in the schema, including an example. 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+resource: it resolves a numeric Instagram user id to its current username. The added note that the handle survives account renames pins down exactly what is returned, though it never names the reverse-direction sibling instagram_user_id to make the contrast 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?

Implied use: lookup a username when only a numeric id is known, and the rename-stability note hints at why this is preferred over cached names. There is no explicit when-not or named alternative, so guidance is only inferred.

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