API Direct

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

With no annotations provided, the description carries the full burden. It discloses pagination behavior ('each page returns up to 50 ranked items'), the typical top-100 coverage, and the fields included in each item. It does not mention authentication, rate limits, or error behavior, but for a read-only rankings tool the disclosed behavior is substantial.

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 deliver the core action, the supported ranking types, the return fields, and pagination constraints. There is no fluff or repetition of obvious 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?

Given no output schema or annotations, the description does a good job of explaining what the response contains and how pagination works. It could be more complete by noting valid country-code values or potential limitations, but the essential information for selecting and calling the tool is present.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining page size, top-100 coverage, and what each returned item contains. It reinforces the enum values and category slug concept, though it does not add much detail for the country parameter.

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 starts with a specific verb and resource: 'Get Amazon best-seller rankings for a category.' It enumerates the supported ranking types and clarifies that the result is a ranked list, which clearly distinguishes it from sibling product-search and product-detail tools like search_amazon_products and amazon_product_details.

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 makes the tool's purpose immediately evident: use when you need category best-seller rankings rather than product details or free-form product searches. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that an agent can route appropriately.

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?

There are no annotations, so the description carries the behavioral burden. It uses a clear read verb ('Get') and discloses a detailed return payload including pricing, buy box seller_id, availability, condition, media, specs, rating breakdown, and reviews. It does not discuss error/not-found behavior, but the read-only nature is transparent.

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 with no wasted words: the first delivers the purpose and input source, the second packs a comprehensive list of return fields. 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?

No output schema exists, so the detailed return field list is essential and is provided. The parameter schema covers the only required input and the optional country default. Minor omissions like invalid-ASIN handling or country-specific behavior do not prevent correct invocation.

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

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

Schema coverage is 100% and both parameters are documented, so the baseline is 3. The description adds value by explaining that the asin is the 10-character code produced by search_amazon_products, which clarifies the expected input more concretely than the schema alone.

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 full details for an Amazon product by ASIN." It also enumerates the returned fields, which distinguishes it clearly from sibling search tools like search_amazon_products. Mentioning that the ASIN comes from search_amazon_products further disambiguates the tool's role.

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: after search_amazon_products returns an ASIN, when full product details are needed. It does not explicitly name alternatives to exclude, but the ASIN provenance guidance and the detail-focused purpose provide enough routing context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful behavioral context: pagination of ~16 results per page, sortability by price/reviews/newest/best sellers, and that it returns the same product objects as search_amazon_products plus total catalog size. It does not mention error handling or rate limits, but for a read-only catalog fetch this is reasonably transparent.

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 with no filler. The core action and required identifier are front-loaded, and the second sentence adds relevant comparison and pagination/sort behavior. Every clause contributes useful information.

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

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

For a paginated catalog tool with no output schema, the description covers what is returned, the relationship to search_amazon_products, page size, and sortability. It does not explain error behavior for invalid seller IDs or country-specific nuances, but those are typically not required for tool selection and invocation. The required parameter, pagination, and sorting are all addressed.

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 adds marginal semantic value by summarizing sort options as 'price, reviews, newest, or best sellers,' but the schema already documents every parameter, enum, and default. 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?

The description clearly states a specific verb and resource: 'Get the catalog of products sold by an Amazon seller by seller ID.' It distinguishes itself from the sibling search_amazon_products by noting it returns the same product objects plus the seller's total catalog size, avoiding confusion with other Amazon tools.

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 this tool: when you have a seller ID and need all products from that seller. It explicitly references search_amazon_products as the related alternative and clarifies the difference, though it does not state explicit exclusion cases or say 'use search_amazon_products for keyword searches.'

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?

No annotations are provided, so the description carries the full burden. It clearly discloses the operation as a read (Get) and enumerates the returned data (name, logo, ratings, feedback breakdown). It does not mention error cases, rate limits, or marketplace-specific variations, but for a simple profile lookup the behavior is well specified.

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 with no waste: the first sentence states the action and input source; the second lists the full return payload. The information is front-loaded and every phrase 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?

The description fully enumerates return fields, compensating for the missing output schema, and provides the input-source context. It does not address possible failure modes (e.g., invalid seller_id, unsupported country) or clarify that seller_id is marketplace-specific, but for a low-complexity two-parameter tool it is largely 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 coverage is 100%, so the baseline is 3. The description adds meaningful context above the schema by explaining that seller_id comes from a product's main_buy_box.seller_id, giving the agent a concrete extraction path. The country parameter is already self-explanatory in 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 states a specific verb ('Get'), a specific resource ('Amazon seller's profile'), and the exact input ('seller ID'). It also explicitly differentiates from sibling tools like amazon_seller_products and amazon_seller_reviews by focusing on profile attributes (name, logo, business address, ratings, feedback).

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 clearly implies the intended use case: when you have a product's main_buy_box.seller_id and need the seller's profile details. It does not, however, explicitly contrast against sibling tools like amazon_seller_products or amazon_seller_reviews, or state when not to use it. The source-of-ID hint provides strong contextual 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?

With no annotations, the description must carry behavioral disclosure. It does so by explaining the pagination loop and enumerating the expected review fields. It doesn't mention rate limits or error behavior, but for a read-only get operation the disclosed behavior is adequate.

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 tightly written sentences with no filler. The main purpose and return fields are front-loaded, followed by filtering and pagination guidance. 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?

The description covers the required input, the review fields returned, filter options, and pagination behavior. Since there is no output schema, the field enumeration helps compensate; country and sentiment details are adequately handled by the input 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?

Schema description coverage is 100%, and each parameter already has a meaningful description, including the detailed get_sentiment explanation. The tool description adds only pagination context for the page parameter and doesn't meaningfully deepen semantics for the other parameters.

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 uses a specific verb and resource: 'Get customer feedback for an Amazon seller by seller ID.' It then enumerates the data fields returned, making it clearly distinct from siblings like amazon_seller_profile and amazon_seller_products.

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 concrete operational guidance: filter by star_rating or sentiment, and paginate with page until has_next_page is false. It doesn't explicitly name alternatives or exclusion conditions, but no sibling directly overlaps with seller reviews, so the context is clear enough.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses concurrency, per-item status/body, input-order preservation, separate billing per item, unsupported endpoint inside a batch, potential latency for large batches, and a docs link. This is comprehensive and gives the agent confidence in side effects and cost behavior.

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

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

Four sentences deliver all essential information: definition, example, concurrency and order, billing, exclusion, latency, and docs reference. No fluff, every sentence earns its place, and key facts are front-loaded. The structure is logical and scannable.

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 tool has no output schema and no annotations, the description covers the critical context: what the tool does, how many items, mixing, concurrency, per-item result format, billing, limitation, potential long duration, and a link to full docs. This is complete enough for an agent to select and invoke the tool 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?

The schema already provides 100% coverage of the only parameter, describing items, endpoint, params, and tag. The description adds an example and reiterates the mix of endpoints but doesn't provide new parameter-level semantics beyond the schema. Per the rubric, baseline 3 is appropriate when schema coverage is high.

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 uses a specific verb phrase 'Execute up to 100 API Direct requests in a single call' and clearly identifies the resource as a batch aggregation of other endpoints. It distinguishes from siblings by explaining it can mix any of the other tools' endpoints, with a concrete example (50 twitter_user_profile + 50 instagram_user_profile). This leaves no ambiguity about what the tool does.

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 clearly states the primary use case (batching multiple API requests) and the limitations (no /v1/web/ai-mode, large batches can take minutes). However, it doesn't explicitly contrast with using individual endpoint tools directly, though the example and wording strongly imply the alternative. A direct statement like 'For single requests, use the specific endpoint tool' would earn a 5.

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

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

No annotations are present, so the description must carry the full burden. It only states 'Get', which implies a read-only operation, but provides no details about authentication requirements, rate limits, error behavior, or whether the group must be public. This lack of behavioral disclosure is a significant gap for a tool with no annotation support.

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 a single, clear sentence that immediately states the tool's purpose and key outputs. Every word earns its place, with 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?

For a simple 1-parameter read tool, the description gives a fair overview but omits an exhaustive list of return fields (uses 'including'), and does not mention edge cases like invalid URLs or access restrictions. Given the absence of an output schema, the description is minimally viable but has clear gaps in behavioral and output 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?

The schema already provides 100% coverage by describing 'url' as 'Facebook group URL'. The description adds no extra meaning about the parameter, such as URL format or validation rules. Since schema coverage is high, the baseline is 3, and the description does not exceed that.

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 uses the specific verb 'Get' with the resource 'Facebook group details' and explicitly lists the key attributes returned (name, description, members count, privacy setting). This clearly distinguishes it from sibling tools like facebook_page_details or facebook_group_posts.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention scenarios where this tool is appropriate (e.g., retrieving metadata for a specific group) or when to prefer sibling tools like facebook_group_posts. No exclusions or alternative recommendations are 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?

With no annotations, the description carries the full behavioral disclosure burden, but it only restates the basic action. It does not disclose pagination behavior, sorting semantics, sentiment-analysis side effects, rate limits, authentication needs, or what a returned post contains.

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 a single clear sentence with no redundant wording or filler. It is well-structured and front-loaded, though it is arguably too sparse to add much value beyond the tool 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?

