SocialAPIs

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful detail that creative, spend, and impressions are returned, but says nothing about auth requirements, rate limits, or data freshness 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?

One efficient, front-loaded sentence with no wasted words. It could be slightly more helpful without sacrificing brevity, but it is well structured.

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?

An output schema exists, so return values need not be explained, and annotations cover the read-only profile. However, for a tool centered on a required ad_archive_id, the description gives no hint about how to obtain that ID or how the optional filter parameters affect results, leaving a clear 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% with 5 documented parameters, so the schema carries the burden. The description adds no parameter-level meaning beyond what the schema already states, which is the baseline expectation at full coverage.

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 detailed info') and resource ('a specific archived ad') plus the returned content areas (creative, spend, impressions). This clearly differentiates it from sibling search tools like facebook_ads_search, though it does not explicitly name an 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?

No guidance on when to use this versus facebook_ads_search or facebook_ads_page_details. It implies 'look up one specific ad' by saying 'a specific archived ad', but never states prerequisites or the alternative path for finding an ad_archive_id in the first place.

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, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds only that these codes serve Meta Ads Library filtering; it discloses nothing extra about caching, stability, or format of the returned codes.

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?

A single front-loaded sentence with no filler or repetition of the title. It is tight, though it is arguably too terse to add much beyond the name.

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?

An output schema exists, so return values need no explanation, and the zero-parameter schema is trivially complete. For a simple reference lookup, the description is sufficient, though a note on how the codes are consumed by ad-search tools would round it out.

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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No parameter meaning is missing.

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 ('Get list of supported country codes') scoped to Meta Ads Library filtering, which clearly separates it from search/archive siblings like facebook_ads_search. It does not name a sibling explicitly, but the lookup nature of the tool 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?

The purpose sentence implies usage ('for Meta Ads Library filtering'), so an agent can infer this is a reference-data call that feeds other ad queries. However, there is no explicit statement of when to call it versus facebook_ads_search or what to do with the returned codes.

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, openWorldHint=true and destructiveHint=false, covering the safety profile, and an output schema exists. The description adds only the country-filter behavior, with no mention of pagination, rate limits, or result scope, so it adds modest value beyond 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?

A single compact sentence with the key action and option front-loaded and zero filler. It is efficient, though the extreme brevity leaves useful routing detail on the table.

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 output schema offloads return-value explanation, and annotations cover safety, but for a tool sitting among several ads-related siblings the description is too thin to disambiguate when this tool should be chosen over facebook_ads_search.

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 are already documented in the schema, and the description's 'optional country filter' merely restates that. No extra syntax, format, or defaulting semantics are added, 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: search ads by keyword, with a country scope. However, it does nothing to distinguish itself from the sibling facebook_ads_search (or facebook_ads_archive_details), so an agent cannot tell from the description alone which of the ads tools to pick.

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 exclusions, and no mention of the sibling facebook_ads_search, which appears to overlap in function. Usage is only implied by the word '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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond 'detailed info' – no note on what fields are returned, rate limits, or that data comes from a public ad archive rather than the live 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?

One short, front-loaded sentence with no waste. It is efficient, though it leaves room for a differentiating clause at negligible length cost.

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 an output schema and full annotation coverage, this is largely complete. The only real gap is disambiguation from the very similarly named facebook_get_page_details sibling.

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?

Single parameter with 100% schema description coverage, so the schema already documents page_id fully. The description adds no format, source, or acquisition detail beyond what the schema provides, making the baseline 3 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 and resource ('Get detailed info about a specific Facebook page') and adds the scoping source ('from the Ads Library'), which meaningfully distinguishes it from the near-identical sibling facebook_get_page_details. It does not name that sibling explicitly, so an agent must infer the distinction.

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 indication of when to choose this over alternatives like facebook_get_page_details or facebook_get_page_id, nor any prerequisites. The Ads Library scope is implicit context, not stated usage 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the Meta Ad Library as the source, but says nothing about pagination via end_cursor, result limits, or rate behavior, so it stays at the annotated baseline.

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?

A single front-loaded sentence with no filler; the scope and primary filters are stated immediately with zero 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?

An output schema exists, so return values need not be described, and the schema fully documents all 8 optional parameters. The only gaps are the absence of guidance on pagination looping and on choosing between query and ad_page_id when both are optional.

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 all 8 parameters, so the schema does the documentation work. The description restates keyword, page ID, country, status, and date but omits sort_data and end_cursor, adding no syntax or default information 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?

Names a specific verb (Search), resource (ads), and the data source (Meta Ad Library), plus the two alternative lookup keys. It does not differentiate itself from nearby siblings such as facebook_ads_keywords or facebook_ads_archive_details, but an agent can still tell what this 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, even though facebook_ads_keywords and facebook_ads_archive_details sit right next to it. Usage is only implied by the listed filter fields.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the media types; it says nothing about authentication needs, rate limits, or where/how the retrieved media is delivered. On the lower bar set by the annotations, this still adds very little behavioral context.

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

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

A single tight sentence with the action and scope front-loaded and no wasted words. It is efficient, though it could have used a few of those saved words on usage or delivery behavior.

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 an output schema present, return values need not be explained, and a one-parameter download tool is inherently simple. Still, nothing is said about authentication, URL validity, or supported URL forms, leaving modest gaps for an openWorld fetch 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 a single required 'url' parameter with full schema description coverage, so the schema already documents the input. The description's phrase 'from Facebook URLs' merely echoes that, adding no format or validation detail beyond the schema; 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?

The description gives a specific verb (Download) plus the resource and subtypes (images, videos, audio) from Facebook URLs. This clearly separates it from the surrounding get_/search_ siblings, which are all read-only lookups rather than downloaders, though it does not explicitly name an 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?

It states what the tool does but offers no when-to-use guidance, no prerequisites (e.g. auth or accessibility of the URL), and no mention of when another sibling would be preferable. An agent gets no routing help beyond the obvious 'this is the download 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, destructiveHint=false and openWorldHint=true, so the read-only safety profile is covered. The description adds nothing beyond that profile (no pagination, ordering, or reply-count behavior), which is the baseline when annotations carry the safety burden.

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?

A single front-loaded sentence with no filler; the verb and target are stated immediately and nothing is wasted.

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 two-parameter read tool with an output schema and covering annotations, the definition is mostly sufficient. The minor gap is that it does not explain the workflow dependency on first calling the comments endpoint, but that is documented in the schema descriptions.

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 in-schema, including their provenance (the comments endpoint with include_reply_info=true). The description repeats the concept of a comment but adds no format or constraint 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?

Specific verb (Fetch) plus a precise resource (replies to a specific comment on a Facebook post). It is distinguishable from facebook_get_post_comments, which returns top-level comments, though the description never names that sibling to make the boundary 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?

There is no statement of when to use this tool versus facebook_get_post_comments or facebook_get_post_details, and no mention that the required inputs must first be obtained from the comments endpoint. Usage must be inferred entirely from 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, destructiveHint=false, and openWorldHint=true, so the safety and external-network profile is covered. The description adds the useful detail of what data is retrieved, but says nothing about auth requirements, rate limits, or whether private/closed groups are accessible.

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?

A single front-loaded sentence naming the resource and its payload, with no filler. It is efficient, though it could spend one clause on routing against siblings rather than only enumerating 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?

A read-only, one-parameter lookup with full schema coverage, explicit annotations, and an output schema that carries the return shape. The description covers purpose and payload adequately; only usage routing 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?

There is a single required parameter ('link') and schema description coverage is 100%, so the schema already documents it fully. The description adds no format guidance (e.g., URL shape or whether an ID works), 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 ('Facebook group') and enumerates the returned fields (member count, description, rules, activity stats), so the agent knows exactly what it fetches. It does not differentiate itself from nearby siblings like facebook_get_group_id or facebook_get_group_posts, 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?

The description gives no when-to-use guidance, no prerequisites, and no alternatives. With siblings such as facebook_get_group_id and facebook_get_group_posts in the catalog, an agent gets no signal on which one applies to a given intent.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description's 'Get' aligns with read-only but adds no further behavioral context such as auth needs, rate limits, or error behavior. With annotations carrying the load, this is adequate but not rich.

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?

A single, front-loaded sentence with zero wasted words. Perfectly sized for a simple URL-to-ID utility.

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?

Given the simple one-parameter operation, an existing output schema, and annotations covering safety, the description provides enough to call the tool correctly. It could be improved by noting that the ID is typically used as input to other group tools, but it is otherwise 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 single parameter 'link' is documented as 'Facebook group URL' in the schema. The description adds no additional format, pattern, or validation details beyond that schema 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?

States a specific verb (Get) and resource (Facebook group ID) and names the input (group URL). It is clearly distinct from siblings like get_group_details, get_group_posts, and get_page_id; there is no ambiguity about what it 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?

Provides no when-to-use guidance, no prerequisites, and does not mention alternatives. The input implies you have a group URL, but no explicit context, exclusions, or sequencing guidance is given.

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, openWorldHint and destructiveHint, so safety is covered. The description adds genuinely new behavioral context by disclosing the credit-based pricing model (ceil(posts_returned/3), minimum 1), which the agent cannot learn from 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?

Two short sentences with the core action front-loaded and the pricing constraint appended. No filler or redundancy; 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Adding the cost model makes this largely self-sufficient, though a brief note on how time filtering interacts with the cursor would close the last 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%, so every parameter (link, limit, timezone, after_time, before_time, end_cursor) is already documented in the schema. The description's references to pagination and time filtering add no syntax or format detail beyond that, 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: 'Fetch recent posts from a Facebook group'. The word 'group' cleanly separates it from siblings like facebook_get_page_posts and facebook_get_group_videos, 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?

There is no when-to-use or when-not-to-use guidance and no alternatives are referenced. The mention of 'pagination and time filtering' describes capabilities rather than conditions for selecting this tool over search_posts or get_page_posts.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-structural context: per-call cost (1 credit) and pagination behavior. It still says nothing about rate limits, auth requirements, or result volume, so it is a modest addition rather than rich disclosure.

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 core action and followed by the cost note. No filler or redundancy; 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?

An output schema exists, so return values need not be described, and annotations cover the read-only safety profile. The description covers action, scope, pagination, and cost, which is nearly everything needed to invoke it correctly; only prerequisite/auth context is 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 both parameters are documented in-schema (group URL, pagination cursor). The description's pagination reference aligns with end_cursor but adds no format, syntax, or constraint detail beyond what the schema already states, 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 (videos from a Facebook group), and the 'group' scoping clearly separates it from siblings like facebook_get_page_videos or facebook_search_videos. It does not explicitly name those alternatives, 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?

The mention of pagination implies the end_cursor parameter is for follow-up calls, which is a mild usage hint. However there is no guidance on when to use this versus facebook_get_group_posts, facebook_get_group_details, or facebook_search_videos, nor any 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 readOnly/openWorld/non-destructive, so the description is not obligated to restate safety. It usefully adds that exact_followers_count triggers a deeper scrape and that calls cost 1 or 5 credits, which is real behavioral information an agent should weigh before invoking.

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 sentences, zero padding, with the capability statement front-loaded and the cost caveat immediately after. Every clause 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 an output schema present, return values need not be explained, and both params are covered. What is missing is the relationship to adjacent tools (page ID resolution, page search) and any prerequisite that the input must be a full page URL rather than an ID.

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 both parameters (including the default for exact_followers_count) are fully documented in the schema. The description only restates the pricing already present in the parameter description, adding no new syntax or format 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 details about a Facebook page) and enumerates the fields surfaced (followers, contact info, category), so the agent knows what comes back. It does not differentiate itself from near-siblings like facebook_get_page_id or facebook_search_pages, which is the only thing holding it below 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?

No when-to-use guidance and no routing versus alternatives such as facebook_get_page_id (resolve URL to ID) or facebook_search_pages. The only decision aid is the cost tradeoff for exact_followers_count, which is a parameter choice, not tool 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context of its own — no note on resolution failure behavior (invalid/private page), rate limits, or what the tool does when the URL does not resolve to a 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?