Given four parameters, no output schema, no annotations, and a large sibling-tool set, the description is incomplete. It does not explain return structure, pagination nuances, the optional sentiment feature, or how this differs from similar Facebook post 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?

Schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds no additional parameter meaning, but the baseline of 3 is appropriate because the schema handles parameter semantics.

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 clearly states a specific verb ('Get') and resource ('posts from a public Facebook group'). It distinguishes from page-related siblings by naming 'group', though it does not explicitly contrast with facebook_page_posts or search_facebook_posts.

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 'public' qualifier is the only usage hint, implying private groups are not accessible. There is no guidance on when to prefer this tool over facebook_page_posts, facebook_post_comments, or search_facebook_posts, and no mention of prerequisites or alternatives.

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

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

With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation via 'Get' and lists return fields, but does not explicitly mention that it has no side effects, handles invalid URLs, or requires authentication. The description adds some value but lacks explicit safety or error 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?

The description is a single sentence, immediately front-loaded with the verb and resource, and lists all relevant output fields without redundancy. Every word contributes meaning.

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 single-parameter tool with no output schema, the description adequately conveys what it does and returns. It does not mention error behavior or explicit read-only status, but given the low complexity and clear focus, it is nearly 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 coverage is 100% with a single 'url' parameter well-described in the schema (including an example). The tool description does not add extra parameter semantics beyond the schema, which is acceptable given full schema coverage. Baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get') and resource ('detailed information about a Facebook page'), listing specific fields (name, followers, categories, contact info, verification status). This distinguishes it from sibling tools like facebook_page_posts and facebook_page_photos, which target different content types.

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 provides clear context about what information this tool retrieves, making it obvious for page metadata. While it does not explicitly mention alternatives or exclusions, the field list (e.g., followers, contact info) differentiates it from content-specific siblings, so the usage intent is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, the fact that pages are billed per page, authentication needs, rate limits, or what the returned data looks like. The 'pages' parameter hints at pagination but the description itself is silent.

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 a single, clear sentence with no filler or redundancy. It front-loads the core action and resource immediately, making it easy to parse.

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 description is minimal and lacks information an agent would need for effective use: no mention of pagination implications, billing, return value shape, or relationship to page_id requirements. Even for a simple getter, a sentence about pagination or the meaning of 'pages' would meaningfully improve 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 description coverage is 100%, so the parameter descriptions already document page_id and pages clearly. The tool description itself adds no extra semantic meaning about the parameters, but this is acceptable because the schema carries that burden.

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 clearly states the operation ('Get photos') and the resource (a Facebook page). It is distinguishable from sibling tools like place_photos or search_facebook_pages because the target platform and resource type are explicit, though it does not contrast itself with any 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?

The description gives no guidance on when to use this tool versus alternatives, nor does it mention any exclusions, prerequisites, or context in which a different tool would be more appropriate. The only implied usage is the literal action 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?

No annotations are provided, so the description carries the full disclosure burden. It only says 'Get recent posts'; it does not mention pagination behavior, date filtering semantics, the optional sentiment analysis and surcharge, or what the returned data looks like. This is a meaningful transparency gap for a tool with several options.

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 one clear, front-loaded sentence with no filler words. It is efficient and immediately communicates the core function, though it leaves out contextual details that are penalized in other dimensions.

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 five parameters, no output schema, no annotations, and a large family of sibling tools, this short description is not complete enough. It does not explain the result format, pagination limits, billing/surcharge behavior, or how to choose among the many related Facebook page content 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?

The input schema has 100% description coverage, so the parameters are already well explained. The description adds only the page ID context and does not provide additional semantic detail beyond what the schema supplies, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Get') on a specific resource ('recent posts from a Facebook page') keyed by page ID. This is clear enough to distinguish it from sibling tools for page details, photos, reels, videos, and comments, though it does not explicitly name alternatives like search_facebook_posts.

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 for retrieving posts from a known Facebook page ID, but it gives no explicit when-to-use or when-not-to-use guidance. There is no mention of how this compares to search_facebook_posts or to other content-specific page tools such as facebook_page_reels or facebook_page_videos.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions the ID requirement but does not disclose that this is a read-only operation, any pagination behavior (despite a 'pages' parameter), or any response format. The description is silent on side effects, authentication, or billing beyond what is already in the schema.

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

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

The description consists of two short sentences that are front-loaded with the main purpose and followed by a necessary prerequisite. There is no redundant wording, and every word contributes to the meaning. It is appropriately concise for a simple tool.

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

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

The tool has no output schema and no annotations, so the description should explain what the response looks like or how pagination works. It does neither. While the schema explains the 'pages' parameter, the description fails to state that the tool returns a paginated list of reels, leaving the agent uncertain about the return format and usage flow.

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

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

The input schema has 100% coverage with descriptions for all three parameters. The description adds no additional parameter semantics beyond restating the requirement for reels_page_id. Since the schema fully documents the parameters, a baseline of 3 is appropriate; the description does not add value 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 clearly states the action ('Get reels') and the resource ('from a Facebook page'), making the tool's purpose immediately understandable. It distinguishes from siblings like facebook_page_posts or facebook_page_photos by naming 'reels', though it does not explicitly differentiate from facebook_page_videos, which could overlap.

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 provides a clear usage prerequisite: 'Requires the reels_page_id from the page details endpoint.' This tells the agent that it must first call the page details endpoint to obtain the ID, offering clear context on when to use this tool. However, it does not explicitly exclude alternatives or state when not to use it, so it does not reach a 5.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing—no mention of paginated results, per-page billing, the sentiment-analysis add-on, rate limits, or response shape. The only behavioral hints (billing, surcharge) live in the input schema's parameter descriptions, not in the tool description.

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 six-word sentence that is front-loaded with the verb and fully earns its place—there is no fluff or redundancy. It is efficient and clear, though the available space could have been used to pack in pagination or billing context.

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

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

With no output schema and no annotations, the description must compensate by hinting at return values and operational details, and it does neither. An agent is left to discover pagination (1-15 pages, billed per page) and the sentiment add-on only by inspecting the schema, and nothing describes what a single review record will look like.

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 (page_id, pages, get_sentiment) are already documented in the schema with types, defaults, and semantic notes. Per the baseline rule, the description need not repeat param details, and it adds no param-level meaning 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?

The description uses a specific verb ('get') and resource ('reviews') tied to a clear target ('a Facebook page'), so an agent understands exactly what data this tool returns. However, it does not differentiate itself from sibling tools that also return review-like data (e.g., place_reviews, amazon_seller_reviews, facebook_post_comments), relying entirely on the name to disambiguate.

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 is provided about when to select this tool over alternatives. With a large sibling set containing other review- and comment-oriented fetchers, the description gives no exclusions, no conditions, and no routing hints beyond the bare statement of what the tool fetches.

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

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

With no annotations provided, the description carries the full burden of exposing behavior. It only mentions the data dependency and not pagination, per-page billing, sentiment surcharge, response format, or any rate/auth constraints. Minimal but not misleading.

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 with purpose ready and the key prerequisite stated up front. No filler, but the first sentence largely repeats the tool name and valuable usage guidance is absent.

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?

Despite decent parameter descriptions, there are no annotations or output schema, and the description does not explain billing, paging behavior, sentiment add-on implications, or when to use this vs video-search/reel siblings. An agent can make a basic call but cannot fully configure or route optimally.

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?

Input schema coverage is effectively 100%: pages, get_sentiment, and delegate_page_id all have meaningful descriptions. The tool description adds little beyond restating the delegate_page_id source, so the schema does the heavy lifting and 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 clearly states the action and resource: 'Get videos from a Facebook page.' It also identifies the required input, delegate_page_id, but it does not explicitly differentiate videos from the related sibling tools like facebook_page_reels or search_facebook_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?

It provides a prerequisite—that delegate_page_id comes from the page details endpoint—but gives no guidance on when to choose this tool over search_facebook_videos, facebook_page_posts, or facebook_page_reels. No exclusions or alternative routing are 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?

The description clearly signals a read-only operation via 'Get' and describes the returned data, which is helpful given no annotations are present. However, it does not mention pagination behavior, per-page billing, or the sentiment analysis surcharge; these are documented only in the input schema, and the description itself carries the burden in the absence of 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?

The description is two sentences, front-loads the core purpose, and provides a compact list of returned fields with no filler or redundancy. Every sentence earns its place.

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

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

For a simple fetch tool, the description gives enough context about what the tool returns and what input is needed, while the schema covers detailed parameter semantics. There is no output schema, but the return-field summary is sufficient for an agent to understand the result shape; missing guidance on when to use the tool is accounted for in the usage_guidelines score.

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 input schema already explains all parameters thoroughly. The tool description adds little parameter-specific meaning beyond referring to 'post ID' and the return shape, which does not materially improve parameter understanding.

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 uses a specific verb and resource: 'Get comments on a Facebook post by post ID.' It clearly indicates the platform, the entity, and the identifying input, and the summary of returned fields reinforces the tool's function. The platform and object make it easy to distinguish from siblings like get_youtube_comments or instagram_post_comments.

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 context is only implied: the tool is clearly for Facebook post comments, and the post_id param description in the schema hints that IDs come from other Facebook post tools. However, the tool description itself gives no explicit guidance about when to prefer this tool over alternatives, and there is no mention of when not to use it.

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

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