A single front-loaded sentence with zero filler; the purpose and the input it operates on are stated immediately with no preamble.

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 an output schema present, return values need not be explained, and the single parameter is fully schema-documented. What is missing is the routing context in a sibling set of 40+ tools — an agent gets no signal about where this resolver fits in a page workflow.

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 documents the link parameter with a concrete example URL. The description adds no additional meaning about accepted URL formats, handling of non-canonical URLs, or usernames without a full URL, 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?

The description gives a specific verb (get), resource (Facebook page ID), and the input it derives from (a page URL), which is enough to distinguish it from get_page_details or get_page_posts. It does not, however, explicitly name or contrast with those siblings, so a 4 rather than 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 guidance on when to use this tool versus the many page-related siblings. An agent must infer that this is a cheap URL→ID resolver to run before calling get_page_details, and no exclusions (e.g., 'if you already have the numeric ID, skip this') 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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds meaningful non-annotation context: the pricing model (ceil(posts_returned / 3) credits, minimum 1) and that pagination/time filtering are supported, which an agent needs to budget and call correctly.

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 with the purpose front-loaded and pricing appended as a secondary concern. Nothing is wasted, though the pricing sentence could be marginally more compact.

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, output-schema-backed tool this is nearly complete: purpose, filtering scope, and cost are all covered, and return values need not be described since an output schema exists. The only real gap is routing guidance versus the group/search post siblings.

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 all six parameters (including link, limit, cursor, and time bounds) are already documented with types, defaults, and ranges. The description gestures at pagination and time filtering but adds no syntax 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 and resource ('Get recent posts from a Facebook page') and its scope (pagination and time filtering), which distinguishes it from facebook_get_group_posts and the search posts tools. It stops short of explicitly naming the sibling it is not, so sibling differentiation is left 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?

The page scope implies when this tool applies, but there is no explicit when-to-use or when-not-to-use guidance and no mention of the obvious alternatives (facebook_get_group_posts, facebook_search_posts). Usage is inferable from the subject but not 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, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured fields. The description adds nothing beyond that — no note on pagination behavior, rate limits, or whether the page must be public, despite an end_cursor parameter implying paginated results.

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?

A single efficient sentence that front-loads the resource and scope with no filler. It is arguably too terse to be maximally useful, but there is no wasted wording.

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?

An output schema exists, so return values need not be described, and the two parameters are schema-documented. Still, for a paginated open-world fetch tool the description omits contract details (pagination loop, page visibility requirements) that would help an agent 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 'link' and 'end_cursor' are already documented in the schema; baseline is 3. The description adds no syntax, format, or pagination semantics beyond what the schema provides.

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 ('reels/short videos from a Facebook page'), which clearly separates it from facebook_get_page_posts and facebook_get_page_videos. It does not, however, explicitly explain how it differs from the closely-named facebook_get_page_videos sibling, leaving the distinction to be inferred.

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, no prerequisites, and never mentions an alternative tool. An agent must guess whether reels should be fetched via this tool or the nearby get_page_videos sibling.

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=true, openWorldHint=true, destructiveHint=false), so the description is not the sole carrier. It adds two useful facts beyond the annotations: pagination is supported and each call costs 1 credit. It does not explain rate limits, auth requirements, or what happens with an invalid cursor.

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, zero filler, with the core capability front-loaded ahead of the pricing note. Nothing 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 an output schema present, return values need no explanation, and the schema fully documents all four optional parameters. The description covers scope, pagination and cost, leaving only minor gaps such as the relationship between link and profile_id, which the schema already hints at.

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 link, limit, end_cursor and profile_id are all fully documented in the schema. The description's mention of pagination loosely maps to end_cursor but adds no syntax, format, or constraint detail beyond what the schema already provides; 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 videos from a Facebook page') plus the pagination behavior. It is clearly distinguishable from facebook_get_group_videos and facebook_search_videos by the 'page' scope, though it does not name those siblings 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 prerequisites, and no routing to alternatives such as facebook_get_page_reels or facebook_get_video_details. The only usage-relevant detail is the pricing line.

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=true, destructiveHint=false, openWorldHint=true). The description adds real behavioral value the annotations don't: the cost model ('5 credits per call') and that this is a heavier scrape than standard post-details, which helps an agent weigh it against cheaper siblings.

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 with zero filler, and the core action is front-loaded before the pricing caveat. 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 an output schema present, return values need not be described, and the description covers scope and cost. It stops short of mentioning rate limits, error behavior, or what happens with posts lacking media, but is largely sufficient for a single-parameter 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 there is a single well-documented post_id parameter, so the schema carries the semantics. The description adds nothing about the parameter format, 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+resource: retrieving media attachments (images, videos) from a Facebook post. It also distinguishes itself from the post-details flow by noting this is a 'deeper scrape than standard post-details,' so an agent can separate it from facebook_get_post_details 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 when to use it (when media attachments are wanted) but gives no explicit when-not guidance or named alternatives, despite a closely related sibling like facebook_download_media. Usage is inferable but not 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 cover the safety profile (readOnly, non-destructive, open-world), and the description adds genuinely new context: the per-call cost (1 credit) and the fact that results are paginated. It does not disclose rate limits or what the response looks like, but pricing is a meaningful addition 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?

Two short sentences, no filler; the core action is front-loaded and the pricing caveat is placed last where it belongs. 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?

An output schema exists, so return values need not be described, and the description covers action, scope, pagination, and cost. The one gap is the absence of explicit routing to facebook_get_comment_replies for nested replies, which an agent might need given the large sibling set.

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 every parameter (link, limit, end_cursor, include_reply_info) is already documented in the schema. The description's mention of 'pagination' is the only added hint, which merely echoes the end_cursor parameter; baseline 3 applies when 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 (Retrieve) and resource (top-level comments) scoped to a Facebook post or reel, and the word 'top-level' implicitly carves out a distinct resource from the sibling facebook_get_comment_replies. It stops short of naming that sibling explicitly, so it is clear but not maximally discriminating.

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 'top-level' qualifier hints that reply retrieval is a separate operation, but the description never says when to use this tool vs. facebook_get_comment_replies or advertises any prerequisites. Usage is implied 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=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description usefully scopes the returned data, but adds nothing about auth, rate limits, or what 'detailed' excludes relative to the extended sibling.

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?

A single efficient, front-loaded sentence with no filler. It is slightly under-powered for disambiguating from the extended sibling, but there is no wasted text.

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 an output schema present and annotations covering the safety profile, the description need not explain return values. It is adequate for a one-parameter read tool, with the only gap being the unaddressed relationship to facebook_get_post_details_extended.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents 'link'. The description adds no format hints (e.g., permalink vs. ID) beyond what the schema provides, 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 detailed data about a Facebook post') and enumerates the payload (reactions, comments, shares, media). It does not differentiate itself from the sibling facebook_get_post_details_extended, which is the key ambiguity an agent faces here.

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 prerequisites, and no mention of the near-identical extended variant. The agent must guess which of the two post-detail tools to call based on the name alone.

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, destructiveHint=false, and openWorldHint=true, so safety profile is covered. The description adds valuable context about what extra fields are returned (view counts, video URLs, music metadata, author verification), but does not add further behavioral traits beyond annotations.

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

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

Two sentences, both front-loaded and purposeful. The first states scope and contents; the second states the specific use case. 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?

An output schema exists, so return values needn't be explained. The description covers purpose and when-to-use adequately, but could note whether this is a superset of standard details or an alternative, and any rate limits or auth needs.

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 only one parameter exists, already fully documented in the schema. The description doesn't add syntax or format guidance beyond what the schema provides, so 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 (extended details about a Facebook post), and enumerates distinguishing fields (view counts, video URLs, music/audio metadata, author verification). Clearly differentiated from the sibling facebook_get_post_details by the 'extended' 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?

Explicitly names the condition for use: 'Use this when the standard post_details response is missing fields like view_count, video_hd_src, or attached_track.' The alternative (standard post_details) is named and the triggering gap is spelled 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile, so the description is not obligated to restate that. However, it adds nothing new: it does not say whether the ID is parsed locally or resolved over the network (relevant given openWorldHint=true) or what happens when the URL is malformed.

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?

A single eight-word sentence with the action front-loaded and no filler. Nothing could be removed without losing 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?

The tool is trivially simple (one param, read-only, output schema present so return values need no explanation), and the description is adequate for that shape. It is still thin on the two things an agent would want: failure behavior on invalid URLs and how this resolver relates to the sibling ID-lookup and post-detail tools.

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 at 100% schema description coverage, the schema fully documents 'link', so the baseline of 3 applies. The description contributes no additional meaning such as accepted URL formats or required URL shape.

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 (extract) and resource (Facebook post ID) with the input (post URL) made explicit, so the transformation is unambiguous. It does not differentiate itself from the near-identical siblings facebook_get_page_id, facebook_get_group_id, and instagram_get_post_id, which is the only thing keeping it from 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 when-to-use guidance, no statement of what the returned ID is for, and no mention of alternatives such as facebook_get_post_details. The 'from a post URL' clause only weakly implies the precondition, so an agent must infer the routing decision on its own.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the categories of data returned (metadata, stats, context) but says nothing about auth requirements, rate limits, or what happens with an invalid/private video ID.

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?

A single front-loaded sentence with no filler; the verb and returned data types come first and nothing repeats the title or 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 one-parameter read tool with an output schema and full annotation coverage, the description is nearly sufficient — return values need not be enumerated. The vague term 'context' is the only gap, mildly reducing completeness.

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 video_id parameter, and the description only restates that the ID refers to a Facebook video post. It adds no ID format, source, or resolution guidance beyond what the schema already documents, so 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 (video metadata, stats, and context for a Facebook video post), which clearly separates single-video detail lookup from sibling listers like facebook_get_page_videos and facebook_search_videos. It does not name any sibling explicitly, so differentiation is inferred rather than stated.

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 tool takes a video_id and returns details, so an agent can infer it is for fetching a known video rather than discovering one. There is no explicit when-to-use, when-not-to-use, or pointer to 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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the result carries SEO URLs and IDs, but since an output schema exists this is largely a restatement of the return shape; no auth, rate-limit, or caching behavior is disclosed. Some added context, but not rich.

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?

A single front-loaded sentence with no filler. Every word earns its place and the payload contents follow the action immediately.

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 zero-parameter lookup with a full output schema and read-only annotations, the description is sufficient to call the tool correctly. The only real gap is the absence of routing guidance toward the search/listing siblings that consume these category IDs.

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 tool takes zero parameters, so the schema carries no semantics to miss; baseline is 4. Nothing in the description is needed to constrain inputs.

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 concrete verb ('Get') and resource ('all Marketplace categories') and even names the returned payload fields (SEO URLs, category IDs). It is clearly distinguishable from sibling tools like facebook_marketplace_search or facebook_marketplace_listing, though it never explicitly names or contrasts them.

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 guidance, no prerequisites, and no indication of how the result relates to siblings such as facebook_marketplace_search (e.g. as a source of IDs for filtering). Usage is only implied by the resource 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 already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds only the intended downstream use (Marketplace filters), with no detail on rate limits, result shape, or ambiguity handling when multiple cities match.

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?

A single front-loaded sentence with no filler, leading with the action and resource. It is perhaps overly terse given the open-world lookup, but nothing is wasted.

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?

An output schema exists, so return values need not be described here. For a simple coordinate lookup the description is sufficient, though it could note behavior when multiple cities match or how country disambiguates.

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 every parameter is already documented in the schema (city, country, exactly_one). The description adds no syntactic 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 GPS coordinates for a city'), which is a clear, non-tautological purpose. It does not name or contrast with any sibling (e.g. facebook_search_locations, facebook_marketplace_categories), so an agent must infer differentiation from the Marketplace scoping alone.

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 phrase 'to use as Marketplace location filters' implies the usage context, giving the agent a rough sense of when this is appropriate. It offers no explicit when-to-use/when-not guidance and does not point to alternative tools for locating cities or locations.

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?

The annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no note on whether a missing/private listing errors, no rate-limit or auth context, no indication of what 'detailed info' includes. It essentially restates the read-only nature the annotations already convey.

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?