With no annotations, the description carries full disclosure burden. It explains the tool fills in user inputs, returns an ordered recipe to execute, and tells the agent to ask the user for inputs if omitted. It doesn't elaborate on return format or execution semantics, but covers the core behavior well.

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

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

Four sentences, each serving a distinct purpose: definition, return value, usage preference, and parameter routing. The front-loaded sentence captures the essence, and the structured guidance is dense without being verbose.

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 no output schema, the description compensates by explicitly stating the return value ('ordered recipe of tool calls') and the workflow with list_skills. It prepares the agent to execute the playbook and handle unnamed skills, covering all functional 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 baseline is 3. The description adds value by giving a concrete example of inputs and skill_id, and clarifies that inputs are optional and what happens if omitted — going beyond the schema's static descriptions.

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 opens with a specific verb+resource: 'Get a ready-made skill's step-by-step playbook' and clarifies it returns an 'ordered recipe of tool calls'. This clearly distinguishes it from sibling data-fetching/search tools and positions it as a meta-tool that produces executable instructions.

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 says 'PREFER running a matching skill over improvising raw searches' and provides a decision tree: if the user names a skill, pass the skill_id directly; otherwise call list_skills first. This is textbook usage guidance with clear alternatives.

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

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

With no annotations, the description carries the full burden. It discloses a notable operational trait—billing $0.005 per page—and the limitation that only up to 5 preview replies are returned. This goes beyond a bare operation statement, though it does not discuss error cases, rate limits, or access prerequisites.

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 dense sentences with no filler. The primary action and return contents are front-loaded, and the cost caveat is placed at the end. 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?

The absence of an output schema raises the burden on the description, and it does enumerate the returned fields and reply preview limit. It also tells the agent about cost, while the schema covers paging and sort options. Missing are the top-level response shape and any failure modes, but these are 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 description coverage is 100%, so the baseline is 3 even without parameter details in the description. The description does not add new meaning for url, pages, or sort_by beyond what the schema already says; it only reinforces pagination through the per-page billing mention.

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 opens with a specific verb and resource: 'Get comments from a YouTube video.' This clearly targets comments rather than video metadata, distinguishing it from youtube_video_details and search tools, and the listed return fields (text, author, likes, replies, date, link) make the exact purpose 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 description provides clear context: use this tool when you need the comment feed of a YouTube video, including preview replies. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the wording leaves little ambiguity against sibling comment tools for other platforms.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context about the response format (paragraphs, headings, lists, images, citations) and session continuation, but it omits details about rate limits, authentication, or potential side effects. The added transparency is adequate but not comprehensive.

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

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

The description is two sentences, front-loaded with the primary action and output, followed by essential continuation guidance. Every sentence earns its place and there is zero 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?

Given the tool's moderate complexity and absence of output schema/annotations, the description covers the core input (prompt) and output structure explicitly. It also explains conversational state via session_token. Minor gaps remain, such as optional parameter behavior or error handling, but the description is largely sufficient for an agent to invoke the tool 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?

The schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already states; session_token is mentioned in both, but no new semantics (e.g., formatting, constraints) are introduced in the description.

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

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