A single short sentence with zero filler and the resource front-loaded. Appropriately sized for a one-parameter getter, though its brevity leaves the gaps in usage and behavior unfilled rather than being maximally efficient.

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?

An output schema exists, so return values need not be described, and annotations cover safety. What's missing is disambiguation from the many other facebook_marketplace_* siblings and any note on failure behavior for an invalid/removed listing. Adequate but with clear gaps for a tool in a dense sibling cluster.

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?

One required parameter (listing_id) with 100% schema description coverage, so the schema already carries the semantics. The description adds no format or sourcing detail (e.g., where a listing_id comes from, whether it comes from a search result). Baseline 3 applies when 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 (Get) and resource (a single Marketplace listing) with the 'detail for one item' scope that separates it from the marketplace search/listing-collection siblings. However, it never names those siblings (facebook_marketplace_search, facebook_marketplace_seller), so the differentiation must be inferred from the phrase 'a single'.

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 alternatives named, despite ~5 marketplace siblings (search, seller, categories, rentals, vehicles) that could plausibly be confused with this one. An agent gets no explicit routing rule for picking this tool over facebook_marketplace_search or facebook_marketplace_seller.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds no behavioral context of its own: it does not mention that end_cursor drives pagination, that radius filtering likely requires coordinates, or how results are ordered by default. Beyond restating the filters, it contributes nothing the structured fields don't already carry.

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?

A single front-loaded sentence with zero filler; the core verb and resource lead and the qualifiers follow. Nothing is padded or repeated from the 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?

Since an output schema exists, return values need no explanation. However, for an 11-parameter search tool with no required fields, the description omits meaningful operational detail: how pagination works, that latitude/longitude pair with filter_radius_km, and which defaults apply. Adequate but with clear gaps.

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 all 11 parameters are already documented in the schema, which sets the baseline at 3. The description names four filter categories that map onto existing parameters but adds no new semantics such as coordinate/radius pairing rules or sort behavior.

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 ('Search') and resource ('Marketplace rental property listings') and enumerates the filter axes (bedrooms, bathrooms, location, price). This separates it from generic siblings like facebook_marketplace_search or facebook_marketplace_vehicles, though the distinction is implied by the word 'rentals' rather than stated 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?

There is no when-to-use guidance and no routing to alternatives such as facebook_marketplace_search (general listings) or facebook_marketplace_vehicles. The agent must infer selection purely from the token 'rentals' in the name, with no stated 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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful operational context beyond annotations by stating 'Pricing: 1 credit per call.' It does not cover auth needs, rate limits, or pagination behavior, so it is not fully exhaustive.

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 two sentences and front-loads the core purpose before the pricing note. Every sentence adds value: the first states what it searches and which filters exist, and the second gives cost 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 rich annotations, full schema coverage, and an output schema, the description does not need to explain return values or parameter formats. It covers the core action and cost, but it omits routing guidance relative to nearby marketplace siblings. That gap is not fatal, but it keeps the definition from being fully 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%, so each of the 13 parameters is already documented in the input schema. The description lists broad filter categories but adds no syntax, format, or boundary details beyond what the schema provides. This matches the baseline of 3 when 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?

The description states a specific verb and resource: 'Search Facebook Marketplace items.' It also names the filter dimensions, making the tool's scope clear. However, it does not distinguish this general marketplace search from sibling tools like facebook_marketplace_vehicles, facebook_marketplace_rentals, or facebook_marketplace_listing.

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 naming the searchable filters and stating the credit cost. It does not say when to choose this tool over sibling marketplace or general search tools, nor does it list any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds no behavioral context beyond that – no mention of auth needs, rate limits, error behavior when a seller_id is invalid, or data freshness. It essentially restates the return payload, which the output schema already defines.

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?

A single tight sentence with the resource front-loaded and zero filler. Appropriately sized for a one-parameter read tool, though its brevity reflects under-specification rather than disciplined editing.

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?

An output schema exists, so return values need no explanation, and the operation is a simple read-only lookup. However, with ten marketplace-related siblings, the description gives no help on where seller_id comes from or how this differs from listing-level tools, leaving a real gap for a shallow 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?

Single parameter seller_id with 100% schema description coverage, so the schema carries the burden; baseline is 3. The description adds nothing about format (numeric ID vs. username) or where the ID is sourced.

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 (seller profile) with the payload contents enumerated: ratings, reviews, badges. Clearly distinct from sibling tools like facebook_marketplace_listing, which fetches a listing rather than a seller. No explicit sibling differentiation in text, so not 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?

No indication of when to use this tool versus facebook_marketplace_listing, facebook_marketplace_search, or facebook_search_people. An agent must infer that seller_id comes from a listing/search result. No exclusions or prerequisites 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. Beyond that the description adds nothing behavioral: no pagination behavior for end_cursor, no note that results are public/open-world listings, no rate-limit or auth context. With annotations doing the heavy lifting, the description contributes almost no extra behavioral value.

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?

A single front-loaded sentence that names the operation before the filter list, with no filler or redundancy. It is appropriately sized for its content, though the content itself is thin.

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?

An output schema exists, so return values need not be explained. However, for an 8-parameter paginated search tool with all-optional inputs, the description says nothing about defaults, how end_cursor pagination is expected to be used, or how this differs from the general marketplace search sibling — leaving real gaps 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 description coverage is 100% across all 8 parameters, so the baseline is 3. The description's filter list (location, price, mileage, year) roughly mirrors schema fields, though "year" corresponds to no actual parameter and "mileage" only exists indirectly via sort_by=VEHICLE_MILEAGE_ASCEND, so the description neither compensates nor misleads meaningfully.

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 clear verb and resource ("Search Marketplace vehicle listings") plus the filter dimensions, which is enough for an agent to know it retrieves vehicle ads. It does not, however, distinguish itself from the closely related siblings facebook_marketplace_search, facebook_marketplace_listing, and facebook_marketplace_rentals, 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?

There is no when-to-use guidance, no mention of when to prefer the generic facebook_marketplace_search or facebook_marketplace_rentals instead, and no prerequisites. The only routing signal is the word "vehicle" in the resource name, which is implied 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds the useful behavioral note that it returns UIDs for geo-filtering other endpoints, but doesn't describe pagination, rate limits, or result scope. With annotations, this is adequate but not rich.

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 core action, then the return/usage note. Every clause is 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?

For a single-parameter search with a full output schema and readOnly annotations, the description covers purpose and the key output use case (UIDs for geo-filtering). It's nearly complete; only the exact return shape is left to the output schema.

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?

Only one parameter, and schema description coverage is 100% with an example (city, place, landmark). Baseline for one fully-documented parameter is 4; the description adds nothing beyond the schema but doesn't need to.

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 clear verb + resource (search Facebook locations by keyword), which is specific. Doesn't differentiate from siblings like facebook_search_pages or instagram_get_nearby_locations, but the resource 'locations' is distinct enough in name.

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 second sentence implies usage ('Returns UIDs for geo-filtering other search endpoints') but doesn't name a specific alternative or give explicit when/when-not criteria. A nearby sibling is instagram_get_nearby_locations, which isn't mentioned.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no note about pagination behavior via end_cursor, rate limits, or result volume for an open-world search.

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?

A single front-loaded sentence with the core verb and resource first, followed by the optional modifier. Nothing is wasted, though it is arguably too terse to be maximally useful.

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?

Output schema exists and annotations cover the safety profile, so the description needn't explain returns. However, for a paginated open-world search tool, the lack of any pagination or scope note leaves minor gaps.

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 baseline is 3. The description confirms keyword and location filtering map to parameters, but adds no format or source detail for end_cursor or location_uid beyond what the schema already states.

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 (search) and resource (Facebook pages) with the keyword-scoping detail. The resource noun naturally separates it from siblings like facebook_search_people and facebook_search_posts, though it never names them 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 beyond the implicit 'you want to find pages'. It doesn't mention when to prefer facebook_get_page_details for a known page, nor how to obtain the location_uid beyond a terse schema hint. No exclusions or alternatives are given.

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, destructiveHint=false, and openWorldHint=true, so the safety profile of this read-only search is covered. The description is consistent with those hints but adds almost nothing behavioral beyond the keyword/location scope, and says nothing about pagination handling or result volume.

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?

A single front-loaded sentence with no filler; the resource and the keyword/location scoping appear immediately. It is efficient, though the brevity borders on under-specification rather than sharp conciseness.

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?

An output schema exists and parameter coverage is complete, so the description needn't explain returns or inputs. However, for a tool sitting among five near-identical 'search' siblings, it omits the routing information an agent most needs to pick 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 query, end_cursor, and location_uid are already documented in the schema. The description echoes keyword search and location filtering but adds no format or usage 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 ('Search for Facebook people/profiles') plus the scope (by keyword). It is clearly distinguishable from fellow search tools, but it does not name those siblings (facebook_search_pages, facebook_search_posts, facebook_search_videos) to differentiate 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?

There is no when-to-use guidance and no routing to alternatives, despite four sibling search tools (people, pages, posts, videos) that an agent must choose between. The only hint is 'with optional location filtering', which is not a usage condition.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the filter scope (keyword, location, time) and does not disclose auth needs, rate limits, or pagination behavior beyond what the schema already says.

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 definition is a single front-loaded sentence with no wasted words. It efficiently states the core action and optional filters.

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 full schema coverage, rich safety annotations, and an output schema, the description need not explain parameters or return values. It is complete enough for invocation, though sibling routing and pagination handling remain 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 description coverage is 100%, so the schema already documents all six parameters, including date formats and the pagination cursor. The description merely restates some parameter concepts (keyword, location, time filters) without adding syntax, defaults, or examples 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?

The description gives a specific verb (Search) and resource (Facebook posts) and notes the keyword scope. It implicitly distinguishes itself from sibling video/page/people searches by saying 'posts,' but never names those alternatives 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?

It states what the tool does but gives no when-to-use or when-not guidance, and no alternatives despite many sibling search tools (search_videos, search_pages, search_people). The agent receives no routing criteria for choosing 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, destructiveHint=false, and openWorldHint=true, so the safety and world-scope profile is covered. The description adds the 'by keyword' search model, but does not disclose pagination behavior (though end_cursor exists) or result characteristics. With annotations doing the safety lifting, a 3 is appropriate.

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?

A single efficient sentence that front-loads the core action and resource, then lists optional filters. No filler 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?

An output schema exists, so return values need not be explained in the description. With annotations covering safety, schema covering parameters, and a clear core purpose, the definition is nearly complete. The only mild gap is lack of sibling-differentiation guidance, which would help in this large tool family, preventing a full 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%, so every parameter including query, fields, end_cursor, most_recent, and videos_live is documented in the schema. The description only echoes the filter concept; no additional format, syntax, or constraint details are provided beyond the schema. Baseline 3 per the 100%-coverage rule.

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 (Search) and resource (Facebook videos) plus scope qualifiers (by keyword, with recency and live filters). The 'search' verb makes it clearly distinct from sibling get_* tools that retrieve known resources (e.g., facebook_get_group_videos, facebook_get_page_videos).

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: use this when you have a keyword and want to discover videos. However, there is no explicit guidance on when to prefer this over content-specific siblings like facebook_get_group_videos or facebook_get_page_videos, nor exclusions for the filters.

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, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds only that all contained stories are returned, which is largely redundant with the existing output schema. No rate limits, auth requirements, or pagination behavior are disclosed.

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?

A single sentence with no filler, and the resource is front-loaded before the return-scope clause. Appropriately sized for a one-parameter getter, though not so tight that it improves on a plain statement of purpose.

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 an output schema covering return values and annotations covering safety, the description only needs to establish purpose and input sourcing, which it does. Minor residual gap is the lack of any failure/empty-highlight guidance, which is low-stakes 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?