The description states a specific verb ('Send a prompt') and resource ('Google's AI Mode') and clearly defines the output (structured conversational reply with reply_parts and reference_links). It distinguishes itself from sibling search tools by emphasizing conversational context and structured citations, leaving no ambiguity about what the tool does.

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 tool provides usage context by describing how to continue conversations via session_token, but it does not explicitly explain when to choose this tool over sibling search tools like search_web. Usage is implied rather than stated with alternatives or exclusions, so it only partially meets the bar for clear 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?

No annotations are provided, so the description carries the full burden. It goes beyond a simple one-liner by disclosing billing behavior ('Billed per page'), the empty-list edge case, the exact return fields, and the exclusivity constraint on url/code. It does not mention auth or rate limits, but it covers the key operational behaviors an agent needs.

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

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

The description is compact and front-loaded: main purpose first, then returned fields, billing, the empty-list edge case, and the input constraint. Every sentence earns its place, and there is no redundant or promotional language.

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 that there is no output schema and no annotations, the description compensates well by listing the returned fields and key behavioral notes. It could state pagination behavior more directly or mention expected errors, but the core information needed to call the tool correctly is present.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that url and code are mutually exclusive, that the comment_id must come from instagram_post_comments, and that the tool is billed per page. These are meaningful semantics not fully explicit in 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 opens with a precise verb and resource: 'Get the replies to one Instagram comment (its thread)'. It clearly distinguishes this tool from sibling instagram_post_comments by focusing on replies, and explains how the comment is identified. No ambiguity remains about what the tool returns.

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

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

The description provides clear context: it is meant to be used after instagram_post_comments, since the comment_id comes from that tool. It also explicitly states 'Provide exactly one of url or code.' It does not explicitly list when not to use the tool or name alternative tools, but the workflow context is clear enough.

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

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

With no annotations, the description carries the full burden, and it discloses important behavioral traits: billing is per page, each page yields roughly 30 posts, duplicates across pages are removed, and sort_by selects the hashtag tab. This goes well beyond a bare statement of purpose, though it does not cover error cases or rate limits.

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

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

The description is three sentences with no filler. It front-loads the core purpose, then leverages the comparison to search_instagram to avoid redundantly listing post object fields, and closes with the behavior of sort_by and pagination. Every sentence earns its place.

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

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

For a read-only paginated retrieval tool, the description covers the output shape, pagination scale, billing model, deduplication across pages, and tab selection. It is complete enough for an agent to select and invoke the tool correctly, even without an 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?

Schema description coverage is 100%, so the schema already documents every parameter clearly, including the enum options, defaults, and pagination behavior. The description adds useful context about post object fields and billing, but it does not need to compensate for missing schema documentation.

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 opens with a specific verb and resource: 'Get Instagram posts and reels for a hashtag.' It clearly differentiates itself from search_instagram by defining the returned object shape plus the hashtag total post count, so an agent can tell exactly what this tool is for.

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 should be used for hashtag-scoped post retrieval and references search_instagram as a point of comparison, but it never explicitly states when to prefer this tool over search_instagram or any other sibling. The usage context is clear enough, but exclusions and decision criteria are left to inference.

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

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

With no annotations, the description carries the disclosure burden; it names the output fields and warns that media URLs are temporary (~6-24 hours). It does not mention authentication, error behavior, or rate limits, but the important output ephemerality is covered.

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 deliver the core action, input options, output contents, and a critical caveat with no filler. Key scoping appears first.

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

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

There is no output schema, so the description compensates by enumerating the returned fields and the temporary URL caveat. Combined with a well-documented single parameter, an agent has enough to select and invoke the 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?

The schema already defines highlight_id thoroughly with valid formats and examples, so the description adds no unique parameter semantics beyond restating ID/URL support. Baseline 3 is appropriate given 100% schema 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?

The description uses a specific verb-resource pair ('Get the stories saved in one Instagram highlight') and specifies both accepted identifiers, highlight ID (from instagram_user_highlights) or URL. This clearly separates it from related story/post tools.

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 explicitly tells the agent that the ID comes from instagram_user_highlights and accepts a URL, giving a clear entry path. It does not explicitly state when to use instagram_user_stories or other alternatives, but the highlight qualifier provides enough context.

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?

There are no annotations, so the description carries the full burden. It meaningfully discloses real behavioral and cost implications: results are billed per page, limited to 15 per page, sorted by popular with pinned comments included by default or recent, and require exactly one identifier. It also previews the response fields, which is especially valuable without an output 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?

The description is compact and front-loaded with the core action, followed by output shape, pagination, sorting, cost, the sibling routing, and the critical input constraint. Every sentence adds distinct value with no fluff or repetition.

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

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

Given no output schema and no annotations, the description fully compensates: it states what data is returned, how pagination and billing work, what sorting options exist, how to get replies, and how to identify the target post. Nothing essential for a correct first call is missing.

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

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

Schema description coverage is 100%, so the baseline is already strong. The description adds meaningful semantics beyond the schema by stating 'Provide exactly one of url or code,' which resolves ambiguity in a schema with zero required parameters. It also reiterates the billing implication of pages, though most parameter details are already well documented in 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 uses a specific verb and resource: 'Get the comments on an Instagram post or reel by post URL or shortcode.' It clearly describes what is returned (text, author details, counts, date, link) and is immediately distinguishable from the sibling instagram_comment_replies and platform-specific comment tools.

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 explicitly names the alternative tool, instagram_comment_replies, and specifies its purpose: 'to fetch a comment's replies.' It also gives concrete input rules ('Provide exactly one of url or code') and states pagination/sorting expectations, so an agent knows exactly when and how to invoke 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?

The description discloses what the tool returns (caption, counts, media URLs, carousel slides, etc.) and the one-of-input constraint. With no annotations provided, the description carries the full burden; it does not mention authentication needs, rate limits, or error behavior. The 'Get' verb implies read-only, but operational aspects are not 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?

The description is three concise sentences. The first sentence front-loads the main purpose, the second enumerates key return fields, and the third provides the essential input constraint. No filler or redundant 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?

Given the tool has no output schema and no annotations, the description lists the expected return fields (caption, counts, media URLs, etc.) and the input constraint, which is sufficient for basic usage. It lacks details on error handling, rate limits, or authentication, but these are not critical for initial tool selection. The description covers the core semantics of the tool well.

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

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

The schema already fully documents all three parameters with descriptions, giving high coverage. The description adds the crucial 'Provide exactly one of url or code' semantic, which is not expressed in the schema's optionality. This clarifies the mutual exclusivity and invalidity of providing both or neither, which is valuable 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 clearly states the tool's purpose with a specific verb ('Get full details') and resource ('single Instagram post, reel, or IGTV video'), and identifies the input method (URL or shortcode). This distinguishes it from sibling tools like instagram_user_posts (multiple posts) and instagram_user_profile (user-level info).

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 clearly implies when to use the tool: when you need details for a single post by URL or code. It explicitly states the input constraint 'Provide exactly one of url or code,' which is a usage guideline for parameters. However, it does not explicitly name alternative tools or state when not to use it, so it lacks direct 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?

With no annotations provided, the description carries the full disclosure burden. It goes beyond the schema by stating the scope ('every liker Instagram exposes'), typical volume ('typically several hundred'), and that results arrive 'in a single request.' It does not discuss rate limits or authentication, but for a read-only retrieval tool the key behavioral traits 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?

Three efficient sentences cover the action, the returned data, and the input constraint. There is no filler and no repetition of schema field descriptions.

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 there is no output schema, the description sufficiently explains what the caller will receive: username, full name, user ID, verification and privacy status, profile picture, and total like count. It also resolves the one-of parameter ambiguity. Nothing essential for making the call correctly 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?

The input schema already describes url and code with 100% coverage, so the baseline is 3. The description adds the crucial mutually-exclusive rule ('Provide exactly one of url or code') and clarifies that the tool accepts both posts and reels, which is not captured by the schema's empty required list.

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 opens with a specific verb and resource: 'Get the users who liked an Instagram post or reel,' and states the two accepted input forms, URL or shortcode. It clearly distinguishes itself from sibling tools like instagram_post_comments and instagram_post_details by focusing on the list of likers.

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 intended use case is clear: call this when you need the users who liked a specific Instagram post or reel. It does not explicitly name alternatives or exclusion conditions, but the purpose is specific enough that an agent can infer when it applies and when a sibling like instagram_post_details would be more appropriate.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses pagination (50 per page), billing semantics (billed per page), query behavior (up to 50 matches, one request, pages ignored), and the fields returned. It does not mention error cases for missing/both identifiers or rate limits, but the core operational traits are transparent.

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 deliver the action, input constraints, output fields, pagination, billing note, and query alternative without repetition or fluff. The most decision-relevant information is front-loaded.

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

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

Despite lacking an output schema and annotations, the description covers the key facts needed to call the tool: input forms, output fields, pagination, billing, and the query override. Minor omissions like handling of invalid or conflicting inputs are unlikely to mislead an agent.

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

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

Schema coverage is 100% and each parameter is already well documented. The description adds meaningful semantics beyond the schema by flagging the billing implication of pages and the mutual exclusivity of username and url, which helps the agent choose the right combination of parameters.

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?

Description opens with a specific verb-resource pair: 'Get an Instagram user's followers', and clarifies the two accepted inputs (username or profile URL). It also names the returned fields, which makes the tool's scope unmistakable and distinguishes it from siblings like instagram_user_following.

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 concrete usage context: exactly one of username or url must be provided, and passing query switches the behavior to search mode with a one-request limit. It does not explicitly contrast this tool with instagram_user_following or search_instagram_users, but the within-tool guidance is clear enough for correct invocation.

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

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

With no annotations, the description carries the behavioral burden and discloses return fields, page size, billing per page, and the one-request behavior of query mode. It does not cover error cases, private account behavior, or rate limits, but it is materially transparent for normal use.

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 dense sentences front-load the action and then pack return fields, pagination, billing, and query mode without filler. Every clause contributes useful decision 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?

Even without an output schema, the description enumerates the returned per-account fields and clarifies the two input modes and billing. Remaining gaps such as private-profile errors and maximum pages are either covered by the schema or are edge behaviors rather than core invocation details.

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 adds the critical mutual-exclusion constraint ('Provide exactly one of username or url') and explains that query mode replaces pagination, which is value beyond what the schema itself 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?

The opening clause names a specific verb and resource ('Get the accounts an Instagram user follows') and the input modes. This clearly distinguishes it from the sibling instagram_user_followers, which would return the accounts that follow a user, and from search-style tools.

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 clear invocation context: use a username or profile URL to retrieve the following list, and pass query to switch to searching within that list instead. It does not explicitly say when to prefer the related followers tool or other Instagram tools, so it stops short of a full when/when-not guide.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses the operation type ('Get'/'Returns') and lists the returned fields (ID, title, story count, cover image, dates, link), which conveys read-only behavior and output shape. It does not mention edge cases like private accounts or rate limits, but for a simple read tool this is reasonably transparent.

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

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

Three short sentences with no filler. The action and input method are front-loaded, then return fields are listed, and the sibling-tool routing and the one-of constraint are stated last. Everything 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 simple two-parameter read-only tool with 100% schema coverage, the description covers what the tool does, its inputs, its output fields, and the relationship to the companion tool. No critical information needed to call it correctly is missing.

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

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

Schema coverage is 100% and already explains URL and username formats. The description adds meaningful value by specifying the mutually exclusive requirement 'exactly one of username or url,' which is not encoded as a required field in the schema. This reduces ambiguity about how to select between the two parameters.

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 uses a specific verb and resource: 'Get an Instagram user's story highlights tray by username or profile URL.' It clearly distinguishes from the sibling instagram_highlight_stories by noting that the tray is the top-level collection and referencing the sibling for stories inside a highlight.

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 exactly when to use the alternative: 'Use instagram_highlight_stories with a highlight_id to fetch the stories inside a highlight.' It also enforces an input rule with 'Provide exactly one of username or url,' making the calling contract 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?

No annotations exist, so the description carries the full transparency burden. It discloses concrete behavioral details: up to 12 posts per page, billing per page, and the exactly-one identifier requirement. It also enumerates return fields. Auth, rate limits, and ordering are not mentioned, but this is still substantial context for a read operation.

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

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

Three sentences, each earning its place: first defines the operation and target, second lists the returned data, third conveys pagination/billing/input requirements. There is no fluff or redundant repetition of the schema.

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

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

For a 4-parameter read tool with no required params and no output schema, the description provides everything needed: what it returns, how to identify the user, pagination size, cost implication, and the exclusivity rule. Nothing essential is missing.

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

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

Schema coverage is 100%, which sets a baseline of 3. The description adds value by stating the mutually exclusive relationship between url and username, a constraint not evident from the schema alone, and reinforces the page-size meaning. The get_sentiment parameter is left to the schema, which is acceptable.

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 a specific resource: a single Instagram user's recent posts and reels (their feed). It clearly distinguishes from sibling tools like instagram_user_profile, instagram_user_stories, and instagram_hashtag_posts by scoping to feed posts/reels.

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?

Delivers clear usage context: fetch a user's feed by profile URL or username, with the important constraint 'Provide exactly one of url or username.' It does not explicitly name sibling alternatives or when-not-to-use scenarios, so it stops short of the top score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the input constraint (exactly one of username or URL) and enumerates the return fields, giving a clear picture of what the tool does. It does not mention rate limits, error conditions, or authentication, but for a straightforward read operation, this level is adequate beyond what is inferred from 'Get'.

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 concise and well-structured: the first sentence declares purpose and input, the second sentence lists return fields and the required constraint. Every sentence adds value with no redundancy. It is front-loaded with the primary action and resource.

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

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

The tool is simple with only two parameters and no output schema. The description explicitly covers the return values, input constraints, and the tool's core functionality, which is sufficient. It does not delve into error handling or edge cases, but given the low complexity, the description is nearly complete. A small gap is the lack of mention of potential errors (e.g., user not found), but this is not a major omission.

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

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

The input schema already provides descriptions for both parameters, which contributes to a high schema coverage baseline of 3. The description adds the critical constraint 'Provide exactly one of username or url,' which is not expressed in the schema where both parameters are optional. This additional semantic guidance raises the score to 4.

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 clearly states the tool's function: 'Get the full profile for a single Instagram user by username or profile URL.' It lists the specific fields returned (biography, follow counts, verification, etc.), which distinguishes it from sibling tools like instagram_user_posts or search_instagram_users. This is a specific verb+resource with comprehensive scoping.

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 the tool: when you need a complete profile for a single Instagram user. It does not explicitly name alternatives or state exclusions, but the context is clear enough. The instruction 'Provide exactly one of username or url' adds operational guidance. There's no misleading information, so a 4 is appropriate.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses temporary media URLs (~6-24 hours), describes the returned story fields, and specifies the empty-list behavior for users without active stories. It does not cover rate limits or private-account errors, but the main behavioral quirks are addressed.

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 front-loaded with the core action and immediately gives the input mode. Each subsequent sentence adds non-redundant value: return fields, URL permanence, empty-list behavior, and the mutual-exclusion constraint.

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 tool with no annotations and no output schema, the description covers input selection, result content, URL lifetime, and the no-stories case. It does not mention error scenarios like invalid usernames or private accounts, but the essential calling context is present.

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

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

The schema already describes username and url; the description adds the crucial constraint 'Provide exactly one of username or url,' which the schema does not encode since no parameters are required. This meaningfully improves an agent's ability to construct a valid request.

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

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

States a specific verb and resource: 'Get an Instagram user's currently active stories' and distinguishes them from related highlight/post tools by the explicit active-stories time window. The detailed return content further confirms this tool is for stories, not profile, posts, or highlights.

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

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

The description gives clear selection context: this is for currently active stories within the last 24 hours, and an empty list means no active stories. It does not explicitly name alternative tools like instagram_highlight_stories or instagram_user_posts, but the active-stories framing makes the intended case obvious.

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

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

With no annotations, the description carries the burden of disclosing behavior. It lists the exact return fields, which is useful, but it does not disclose potential failure scenarios (e.g., invalid URL, missing data) or whether any special permissions are required. The behavior is a simple read, but edge cases are not addressed.

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 a single, front-loaded sentence that directly states the action and lists the return fields. Every word contributes to understanding, with no redundancy or unnecessary detail.

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 tool with one parameter and no output schema, the description adequately covers input (URL) and output (specific fields). It does not mention error handling or the need for prior search, but given the low complexity, the description is sufficiently 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?

The input schema already provides 100% coverage for the url parameter with a description ('LinkedIn company page URL'). The tool description merely repeats 'by URL' without adding extra meaning, such as URL format examples or constraints. Since schema fully documents the parameter, baseline 3 is appropriate.

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

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

The description explicitly states 'Get detailed information about a LinkedIn company page by URL' and enumerates the specific fields returned (name, description, employee count, etc.). This clearly distinguishes it from siblings like linkedin_company_posts (posts) and search_linkedin_companies (search).

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 clearly implies the use case: you need a LinkedIn company URL to retrieve detailed metadata. It mentions the URL requirement but does not explicitly contrast with alternatives such as search_linkedin_companies or note when not to use the tool. Context is clear, but exclusions are missing.

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?

No annotations are present, so the description carries the behavioral disclosure burden. 'Get' and 'Returns posts with engagement metrics' disclose a read-only retrieval behavior, but the description does not mention authentication, rate limits, recency bounds, or other operational traits. It is adequate for a simple read tool, but not richly transparent.

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 with no wasted words. It front-loads the core action and resource, then states the key output characteristic. Every sentence earns its place.

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

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

For a low-complexity read tool with schema-described parameters, the description is nearly complete: it states the input type (URL), the resource type (company page), and the output focus (posts with engagement metrics). It lacks an explicit note about pagination or sample output, but the schema covers pagination and the absence of an output schema makes the metrics mention sufficient.

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

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

The input schema already describes all three parameters (url, page, get_sentiment) with clear descriptions, including defaults and side effects. The tool description adds no meaningful parameter information beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Get recent posts from a LinkedIn company page by URL.' It also states what is returned (posts with engagement metrics), and the 'company page' scope distinguishes it from sibling tools like linkedin_person_posts and linkedin_company_details.

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 clear context for use: retrieving recent posts from a LinkedIn company page by URL. It does not explicitly mention alternatives or when-not-to-use, but the scope is clear enough to route an agent correctly among the LinkedIn-related sibling tools.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns a comprehensive set of fields (title, company, location, date, type, etc.), giving the agent a clear picture of the response behavior. The word 'Get' implies a read-only operation, though it does not explicitly state non-destructiveness or error conditions. Still, it provides substantial 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?

The description is a single, focused sentence that front-loads the action ('Get detailed information') followed by the resource and a concise list of returned fields. Every word adds value, with no redundant or verbose phrasing.

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?

This is a simple single-parameter read tool with no output schema and no annotations. The description fully covers what the tool does, how it is invoked (URL or ID), and what it returns (all major job attributes). For its complexity level, the description is complete and self-sufficient.

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 the url parameter already described as 'LinkedIn job URL ... or numeric job ID.' The tool description adds no new parameter semantics beyond repeating that the input can be a URL or numeric ID. This meets the baseline for parameters already well-documented in the schema, but does not elevate it.

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 uses a specific verb and resource: 'Get detailed information about a specific LinkedIn job listing.' It clearly differentiates from sibling tools like search_linkedin_jobs by focusing on a specific listing by URL or ID. It also enumerates the returned data fields, making the tool's purpose 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 description clearly implies when to use this tool: when you have a LinkedIn job URL or numeric job ID and need detailed information. It does not explicitly mention alternatives or exclusions, but the 'by URL or numeric job ID' qualifier provides clear context that this is for retrieving a single job's details, not for searching or listing jobs.

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

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

With no annotations, the description carries the full burden. It usefully discloses the output contents (engagement metrics, author info, images, videos, articles) and implies a read-only operation with 'Get', but it does not mention pagination behavior, data limits beyond what the schema states, rate limits, or visibility caveats for private posts.

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 a single, front-loaded sentence that communicates the core action, target resource, input form, and key output categories without any filler. Every part 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 tool with no output schema and no annotations, the description covers the returned data at a high level and includes core identification inputs. However, it lacks explicit usage boundaries, alternative tool routing, and behavioral caveats that would make it fully self-sufficient for an agent.

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 adds slight context by explaining the url parameter accepts a profile URL or public slug, but it does not meaningfully elaborate on page or get_sentiment beyond the schema's own descriptions.

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 action ('Get recent posts'), a clear resource ('authored by a LinkedIn person'), and the input method ('profile URL or public slug'). It also differentiates from siblings by explicitly scoping to person posts rather than company posts or post details.

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 context is implied: you need a LinkedIn profile URL or public slug, and the target is a person rather than a company. However, there is no explicit guidance about when to choose this tool over alternatives like linkedin_company_posts or search_linkedin, and no exclusions 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?

No annotations are provided, so the description carries the burden of signaling safety. The verb 'Get' and the promise to 'Return' data clearly indicate a read-only operation. It also discloses what the user will receive (post text, author details, engagement metrics), giving a transparent view of the output. It does not mention limitations like missing public posts or rate limits, but for a read operation this is adequate.

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 tight sentences front-loaded with exactly what the tool does. Every phrase adds value—'specific', 'by URL', and the list of returned data—without any redundant or filler 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?

With no output schema and no annotations, the description does a good job explaining the return value and distinguishing itself from sibling tools. It lacks explicit mention of the optional get_sentiment behavior (though that is covered in the schema) and potential edge cases like invalid URLs, but overall it is sufficiently complete for a straightforward 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%—both 'url' and 'get_sentiment' have clear descriptions in the schema. The tool description adds no new parameter-specific meaning beyond what the schema already provides, so the baseline 3 applies. The only slight addition is that 'by URL' reinforces the purpose of the url parameter.

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 clearly specifies the action ('Get detailed information') and the exact resource ('a specific LinkedIn post by URL'). It also lists the key output content (full post text, author details, engagement metrics), which distinguishes it from sibling tools that search or list posts rather than fetch details for a single post.

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 'by URL' provides clear context for when to invoke this tool: whenever you have a direct LinkedIn post URL and want its details. It does not explicitly state alternatives or exclusions, but the scope is unmistakable given the 'specific LinkedIn post by URL' wording.

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

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

With no annotations, the description carries the burden. It explains that the tool lists skills and details the return contents (id, name, category, description, inputs), plus it clarifies that the tool is a starting point and that skills are playbooks. It does not disclose potential pagination, rate limits, or error behavior, but for a simple listing tool, the behavioral transparency is strong.

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 front-loaded with 'START HERE' and clearly structured in four sentences covering purpose, usage, return value, and next step. It is somewhat verbose due to long enumerations of outcomes and use cases, but every sentence contributes value, so it earns a 4 rather than a 5.

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 description is complete for a simple tool: it explains what the tool does, when to use it, what it returns, and how to proceed (via get_skill). Since there is no output schema, the description's explicit mention of return fields adequately compensates. The guidance about common goals and playbooks adds rich context.

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

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

The schema description fully covers the only optional parameter 'category' with examples ('sales', 'recruiting', etc.), so schema coverage is 100%. The main description does not add anything about the parameter, but the baseline of 3 applies because 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 clearly states that the tool 'Lists the ready-made API Direct skills' and explicitly enumerates what it returns ('each skill's id, name, category, what it does, and its inputs'). It also distinguishes itself from siblings by positioning as the entry point and referencing get_skill for running a skill, making the purpose 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 description provides explicit when-to-use guidance: 'Whenever the user's request looks like lead-gen, competitor/brand monitoring, recruiting, due diligence, deal sourcing or market research, call this FIRST to check for a matching playbook before improvising your own searches.' It names an alternative (improvising searches) and suggests a follow-up action (get_skill), though it does not explicitly state when not to use the 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?

With no annotations, the description carries the full burden. It discloses the read-only nature ('Get'), and details the return payload including a website scrape, photos sample, owner info, and more, giving a transparent behavioral picture.

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 sentence, front-loaded with the core purpose, followed by a detailed yet relevant list of return fields. Every clause adds value and the length is justified by the tool's comprehensive nature.

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 no output schema or annotations, the description is exceptionally complete: it enumerates the return fields, mentions the website scrape, and ties the input to search_places. This is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds valuable semantics by explaining that place_id is the ChIJ... value from search_places, clarifying how agents should source this parameter. It also implies that country and language affect the returned details.

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 starts with 'Get full details for a Google Maps place by place_id', using a specific verb and resource. It clearly identifies the input (ChIJ... value from search_places) and distinguishes itself from sibling tools like place_photos and place_reviews by returning a comprehensive set of data.

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 states that place_id is the value returned by search_places, providing clear prerequisite context. It does not explicitly name alternative tools or when-not-to-use, but the 'full details' scope makes the tool's niche unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that photos and videos are returned together, that pagination works in pages of up to 10 items billed per request, and that results include URLs, coordinates, and timestamps. It stops short of discussing rate limits, authentication, or the meaning of 'type' values, but the disclosed behavior is substantial and accurate.

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

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

Three sentences, all information-dense and front-loaded. The first sentence states the primary purpose, the second details return fields and the media-type caveat, and the third explains pagination. No filler or repetition of schema 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?

Given the absence of an output schema, the description does well to mention the key returned fields (URLs, coordinates, timestamps) and clarify that the type field must be filtered client-side. It also explains pagination and billing. It could have added error conditions or examples of valid place_id, but for a read-only listing tool this is quite 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?

The input schema already provides 100% coverage for all four parameters, so the description's additional value on parameters is limited. It does reinforce the meaning of the pages parameter ('each page returns up to 10 items and is billed as one request'), but this information already exists in the schema description. Baseline 3 is appropriate when the schema is comprehensive.

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 opens with a specific verb ('Get') and resource ('photos and videos for a Google Maps place by place_id'), clearly differentiating from sibling tools like place_details or place_reviews. It also lists the main return fields (URLs, coordinates, timestamps), leaving no ambiguity about what the tool does.

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 provides clear context for use: it is keyed by place_id, returns both photos and videos together, and instructs the client to filter by type. It also explains pagination behavior with the pages parameter. However, it does not explicitly state when to use this tool versus alternative media-fetching tools (e.g., if sibling tools also return media), though this is minor given the clear scope.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses page size limits (up to 10 reviews per page), the language filtering semantics (originally written language), and the interaction between sort_by and pagination. This goes beyond the schema and gives users meaningful behavioral expectations.

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 three concise sentences, front-loaded with the primary action and place_id requirement. It packs essential details (review contents, pagination, language filtering, sort behavior) without redundancy or fluff.

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 no output schema and no annotations, the description adequately covers what reviews contain, pagination limits, and parameter behaviors. It does not mention sentiment analysis or translation, but the schema descriptions for those parameters suffice. The description is complete enough for a focused, read-only 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%, so baseline is 3. The description adds value by clarifying the language parameter with concrete examples (fr returns French reviews only) and explaining the strategic use of sort_by to surface more reviews. This enriches parameter understanding beyond the schema descriptions.

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 uses a specific verb ('Get') and resource ('user reviews for a Google Maps place by place_id'), clearly distinguishing it from sibling tools like place_details or place_photos. It immediately establishes the tool's core function and scope.

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

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

The description provides clear context for use (fetching Google Maps reviews by place_id) and gives practical guidance on combining sort_by with multiple pages to surface a larger review pool. It does not explicitly contrast with sibling tools, but this is fairly obvious given the focused purpose.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses the return fields (ASIN, title, price, rating, Prime status, etc.), pagination behavior (~16 results per page), and available filters, which gives an agent a solid behavioral model of a read-only search operation. It does not go into rate limits or data freshness, but the disclosed behavior is substantially more than minimal.

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 three tightly written sentences: what it does, what it returns, and what filters/pagination to expect. Every sentence adds value and the core action is front-loaded.

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

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

Given the tool's complexity (14 parameters, no output schema), the description covers the key contextual gaps: return fields, marketplace scope, filters, and page size. It does not enumerate every parameter, but the schema already handles that. A short mention that queries can also be ASINs would have made it fully complete, but the current level is strong.

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

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

Schema coverage is 100%, so the schema fully documents all 14 parameters. The description provides a useful high-level summary of filter categories and page size, but it does not add meaning beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource ('Search Amazon products by keyword') and adds a concrete scope ('across 24 marketplaces'). This clearly distinguishes it from sibling tools like amazon_product_details or amazon_seller_products, which target different lookup modes.

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 for keyword-based Amazon product discovery and lists filter capabilities, but it never explicitly states when to prefer this tool over alternatives like amazon_best_sellers or amazon_seller_products. There are no exclusions or when-not-to-use conditions.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It communicates keyword search and optional place scoping, but says nothing about pagination/billing behavior, date filtering, result format, ordering, or limits. For a search tool with no output schema, this is a notable gap.

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 one short sentence that front-loads the primary action ('Search Facebook events by keyword') and then adds the single most important optional modifier. Every word earns its place with no fluff.

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 5-parameter tool with no output schema and no annotations, the description covers the core query and optional location scoping but omits the date-range options, pagination semantics, and what the response looks like. It is minimally viable but not fully complete for agent decision-making.

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 five parameters. The description adds value for location_id by directing the agent to search_facebook_locations, though the schema already says the same thing, so it contributes limited new semantic meaning.

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

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

The description states a specific verb ('Search'), a clear resource ('Facebook events'), and the matching criterion ('by keyword'). It also distinguishes itself from sibling Facebook search tools (pages, posts, videos, locations) by naming 'events' and by pointing to the companion location tool for place-scoped searches.

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 gives clear invocation context: search by keyword, and optionally scope to a place using location_id resolved via search_facebook_locations. It doesn't explicitly state when not to use this tool or contrast it with other facebbook search siblings, but the event-specific resource and location resolution guidance make the intended usage clear.

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?

No annotations exist, so the description is the only behavioral disclosure. It explains the output's purpose but does not mention handling of ambiguous names, multiple matching locations, no-result cases, or exact return format—important gaps for a resolver.

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, purpose first, every word earns its place. It is brief and highly scannable.

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 resolver, the description fully covers purpose, input scope, and output usage via downstream tool references. No output schema is needed when the description points to the exact consumers.

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 already defines 'query' with a description and max length. The description adds semantic narrowing by specifying accepted entity types (city, region, country), which is extra value 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 uses a specific verb 'Resolve' and clearly states the resource (place name to Facebook location IDs). It distinguishes this from sibling content-search tools by framing it as a preparatory lookup step.

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

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

Explicitly tells when to use the tool (to obtain a location ID for scoping searches) and names two direct consumer tools (search_facebook_posts, search_facebook_events). This provides clear integration context and implicitly contrasts with alternative search tools.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search Facebook pages by keyword' and does not mention result shape, pagination behavior, rate limits, or scope limitations like public pages only. This is a minimal statement rather than a transparent behavioral 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?

The description is a single sentence with no filler and the core action is front-loaded. It is structurally efficient, though slightly under-specified for the broader selection context; still, this is a genuine conciseness strength rather than a verbosity problem.

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

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

With no output schema and no annotations, the description is the only behavioral context available. It omits what returned page results look like, how results are ordered, and when this search should be preferred over neighboring Facebook search tools. This is too thin for confident tool selection among many 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 the parameters are already documented and the baseline is 3. The description's 'by keyword' vaguely maps to the query parameter but adds no new information about pages, pagination, or billing. It neither improves nor harms parameter understanding.

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 clearly identifies the action: search Facebook pages by keyword. It is unambiguous about the resource type, but it does not differentiate this tool from siblings like search_facebook_posts, search_facebook_videos, or search_facebook_events, so an agent may need extra inference to pick the right one.

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 about when to use this tool versus alternatives such as search_facebook_posts, facebook_page_details, or search_facebook_locations. The description only restates the operation and provides no context, exclusions, or routing hints.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly discloses the all-of-Facebook scope and the optional location filter, but it omits pagination behavior, per-page billing, and the sentiment-analysis surcharge, leaving those important operational traits only in the schema.

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

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

Two terse sentences with no extraneous words. The primary action is front-loaded, and the optional location guidance is appended without diluting the core message.

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 schema fully documents all seven parameters, and the description adds the essential global scope and location-resolution context. The missing output schema and absent annotations leave minor ambiguity about result format, but the tool is straightforward enough that this is not a significant 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 the baseline is 3. The description adds real value by instructing the agent to resolve location_id via search_facebook_locations, which is a meaningful cross-tool usage hint beyond what the schema says.

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 opens with a specific verb and resource, 'Search Facebook posts by keyword across all of Facebook,' making the tool's core purpose immediately clear. It also distinctly separates this from sibling tools like search_facebook_pages or facebook_page_posts by emphasizing the global 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?

It provides explicit guidance for the optional location scoping, including a direct pointer to search_facebook_locations to resolve the location_id. However, it stops short of explicitly explaining when not to use this tool or naming alternatives for page- or group-specific post retrieval.

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?

No annotations exist, so the description carries the full burden of behavioral disclosure, yet it discloses nothing about pagination, billing, or result limits. The pages and get_sentiment parameter descriptions mention per-page billing and the sentiment surcharge, but the tool-level description itself contributes no behavioral context for an agent evaluating cost or side effects.

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

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

The description is a single six-word sentence that is front-loaded and free of filler. It is genuinely concise, though the brevity is the flip side of the missing usage and behavioral guidance penalized elsewhere.

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 tool with 6 parameters, per-page billing, an AI-sentiment surcharge, and multiple Facebook sibling tools to distinguish from, a six-word description is not complete context. With no annotations and no output schema, the agent is left unable to judge cost, result scope, or when to select this tool over facebook_page_videos.

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 the 500-character query cap, page range 1-15, sort enum, date filters, and the sentiment-analysis surcharge. The description adds no parameter-level meaning beyond echoing 'keyword,' which is already obvious from 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?

The description states a clear verb ('Search'), a specific resource ('Facebook videos'), and a method ('by keyword'), so an agent can grasp the core operation instantly. However, it does not differentiate this tool from the sibling facebook_page_videos, which also concerns Facebook videos — the scoping distinction (site-wide keyword search vs. per-page listing) is left implicit.

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

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

No guidance is given on when to use this tool versus alternatives such as facebook_page_videos, search_facebook_posts, or search_facebook_events. An agent facing several Facebook search/list siblings gets no decision rule beyond the name-to-resource match, which is not enough to route correctly.

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

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

With no annotations, the description carries the burden of disclosing behavior, but it only says 'Search forum posts across the web.' It does not mention result formatting, pagination behavior, the country/time filtering effect, or the get_sentiment surcharge described in the schema.

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

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

The description is a single front-loaded sentence with no filler or redundancy. It is concise, though it may be too sparse for a tool with five parameters and no annotations.

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 five parameters, no annotations, no output schema, and a broad sibling family, a one-line description is not complete enough. It lacks usage context, edge-behavior notes, and any indication of what distinguishes forum search from other web/social searches.

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 five parameters. The description adds no parameter meaning beyond the schema, which is acceptable but not additive.

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 action ('Search') and resource ('forum posts') with a scope ('across the web'), so an agent can understand the basic function. It does not differentiate from closely related siblings like search_reddit or search_web, so it misses the distinction test.

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 exclusions, and no mention of alternative tools. Among many sibling search tools, an agent gets no help deciding between search_forums and search_reddit, search_web, or search_news.

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?

No annotations are available, so the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention pagination behavior, result format, rate limits, or the sentiment analysis surcharge feature exposed in the schema.

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

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

A single, front-loaded sentence with no filler. Every word adds meaning, and the core action is immediately clear.

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 has moderate complexity with three params and no output schema or annotations. The description covers the basic purpose but omits behavioral context, usage guidance, and expected output details, leaving an agent to infer important invocation context.

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 parameters are already well documented. The description adds no parameter-level meaning, but it doesn't need to because the schema carries the detail.

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

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

The description names a specific verb ('Search'), resource ('Instagram posts'), and method ('by keyword'). It distinguishes the tool from search_instagram_users, but doesn't differentiate it from related post-level Instagram tools like instagram_hashtag_posts.

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

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

No when-to-use or when-not-to-use guidance is provided. With many sibling search tools, the description does not explain when to choose this over alternatives like search_instagram_users, instagram_hashtag_posts, or instagram_post_details.

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

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

With no annotations, the description must disclose behavioral traits. It only lists return fields and does not mention pagination, result limits, sorting, or read-only nature. For a search endpoint, this leaves important behavior unspecified.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys purpose and output 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?

For a simple one-parameter search tool, the description is mostly complete: it states what it searches, the input, and what is returned. It could be improved by clarifying whether results are a list, but the lack of output schema makes the listed fields helpful enough.

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

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

The schema covers the single parameter query with 'Search keyword (max 500 characters)' and the description simply repeats 'by keyword'. No additional semantic value is added 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 clearly states the action ('Search Instagram users') with a specific resource and modifier ('by keyword'), and lists the returned fields. This distinguishes it from broader search tools like search_instagram.

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 is provided on when to use this tool versus alternatives such as search_instagram or instagram_user_profile. The description gives no context for choosing it over sibling search tools.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the return payload (post content, engagement metrics, attached media, has_content_entities repost flag, optional AI sentiment) and mentions a per-page surcharge for sentiment. It does not address rate limits, pagination behavior beyond what the schema offers, or the discrepancy around the 'author' filter.

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 compact and front-loaded, opening with the main purpose before explaining filters and return data. The filter list is packed with parenthetical explanations, making it dense but not bloated. The organization is logical, though the erroneous 'author' filter makes the otherwise crisp structure slightly misleading.

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 description covers the core operation, available filters, and return fields, which is fairly complete for a search tool. It lacks explicit mention of the sort_by and page parameters, does not explain that query is optional when a filter is provided, and omits guidance on how the 'author' item relates to the schema. Overall it is adequate but has noticeable 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 does add useful clarification, such as 'from_company (posts by a company page id)' and 'mentions_company (posts that MENTION)'. However, it also names an 'author' filter that is not present as an input parameter, which reduces trust and adds ambiguity rather than pure value.

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 opens with a specific verb and resource: 'Search LinkedIn posts.' It further clarifies scope by listing several distinct filters, which helps distinguish this from company/person/comment tools. However, it references an 'author' filter that does not appear in the input schema, creating some confusion about the exact tool surface.

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 the tool by saying to provide a query and/or a filter, and the filter list suggests it is for post-level search. It does not explicitly distinguish this from related siblings like linkedin_company_posts or linkedin_person_posts, nor does it state when not to use this tool. Usage guidance is present but mostly implicit.

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

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

With no annotations, the description must carry the full behavioral disclosure burden. It mentions return fields (name, description, followers, logo) but omits key behavioral traits such as whether the operation is read-only, authentication requirements, rate limits, or pagination specifics beyond the schema. The word 'search' implies read-only, but no explicit safety guarantees are provided.

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 concise yet informative sentences. It front-loads the action and return summary without any filler or redundant details, making it easy for an agent to parse quickly.

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-param search tool, the description is minimally adequate: it states what is searched, how (by keyword), and what is returned. However, it lacks usage guidance and behavioral transparency, which leaves gaps in selection confidence and invocation safety. No output schema exists, so the return field enumeration is helpful but not comprehensive.

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 both params (query and page) already well-documented in the input schema. The description adds minimal value for parameter understanding, only indirectly reinforcing the role of 'query' as a keyword. Baseline 3 applies due to complete schema 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?

The description uses a specific verb ('Search') and resource ('LinkedIn companies'), with the keyword-based scope clearly stated. It is easily distinguished from sibling tools like search_linkedin (general) and search_linkedin_jobs (jobs), and its functionality 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 description implies usage for keyword-based company searches but provides no explicit guidance on when to prefer this tool over alternatives like search_linkedin or linkedin_company_details. No when-not-to-use conditions or alternative suggestions 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?

With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool returns and that it supports filters, which is useful, but it does not mention pagination behavior, rate limits, authentication requirements, or how the 25-per-page limit behaves. The description is accurate but leaves some operational behavior undisclosed.

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 with no filler: the primary action is front-loaded, followed by return fields and filter capabilities, then a use-case signal. Every clause adds value without repetition or bloat.

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

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

The description covers the main return fields, filter dimensions, and a practical use case, which is strong given that all parameters are fully documented in the schema. It does omit pagination details and the relationship with companion tools like linkedin_job_details or search_linkedin_companies, but the schema and sibling names partially compensate. Overall it is nearly complete for an agent selecting this 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%, so the schema already documents all parameter meanings and defaults. The description adds context by grouping filter types and by tying the tool to hiring/expansion/funding signals, but it does not add parameter-level detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches LinkedIn job listings by keyword, naming the specific resource and primary action. It lists return fields and filters, which makes its function obvious. It does not explicitly contrast with sibling tools like linkedin_job_details or search_linkedin_companies, so it falls short of full sibling differentiation.

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

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

The description implies when to use the tool: for job searches by keyword with filtering and for hiring/expansion/funding signals. It does not explicitly state when not to use it or mention alternatives such as linkedin_job_details for retrieving a specific job's details. The context is present but not fully articulated.

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?

Since no annotations are provided, the description carries the full burden. It only states what is searched, but doesn't disclose any behavior beyond that, such as how results are returned, whether filters apply by default, or any limitations like rate limits or source diversity.

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 a single sentence, front-loaded with the verb, and contains no extraneous information. It is appropriately sized for a straightforward search tool.

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

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

The description is minimal but sufficient for a simple search tool. It could benefit from mentioning the type of results returned or that filters exist, but the schema compensates by documenting all parameters. Given no output schema or annotations, a bit more context would be ideal, but it remains acceptable.

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

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

Schema description coverage is 100% with each parameter having its own description. The tool description adds no parameter-specific meaning, so the baseline of 3 applies. It doesn't hinder understanding, but also doesn't provide any extra semantic clarity.

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 clearly states the tool's purpose with a specific verb and resource: 'Search news articles'. This distinguishes it from siblings like search_web or search_reddit, but doesn't explicitly name alternatives. The addition of 'thousands of sources worldwide' adds scope.

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

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

No usage guidance is provided. The description doesn't explain when to choose this tool over other search tools, nor does it offer any alternatives or exclusions. The agent gets no help in deciding between search_news and search_web for a query.

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

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

With no annotations, the description carries the full transparency burden. It discloses pagination behavior ('Each page returns up to 10 results'), optional geographic biasing, and the return data fields. This is solid coverage for a read-only search tool, though it omits details like rate limits or failure modes.

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

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

The description is exactly three sentences, front-loaded with the tool's purpose, and every sentence adds value. It lists return fields, notes geographic biasing, and states pagination in a compact, readable format.

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 has 7 parameters and no output schema, so the description must compensate. It lists the key return fields, explains the optional bias mechanism, and notes page size. It does not cover edge cases or limits, but for a search tool this is adequate context.

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

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

The schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds a modest group-level semantic for lat/lng/zoom ('bias results by geographic center') and reiterates pagination, but does not introduce meaning 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 clearly states the tool searches Google Maps places (local businesses, points of interest) via free-text query, and enumerates the return fields. This specific verb-resource-scope pairing distinguishes it from sibling tools like search_web or place_details.

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 for finding places on Google Maps, and the geographic bias option gives a clear use case. It does not explicitly mention alternatives or exclusions, but the context is strong enough that an agent would know when to invoke it.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Search Reddit posts.' It does not mention pagination limits, sort behavior, the sentiment analysis option, rate limits, or what fields are returned, so an agent gets minimal insight into the tool's actual behavior.

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

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

The description is very short and free of filler, with the core purpose front-loaded. While it could include more useful context, as a concise statement it is well-structured and immediately scannable.

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 has no annotations and no output schema, so the description should provide more context about what the agent can expect from the result and any important limitations. 'Search Reddit posts' alone is too thin to be considered complete for a search tool with pagination, sorting, and optional sentiment analysis.

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 each parameter already has a meaningful description. The tool description adds no extra parameter context, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Search') and a specific resource ('Reddit posts'), which clearly distinguishes it from sibling tools like search_reddit_comments and search_reddit_users. It adds value beyond the tool name by narrowing the resource to posts.

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 provides no explicit guidance on when to use this tool vs. alternatives. It does not mention search_reddit_comments, search_reddit_users, or any exclusions, leaving the agent to infer usage purely from the name and siblings.

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

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

With no annotations, the description must disclose behavioral traits itself, but it only repeats the operation. It does not mention output format, pagination behavior, rate limits, search semantics, or nuances of the get_sentiment option. The schema documents parameters but not behavior, so the agent gets no beyond-schema transparency.

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 entire description is one short, front-loaded sentence with no filler or repetition. It is appropriately concise for a straightforward search tool, though it could have added context without becoming bloated.

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 has 4 parameters, no output schema, and no annotations, meaning the description is the main source of context beyond the schema. A single statement of purpose does not cover expected return data, sorting/pagination behavior, or how to choose between sibling search tools, so the definition is incomplete for correct invocation.

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

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

Schema coverage is 100%; every parameter (query, pages, sort_by, get_sentiment) has a descriptive schema entry with defaults and constraints. The description adds no parameter information, but the baseline of 3 applies because the schema already 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?

The description states a clear verb and resource: 'Search Reddit comments.' It identifies the tool's function and, by naming comments rather than users or general Reddit content, hints at a distinction from siblings like search_reddit_users and search_reddit. However, it gives no scope details or contrasts, so it is clear but not fully differentiating.

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 is provided about when to choose this tool over alternatives such as search_reddit, search_reddit_users, or search_forums. There are no conditions, exclusions, or mention of complementary tools, leaving the agent to infer usage solely 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?

With no annotations provided, the description carries the full burden of disclosure. It states that profile data is returned (username, karma, account age, bio), but does not mention whether this is a read-only operation, rate limits, pagination, or any side effects. For a simple search tool, the basic return info is useful but not 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?

Two short sentences, front-loaded with the main purpose. No filler or redundancy; every word adds value.

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 one-parameter search tool, the description is fairly complete: it states the action, the target resource, and the returned fields. However, it lacks mentions of result limits, sorting, or potential ambiguity (singular vs. plural profiles), which would improve 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?

Input schema has 100% coverage: the 'query' parameter is described as 'Search keyword (max 500 characters)'. The description's 'by keyword' adds little beyond the schema. Baseline 3 applies because schema adequately documents the parameter.

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?

Description clearly states the action ('Search Reddit users by keyword') and the resource ('Reddit users'). It distinguishes from siblings like 'search_reddit' (posts) and 'search_reddit_comments' by specifically targeting user profiles, and lists return fields (username, karma, account age, bio) for additional clarity.

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 tool vs alternatives (e.g., search_reddit for posts, search_reddit_comments for comments). The description implies usage for finding Reddit users but does not mention any conditions, exclusions, or preferred scenarios.

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

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

With no annotations, the description carries the full burden. It discloses the cost per request ('Billed $0.006 per request') and outlines the response contents, which is valuable behavioral context. It also mentions the optional sentiment analysis and its surcharge. It does not explicitly state read-only status or rate limits, but the 'Search' verb implies non-destructive behavior.

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

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

The description is concise: two sentences that front-load the purpose and return types, then add cost information. Every word earns its place, and there is no redundant filler.

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

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

With no output schema, the description adequately conveys the key return fields (text, author, engagement metrics, media, permalinks) and the optional sentiment enhancement. It covers cost and the optional parameter, but does not mention pagination, sorting, or date filters, which might be expected for a search tool. Overall, it is sufficient for basic usage understanding.

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

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

The schema itself documents both parameters with full coverage (100%), so the description does not need to repeat parameter details. It adds marginal context by mentioning the sentiment surcharge, but does not elaborate on parameter syntax or formats beyond the schema. Baseline 3 is appropriate when the schema handles semantics.

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 clearly states the tool's purpose: 'Search Threads (Meta's Threads app) posts by keyword' and lists the specific types of returned data (text, author, engagement metrics, media, permalinks). This distinguishes it from sibling tools like search_threads_users, which focuses on users rather than posts.

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 explicit context for when to use the tool: when you need to search Threads posts by keyword. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent can infer when to use it. A higher score would require naming alternate tools or scenarios to avoid.

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?

No annotations are provided, so the description must carry the burden. It discloses the return fields (username, full name, verification status, profile picture) and the per-request cost, but it does not mention result limits, pagination, or rate limits. These omissions leave some behavioral uncertainty.

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, front-loaded with the tool's purpose. The first sentence states the action and resource, and the second adds valuable return fields and pricing. No wasted 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?

For a simple one-parameter tool with no output schema, the description adequately covers purpose, return fields, and cost. It could be more complete by specifying result count or pagination, but these are not critical for a basic search operation.

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

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

The schema already fully describes the only parameter ('query' with max 500 characters), achieving 100% coverage. The description adds no additional semantic detail beyond the schema, 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?

The description uses a specific verb ('Search') and resource ('Threads users'), clarifying that it searches user profiles on Meta's Threads app. This distinguishes it from sibling tools like search_threads (likely posts) and other user search tools.

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 clearly indicates this tool is for keyword-based user search, which implies usage context. However, it does not explicitly state when not to use it or mention alternatives like threads_user_profile for exact-username lookups.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action and does not mention pagination, sorting, region filtering, or the sentiment analysis surcharge, all of which are relevant behavioral traits.

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

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

The description is a single sentence with no filler or redundant phrasing, making it concise and front-loaded with the essential 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?

Despite the schema covering parameters, the description provides no information about return format, pagination limits, or the sentiment surcharge. With no output schema and moderate complexity, the description is not complete enough for full agent understanding.

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 adds little beyond the schema, only implicitly mapping 'keyword' to the query parameter, but it does not clarify any additional parameter semantics.

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 uses a specific verb 'search' with a clear resource 'TikTok videos' and qualifier 'by keyword', making it obvious what the tool does and distinguishing it from sibling tools like search_tiktok_users and tiktok_video_details.

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 for keyword-based TikTok video search but provides no explicit when-to-use or alternative guidance. It does not mention alternatives like search_instagram or search_twitter for other platforms, leaving the agent to infer context from the tool 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?

With no annotations provided, the description must carry the full behavioral burden. It discloses the return fields and the search-by-keyword behavior, which is useful. However, it does not mention pagination behavior (though the pages parameter exists in schema), rate limits, or authentication requirements. The read-only nature is implied by 'search' but not explicitly stated.

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 consists of two short sentences that front-load the purpose and return information. There is no redundant or extraneous content, making it highly concise and well-structured.

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