Only one parameter, and schema coverage is 100% — the schema already documents highlight_id and its source. The description's 'by ID' phrasing restates the schema without adding format or edge-case guidance, 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 (Get) and resource (highlight details) and clarifies the return scope: 'including all stories within the highlight'. This distinguishes it implicitly from instagram_get_profile_highlights, which lists highlights rather than detailing one, though the sibling is never named.

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 'by ID' and by the parameter note that the ID comes from the profile highlights endpoint, so an agent can infer the upstream call. There is no explicit when-to-use/when-not or named alternative, so it stays at the minimum viable level.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that results can be 'top/ranked or most recent', which duplicates the tab param, and says nothing extra about rate limits, auth, or pagination behavior beyond the end_cursor field.

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 core action. The second sentence largely restates the first while adding the tab distinction, so there is minor redundancy but no wasted bulk.

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 an output schema present, the return values need no explanation, and annotations cover safety. Required params and optional pagination are clear, leaving only the omission of how to source a location_id as 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema, and the description's 'top/ranked or most recent' merely paraphrases the tab enum values. Baseline 3 is appropriate since the schema carries the semantic 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 (Get) and resource (Instagram posts) scoped to a location, and the second sentence clarifies that posts are 'tagged at a place', which separates it from instagram_get_profile_posts. It does not name any sibling explicitly, 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 implied: you call it when you have an Instagram location_id. The description never says how to obtain a location_id (e.g. via instagram_get_nearby_locations) or when to prefer it over instagram_get_profile_posts, so no explicit when/when-not routing is provided.

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, destructiveHint=false, and openWorldHint=true, so safety behavior is covered structurally. The description adds that results are scoped to one location and lists what comes back, but says nothing about authentication needs, rate limits, result volume, or pagination — modest added value beyond the annotations.

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

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

A single front-loaded sentence with no filler; the resource and returned fields come first. It stops just short of the ideal because the list of returned fields occupies space while omitting the more decision-relevant routing 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?

An output schema exists, so return values need not be explained, and the single parameter is fully documented. However, with many location- and post-oriented siblings in scope, the absence of any routing or prerequisite guidance leaves an agent with a real gap when deciding whether this is the right call.

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 required parameter with 100% schema description coverage ('Instagram location ID'), so the schema already carries the semantics. The description only restates the scoping ('for a specific Instagram location') with no id format, source, or example, which is the expected baseline when 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?

The description names a specific verb and resource ('Get nearby places/locations for a specific Instagram location') and enumerates the returned attributes (name, category, coordinates, post count). It is clearly distinguishable from post-oriented siblings, though it does not explicitly differentiate itself from location-search siblings like facebook_search_locations.

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 the tool needs an existing Instagram location (via 'for a specific Instagram location'), but gives no explicit when-to-use, prerequisites, or alternatives. An agent cannot tell from the text when to pick this over facebook_search_locations or instagram_get_location_posts.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the set of returned facets but says nothing about auth needs, rate limits, or behavior on private/deleted posts, so it only marginally exceeds 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?

One tight, front-loaded sentence with the verb and resource first and the enumerated fields immediately after. No filler, no repetition of the 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?

An output schema exists, so return-value documentation is unnecessary, and annotations carry the safety profile; the description is sufficient for this simple single-parameter read tool. Minor gaps remain around how to obtain a valid shortcode and what happens for private or nonexistent posts.

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 'shortcode' parameter is fully documented in the schema with an example. The description adds no extra semantics such as how to derive the shortcode from a URL or whether an internal ID is accepted, 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?

The description states a specific verb and resource ('Get full details of a specific Instagram post') and enumerates the returned facets (media, engagement, caption, owner info). It does not, however, explicitly distinguish itself from the adjacent instagram_get_post_id or the more scoped get_post_details variants in the sibling set.

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, when-not-to-use, or alternative-tool guidance. The only implied condition ('to get post details, call get_post_details') merely restates the name, and nothing explains how it relates to instagram_get_post_id.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the 'any Instagram post URL' breadth claim; it says nothing about behavior on malformed/non-post URLs or failures, but with annotations carrying the burden a 3 is appropriate.

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?

A single front-loaded sentence with zero filler; the action and the input are established in the first few words.

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?

An output schema exists, so return-value shape need not be explained, and for a one-parameter extraction utility the description covers the essentials. Minor gaps (URL format tolerance, error behavior) are not fatal 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 description coverage is 100% for the single 'link' parameter ('Instagram post URL'), so the schema already does the work. The description's 'any Instagram post URL' is consistent but adds no format, example, or accepted-URL-variant 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?

The verb ('Extract') and resource ('post shortcode/ID from any Instagram post URL') are specific and unambiguous, so an agent can immediately tell this is a URL-to-ID parser rather than a content fetcher like instagram_get_post_details. It stops short of naming or contrasting any sibling explicitly, which keeps it from 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 by the narrow purpose: call it when you hold an Instagram post URL and need the ID for another call. It never states when NOT to use it or points to a sibling (e.g., instagram_get_post_details / instagram_get_user_id), so guidance is inferential rather than explicit.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the returned data fields, which is modest value beyond annotations, but says nothing about auth requirements, rate limits, or failure modes for private/nonexistent 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?

A single efficient sentence with the resource and scope front-loaded and no filler. It could be slightly tighter, but every clause contributes useful field 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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. The remaining gap — no when-to-use guidance or differentiation from the many sibling retrieval tools — is minor 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 coverage is 100% and both parameters (username, link) are documented there, including that link is an alternative to username. The description only mentions username and adds no syntax or format detail, so the schema does the heavy lifting — 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 user profile information by username') and enumerates the returned fields (bio, followers, posts count, verification, related profiles). This distinguishes it from content-fetching siblings like instagram_get_profile_posts, though it never explicitly names those siblings.

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 guidance on when to use this vs alternatives such as instagram_get_user_id (if only the ID is needed) or instagram_get_profile_highlights. The description gives no context, prerequisites, or exclusions, leaving routing 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds the returned field set, but says nothing about auth requirements, rate limits, pagination, or private-account behavior for an open-world scrape.

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?

A single front-loaded sentence with no filler; the resource and payload are stated immediately. It is near-optimal in length, though not maximally informative per word.

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 an output schema present, return values need not be explained, annotations cover the safety profile, and the one required parameter is fully documented in the schema. Only the relationship to the highlight-details sibling 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?

Schema description coverage is 100% for the single user_id parameter, so the schema already carries parameter meaning. The description adds no format or sourcing detail beyond what the schema documents; 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 ('all highlights from a user profile') and enumerates the returned fields (cover images, titles, permalinks). It is clearly distinguishable in spirit from the singular instagram_get_highlight_details sibling, though it does not name or explicitly contrast that sibling.

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 by the plural 'all highlights' phrasing; there is no explicit when-to-use statement and no mention of the closest alternative, instagram_get_highlight_details. An agent can infer it is the list-level counterpart, but nothing is 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the behavioral nuance that username yields more results and that results are paginated, but says nothing about rate limits, auth requirements, or how pagination terminates.

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 with zero filler, and the core action is front-loaded ahead of the parameter hint. 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 annotations covering safety and an output schema covering return shape, the description is adequate for invocation. It is nonetheless incomplete on the one thing that matters most here: distinguishing profile posts from the sibling reels/highlights/profile-details tools in the same Instagram group.

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 user_id, username, and end_cursor, including the 'recommended — returns more results' note. The description merely restates that same guidance, adding no syntax, format, or constraint information beyond the structured fields.

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 from a user profile") and adds the pagination scope, so the agent knows exactly what is returned. It does not distinguish this from close siblings like instagram_get_profile_reels or instagram_get_profile_highlights, so a reader could confuse the resource boundaries.

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 only guidance is parameter selection ("Provide username ... or user_id"), which is about how to call rather than when to choose this tool. There is no statement of when to prefer this over instagram_get_profile_reels, get_profile_highlights, or get_location_posts, all of which return related profile content.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the pagination behavior and a hint at return content, which is useful but thin given the annotations do most of the work.

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, front-loaded with the core action followed by the return summary. Every phrase 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?

An output schema exists so return values need not be spelled out, and annotations cover the safety profile. The description is adequate for this simple two-parameter read tool, though it could note how pagination terminates or what the cursor returns.

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 and end_cursor are already documented. The description mentions 'pagination' but adds no format, cursor handling, or default details beyond what the schema provides. 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 reels from a user profile') and scope that distinguishes it from instagram_get_reels_feed and instagram_get_reels_by_audio. It does not explicitly name those siblings, but the 'from a user profile' scoping is clear.

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 scope ('from a user profile'), but there is no explicit when-to-use guidance and no mention of the alternative tools (reels feed, reels by audio) that an agent must choose between. No exclusions or prerequisites 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond the annotations — no mention of pagination semantics for max_id, result volume, or auth requirements — and largely restates the purpose.

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 core action, but the second sentence is a paraphrase of the first rather than adding information. Minor redundancy costs it the top score.

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?

An output schema exists, so return values need not be described, and the tool is a simple two-parameter read. However, nothing is said about pagination flow or how results are scoped, leaving the description minimally adequate rather than 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% for both parameters (audio_id and max_id cursoring), so the schema carries the parameter burden. The description adds no meaning beyond what the schema already documents, which is the 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 (Get) and resource (Instagram Reels by audio/music ID), which clearly distinguishes it from siblings like instagram_get_profile_reels and instagram_get_reels_feed. It does not explicitly name those alternatives, so sibling differentiation is implied rather than stated.

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 second sentence ('Find all reels using a particular sound') implies the use case but gives no explicit when-to-use vs. when-not guidance and does not point to alternative reel-retrieval tools. Usage is inferable but not spelled 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the feed may be recommended, trending, or chained from a prior clip, which is genuine context, but says nothing about auth/session requirements, rate limits, or pagination behavior beyond the chained mode.

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?

One front-loaded sentence with no filler; the feed types are listed compactly. It earns its place, though a short clause on when to prefer it would be worth the extra length.

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 an output schema present, return values need no explanation, and annotations cover safety. Still, for a feed tool in a family of similar reels tools, the description omits the routing and pagination guidance an agent needs to call it correctly versus its siblings.

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 parameter (clips_media_id) is fully documented in the schema. The description only alludes to chaining via 'same-author chained clips' without adding syntax or usage 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 (Get) and resource (Instagram Reels feed) and enumerates what the feed contains: recommended, trending, or same-author chained clips. It does not, however, explicitly distinguish itself from siblings like instagram_get_profile_reels or instagram_get_reels_by_audio, so an agent must infer the difference from names alone.

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 names feed modes but never says when to choose this tool over the sibling reels tools (profile reels, audio reels). No prerequisites, no exclusions, no routing guidance is given; usage is left entirely 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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that the tool accepts either a link or a username, which is contextual value but not real behavioral disclosure beyond the schema.

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

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

A single front-loaded sentence with no filler; the core action and its input variants come first and nothing is wasted.

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?

An output schema exists, so return values need not be described. For a simple ID-lookup tool this is largely sufficient, with the only residual gap being the absence of guidance on the optional link/username choice.

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 'link' and 'username' are already documented in the schema. The phrase 'from a link or username' mirrors the params but adds no format, precedence, or mutual-exclusivity information, 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 the unique ID of any Instagram profile') and clarifies scope with 'link or username'. It is distinguishable from profile-data siblings like instagram_get_profile_details, but it never names or explicitly contrasts with a sibling tool.

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 this over instagram_get_profile_details, and no indication of how the resulting ID should be used. The description also does not clarify the relationship between the two input paths (link vs username) despite neither being required.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that results span users/hashtags/places, but says nothing about rate limits, auth needs, or pagination behavior beyond the cursor param.

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?

A single front-loaded sentence with no filler; the verb and scope come first and every clause 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 two-parameter read-only search with a full output schema and complete parameter coverage, the description supplies enough context for an agent to invoke it correctly. Only minor behavioral detail is 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%, so both parameters (keyword, end_cursor) are already documented in the schema. The description adds no syntax, format, or filtering detail beyond that 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?

States a specific verb (search) and resource (Instagram by keyword) plus the result categories (users, hashtags, places). This clearly separates it from the instagram_get_* retrieval siblings, though it does not explicitly name or contrast with any of them.

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 by 'search by keyword'; there is no explicit when-to-use, when-not-to-use, or alternative named. Since no close sibling performs an Instagram keyword search, the disambiguation burden is low, keeping this at an implied-usage 3.

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