agdata

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

Annotations already declare readOnly/openWorld/non-idempotent. The description adds valuable non-obvious behavior: each product is 'filled in from its product page' (i.e., an extra fetch per item) and the cap of 20 per call. It does not mention rate limits or latency, but the enrichment cost is disclosed.

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

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

Front-loaded with the core action, then limits, then the returned field list. Dense but every clause carries information; the field enumeration is long but justified given no output schema.

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

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

With no output schema, the description usefully enumerates the normalized product fields and notes per-item page enrichment. Minor gaps remain (e.g., no note on failure/empty results or language/store caveats), but it is sufficient to invoke correctly.

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

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

Schema coverage is 100% and the schema itself documents limit clamping (larger lowered to 20, 0/negative → default) and the query example. The description only restates 'Body: {query, limit}', adding nothing beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Keyword search on Amazon.com (US store)', with per-call limits. This clearly distinguishes it from the amazon-reviews sibling and other search siblings.

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

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

'Good for price checks and product comparison' gives concrete usage context, and the store scoping (US) implicitly rules out other locales. No explicit when-not or named alternative, but the intended use case 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?

Annotations already cover the read-only, non-destructive, open-world profile, and the description adds genuinely new behavioral facts: the 50-review ceiling, that reviewer names and photos are omitted, and that a product with no reviews is not charged. The billing/charging behavior is especially useful given idempotentHint=false, though the cost model itself is only hinted at.

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 pair that leads with the core action and payload, then packs sort/filter/marketplace options and exclusions without redundancy. Every clause carries information an agent needs.

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

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

With no output schema, the description compensates by enumerating returned fields (rating, title, text, date, verified flag, helpful votes) and explicitly noting what is not returned. Combined with billing and filtering behavior, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all five parameters are already fully documented in the schema, including the URL-sets-marketplace rule and the 1-50 clamping behavior. The description only restates the high-level capability (sort, star filter, marketplaces) without adding syntax or edge-case meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('send an ASIN or an Amazon product URL and get up to 50 customer reviews as JSON') and enumerates the returned fields. It is unambiguously distinguishable from sibling review tools like google-maps-reviews or youtube-comments, which target other platforms.

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 clear: use it to fetch customer reviews for an Amazon product, with sort/filter/marketplace options spelled out. There is no explicit when-not or named alternative, though among the siblings none competes for Amazon review data, so the gap is minor.

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?

Beyond the read-only and non-destructive annotations, the description discloses the per-website stablecoin pricing model, refunds for sites with no contacts found, and the supported payment networks (Base or Polygon, not Solana). It also specifies that the output is JSON including the contact page found, which is meaningful 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 three tightly structured sentences: purpose and return data first, pricing/refunds second, and payment-network restriction last. Every sentence adds useful information, and there is no filler or repetition.

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

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

For a one-parameter tool with no output schema, the description covers what is returned, the per-website cost, refund behavior, and payment-network constraints. It does not explain how payment is actually authorized or what error states look like, leaving a small but real gap for a paid 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 has 100% coverage for the single `urls` parameter, including the 1-to-5 limit and domain-or-URL format. The description reinforces the batch size and per-site pricing but adds no new syntactic or semantic 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 states a specific verb and resource: it sends websites and returns emails, phones, and social links from home, contact, and about pages. The purpose is clear and inherently distinct from siblings like email-verify or maps-contacts, but the description does not explicitly route the agent away from any sibling tool.

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

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

Usage is implied by the clear 'website contact finder' framing and the 1-to-5 website limit, but there is no explicit when-to-use guidance versus alternatives such as maps-contacts, email-verify, or web-search. Payment and network constraints add context, yet they do not tell the agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond those: privacy limits ('no seller names or thumbnails') and a billing rule ('a search with no results is not charged'), which are genuinely useful for an agent deciding to call it.

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

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

Purpose is front-loaded in the opening clause, and the field list, marketplace scope and billing note all earn their place. It is dense with colons and semicolons but not padded with 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 compensates by listing the returned fields, and it covers scope, privacy and billing. Minor gaps remain (no pagination behavior beyond the limit param), but for a read-only search tool it is essentially complete.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters fully. The description's mention of 'Eight eBay marketplaces, last 1 to 90 days, new or used' merely restates the site, days and condition constraints already in the schema, adding little new meaning. Baseline 3 applies.

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

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

The description gives a specific verb and resource: 'send a keyword, get sold items as JSON for resale comps.' It also enumerates the returned fields (sold price, currency, shipping, total, sale date, condition, listing type, bids, seller feedback), so an agent knows exactly what it produces. The eBay-sold scope cleanly separates it from the sibling 'amazon' and other listing 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?

'for resale comps' implies the intended use case, giving some context on when to reach for it. However, it never names an alternative or states when NOT to use it versus comparable siblings like 'amazon' or 'shopify-products.' Usage is implied rather than explicitly guided.

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

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

Goes well beyond the annotations by disclosing the payment model (pay per address in stablecoins), the refund rule for addresses with no verdict, the supported chains, and the important interpretive rule that catch-all and strict servers are never reported as valid. These are non-obvious behaviors an agent could not infer from readOnlyHint/destructiveHint.

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

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

The core capability is front-loaded and the remaining sentences are dense with operational facts (returned fields, risk semantics, payment, refunds, chains). Only the 'for AI agents' phrase is filler; otherwise no wasted text despite the length.

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

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

With no output schema, the description carries the return-value burden itself by listing verdict fields (status, score, domain/mail-server existence, disposable, role-based, free-provider, catch-all, typo suggestion). Combined with payment, refund and chain details, an agent can call this correctly without further information.

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

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

Schema coverage is 100% and the single parameter already documents the 1–20 range, duplicate handling and per-address pricing. The description restates the 20-address cap and pricing but adds no syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Email verification API ... send up to 20 email addresses and get a verdict for each') and enumerates the returned fields, so an agent knows exactly what it gets back. Nothing in the sibling list does address verification, so the tool is unambiguous.

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

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

The context is clear: batch-verify up to 20 addresses before using them. It also states the network constraint (Base or Polygon, not Solana) which is a real precondition. It never explicitly says when not to use it or names an alternative, but no sibling overlaps, so the gap is minor.

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?

Beyond the read-only and open-world annotations, the description discloses the per-call maximum, that commenter names and handles are omitted, and the pay-per-call stablecoin/refund model. It still does not cover pagination, ordering, or deeper access constraints, but it adds 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 compact and front-loaded around the core action, then adds only high-value details: returned fields, limits, privacy behavior, and payment terms. Every sentence earns its place.

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

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

With no output schema, the description usefully lists the returned comment fields and states that commenter identities are excluded. It is mostly complete for invoking the tool, though it could say more about pagination, ordering, or whether more than 100 comments are retrievable across calls.

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

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

Schema description coverage is 100%, so both the url and limit parameters are already documented in detail. The description repeats that it accepts public post/video/reel URLs and mentions the 100-comment cap, but adds little parameter semantics 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 states a specific verb and resource: fetching comments for a public Facebook post, video, or reel URL. It clearly distinguishes this from Facebook content-fetching siblings such as facebook-posts or facebook-page by focusing on 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?

The use case is strongly implied—send a public Facebook URL to get its comments—but the description does not explicitly say when to use this instead of facebook-posts, facebook-page, or other comment tools. No exclusions or alternative-routing guidance 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?

Annotations already cover read-only, non-destructive, open-world behavior. The description adds important unannotated behavior: pay-per-call in stablecoins and no charge for private, unknown, or non-page inputs. It does not detail auth or rate limits, but those are less central for this lookup.

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 compact sentences with the return fields and cost policy front-loaded. There is little waste; even the pricing and failure-policy 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, but the description enumerates the returned fields and JSON format. Together with the fully described single input parameter and the annotations covering safety/open-world behavior, this is enough 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 single url parameter is fully described by the schema, including an example and the exclusion of profiles/groups. The description reinforces that the URL must be a public Facebook page and that only one page is processed per call, but adds no new syntax or format details beyond the schema, so the 100% coverage baseline of 3 applies.

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

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

States a specific action (send the URL of a public Facebook page) and a specific result (public page details as JSON, including name, category, followers, intro, website, and contact fields). The resource is clearly page details rather than posts/comments, and the scope excludes private/unknown/non-page inputs.

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 clear usage context: one public Facebook page URL per call, returning page details. It also states private, unknown, or non-page inputs are not charged, which helps avoid misuse, but it does not explicitly route agents to facebook-posts or facebook-comments 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?

Annotations already declare readOnly/openWorld/non-idempotent, and the description adds genuinely new behavior: a hard cap of 20 posts per call, per-post stablecoin billing, no charge for pages with no readable posts, and refunds for paid-but-undelivered posts. Those commercial and failure-mode details are exactly what an agent needs before spending.

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

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

One front-loaded sentence covers input, output, and limits, followed by a short billing/refund sentence. Every clause carries actionable information, with no filler or restatement of the title.

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

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

With no output schema, the description compensates by listing the exact return fields (text, time, reaction/comment/share counts, video views, reaction breakdown) plus cost behavior. Nothing an agent needs to invoke 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%, so both `url` and `limit` are fully documented with examples, defaults, and clamping rules. The description only echoes the 20-post ceiling ('Up to 20 posts per call') and adds no new parameter semantics, so the baseline 3 applies.

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

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

States a concrete verb and resource ('send the URL of a public Facebook page and get its most recent posts') and enumerates the returned fields, so an agent can distinguish it from facebook-comments or facebook-page without reading a schema.

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

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

The scope is clear: the input must be a public Facebook page URL, and it returns recent posts rather than profile metadata or comments. It never names a sibling alternative or states when not to use it (e.g., private pages, comment retrieval), so it falls short of a 5.

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

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

Annotations already declare non-destructive write, non-idempotent, closed-world behavior. The description adds valuable context beyond annotations: rate limiting (a few messages an hour), human review, no payment/account, and a privacy hint in the schema. It does not contradict 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?

Short, front-loaded, and every sentence adds value. 'Free' immediately sets cost context, followed by purpose, review process, and constraints—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?

Given a simple form with four parameters (one required) and no output schema, the description covers what the tool does, cost, rate limit, human review, and privacy guidance. Minor gaps: it does not describe a confirmation or return behavior, but that is less critical here.

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

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

Schema coverage is 75% with explicit descriptions for route, contact, and message. The description's phrasing 'a bug, an idea or a thanks' loosely maps to the kind enum, but it does not add meaning beyond what the schema provides 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?

States a specific verb and resource: send feedback to the people who run the service. The examples (bug, idea, thanks) clarify scope, and it is trivially distinguished from all sibling tools, which are data-retrieval 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?

Clear context for when to use it: to report what worked, failed, or is missing. It adds constraints (limited to a few messages an hour, no account) but does not explicitly state when not to use it or name alternatives, though no feedback alternative exists.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: an explicit cap of 20 places per call and a full list of returned fields, which tells the agent what a call yields.

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 purpose and scoping are front-loaded in the first sentence, the example is compact, and the return-field list and use cases follow in an efficient order. No sentence is wasted, though the field enumeration is dense.

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

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

With no output schema, the description correctly compensates by enumerating the return fields, and it covers parameters and use cases. It is essentially complete for a read-only search tool, with only pagination behavior beyond the per-call cap left implicit.

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

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

Schema description coverage is 100%, so query, location and limit are all documented in the schema (including the 1-20 clamp and default). The description restates the 20-place cap and shows an example invocation but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: search Google Maps places for a term, optionally narrowed to an area, with a concrete example. It clearly conveys discovery of local businesses, but does not explicitly distinguish itself from the sibling google-maps-reviews, even though it lists totalScore and reviewsCount as fields.

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 offers concrete use cases (local lead lists, store/competitor mapping, checking hours or phone) which implies when to use it, but provides no when-not guidance or named alternatives such as google-maps-reviews for review data.

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

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

Annotations already cover safety (readOnly, non-destructive, open-world), and the description adds substantial extra context: the 50-review cap, fields included vs deliberately omitted (reviewer names, profiles, photos), and billing behavior (unfetched/no-review requests not charged, paid-but-missing reviews refunded). This goes well beyond what annotations provide.

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

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

Front-loads the core action and output shape before billing detail, with no truly redundant sentences. The opening 'for AI agents' framing is mild filler and the sentence is long, but each remaining clause carries information an agent needs.

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

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

With no output schema, the description carries the burden of describing returns and does so fully: star ratings, text and translation, date, likes, owner reply, plus place name/address/rating, and it flags excluded data. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% and the parameter docs are rich (place_id format, limit clamping, language enum). The description only restates the sort options and the 50 cap, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (fetch Google Maps reviews for a place) plus the input forms (place_id or Maps URL) and sort options. It is clearly separable from siblings like google-maps (place lookup) and amazon-reviews (different source).

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 via the input formats and sort values, and notes the no-review/refund billing case, but never states when to choose this tool over siblings such as google-maps or when it is inappropriate. Context is implied rather than explicit.

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

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

Annotations already declare readOnly, openWorld, non-idempotent and non-destructive characteristics, so the safety profile is covered. The description adds genuinely new behavioral context: a result cap of 30, the shape of returned records, and a billing/refund note about paid-but-unreturned articles, which is information no annotation supplies.

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

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

The core capability and return payload are front-loaded, followed by the edition note and refund clause. It is dense but every clause carries information; slightly compressed prose keeps it from 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?

With no output schema, the description compensates by naming the returned fields, and the annotations cover the safety profile. The only minor gap is absence of guidance on pagination or result freshness relative to sibling search tools, but nothing needed to call the tool 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 description coverage is 100%, so all four parameters are already documented with defaults, ranges and patterns. The description corroborates the 30-item cap and the language/country edition concept but adds no syntax or format 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?

States a specific verb and resource: search Google News for a keyword and return up to 30 current articles. It enumerates the returned fields (headline, publisher, publish time, description, link), which lets an agent distinguish it from google-search and web-search siblings that return general web results.

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

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

Gives clear invocation context (send a keyword or phrase; choose language and country edition) and implies the use case of current news retrieval. It stops short of explicit when-not or alternative-tool guidance versus google-search/web-search, so it earns a solid 4 rather than a 5.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent), so the bar is lower; the description still adds real context beyond them: reviewer names and photos are not returned, and an app with no reviews is not charged. It does not explain why the call is non-idempotent, but the coverage-plus-additions is solid.

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

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

A single dense paragraph that is front-loaded with the input formats and the returned payload. Every clause carries information, though the enumeration of returned fields makes it slightly long.

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

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

With no output schema, the description does useful work by enumerating the returned fields (rating, text, date, app version, language, helpful votes) and the 200-review ceiling. Input formats, sorting, filtering and the privacy exclusion are all covered; only rate limiting and pagination behavior are unmentioned.

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 app, sort, limit and rating in detail. The description restates the sort options and star filtering but adds no format or edge-case detail beyond the schema, which is the correct baseline when structured fields do the heavy lifting.

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

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

States a specific verb and resource ('get up to 200 reviews as JSON') for a well-defined source: Google Play. It is immediately distinguishable from siblings like google-maps-reviews or youtube-comments by naming the Android package/Play Store URL input.

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 tells the agent what input to send and what options exist (sort by newest/relevance/rating, filter by stars), which implies usage, but it never states when to prefer this tool over a sibling such as google-maps-reviews or when it is inappropriate. No explicit alternatives or exclusions are given.

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

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

Annotations already declare readOnly (safe read) and openWorld, so the bar is lower. The description adds valuable non-obvious behavior: limit is billed in pages of ~10 and rounded up, so requesting 11 yields two pages — this billing/quota behavior is not in the schema or annotations.

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

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

Front-loaded with the core purpose and return shape, then params, then use cases. Dense but every sentence carries information; the field enumeration is long yet useful given no output schema.

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

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

With no output schema, the description usefully enumerates the returned record structure (organicResults, paidResults, relatedQueries, peopleAlsoAsk, metadata). Safety profile is covered by annotations. Complete enough to invoke correctly; could mention rate limits or result freshness.

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 nonetheless adds meaning by clarifying the rounding/billing semantics of limit beyond the schema's own note, and confirms the required body shape {query, limit}.

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

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

States a specific verb+resource (Google Search results, SERP) for a query, returned as JSON, and enumerates the exact fields returned. An agent can distinguish it from siblings like web-search or google-news without opening the schema.

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

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

Gives concrete use cases — rank checks, source discovery, grounding answers — which implies when to invoke it versus generic web-search. It does not explicitly state when NOT to use it or name the closest alternative (web-search), so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description still adds real value by disclosing the result shape (title, employer, location, posting date, job types, benefits, salary, description) that no output schema provides, plus the notable billing guarantee that paid-but-unreturned jobs are refunded. It omits rate limits and how the non-idempotent nature plays out across calls, keeping it out of 5 territory.

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?

It is a single dense sentence with the core action and return payload front-loaded and no filler. The trailing refund clause is slightly tangential to selection, but each clause carries information.

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

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

With no output schema, the description correctly compensates by enumerating the returned fields, and all five parameters are documented in-schema, so an agent can call it correctly. It lacks only edge-case behavior (empty results, error handling, whether the full listing text is truncated), which is a minor omission for a read-only search 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 every parameter (including the limit cap-slash-default quirk, the posted enum, and the country list) is already documented in the schema. The description's mention of title, location, country, and recency filtering largely restates the schema, which is the correct baseline 3 rather than a value-added score.

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

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

The description names a specific verb and resource ('Indeed jobs search API... send a job title... get up to 50 job listings as JSON') and even enumerates the returned fields, so the tool's function is unmistakable. However, it never distinguishes itself from its closest sibling (linkedin-jobs) or from general job-seeking via web-search, so it stops short of a 5.

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

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

It gives concrete usage context -- filter by posting recency, coverage of 60 countries, up to 50 results -- but offers no explicit when-to-use or when-not-to-use guidance relative to siblings like linkedin-jobs. Usage is implied rather than routed.

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

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

Annotations already declare readOnly/openWorld/idempotent=false/destructive=false, so safety is covered. The description adds real value by stating no Instagram login or API key is required and by listing the normalized output fields, though it omits rate limits or failure behavior.

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

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

Front-loaded with the resource and modes, then parameters, then return shape, with no filler. A few clauses duplicate the schema's mode descriptions, costing it the top mark.

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

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

With no output schema, the description usefully enumerates the normalized post fields (caption, likes, comments_count, views, media_url, etc.) and covers modes, parameters, and the auth model. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and the schema already documents mode, limit, and query thoroughly. The description's restatement of mode semantics and the 1-20 limit is largely redundant with the schema, so it lands at the baseline.

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

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

States a specific verb+resource (fetching Instagram posts as JSON) and enumerates the four modes it supports. An agent can tell this retrieves posts rather than comments, but the description never explicitly contrasts itself with siblings like instagram-comments or tiktok.

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 maps each mode to a use case: profile for an account's posts, hashtag for a tag, search/user for keyword-driven discovery. That is strong conditional guidance, though it stops short of naming exclusions or rival tools to prefer instead.

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

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

Beyond the readOnly/openWorld annotations, it discloses a hard cap of 100 comments per call, that commenter names and handles are deliberately not returned, and an unusual payment model (pay-per-call in stablecoins with refunds for undelivered comments). These are behavioral traits an agent could not infer from annotations or schema.

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

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

Three tight sentences: purpose and invocation first, then result shape, then constraints and payment. Every sentence carries information an agent needs and none repeats the schema.

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

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

With no output schema, the description compensates by naming the returned fields (text, time, likes, reply count) and flagging the missing commenter identity. Combined with the cap and refund behavior, an agent has everything needed to call this correctly and interpret the result.

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

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

Schema description coverage is 100% and both parameters are fully documented in the schema, including default, min/max, and clamping behavior. The description only echoes the 100-comment cap, adding no syntax beyond what the schema already provides, so the baseline 3 applies.

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

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

The description states a specific verb+resource: send a post/reel URL and receive its comments as JSON. The title and resource scope (comments under a post) make it clearly distinct from the sibling instagram tool (post data) and from tiktok-comments/youtube-comments, so an agent can pick it without opening the schema.

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

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

It implies when to use it ('send the URL of a post or reel and get its comments') but offers no explicit when-not or alternative routing, e.g. to the sibling 'instagram' tool for post metadata. Usage context is present but entirely inferred.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint), but the description adds useful non-schema context: 'public' profiles only, 'one per call,' 'no limit field,' and that email addresses are not returned. This enriches understanding beyond what annotations provide.

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 key action and scope. The second sentence lists many return fields, which is informative but somewhat verbose; however, every element is relevant to understanding the output.

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

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

With no output schema, the description compensates by enumerating returned fields (name, headline, experience, education, etc.). It also notes email exclusion. The only missing element is explicit guidance on failure modes or rate limits for a non-idempotent, open-world 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 description for 'query' (100% coverage) already describes acceptable formats. The description repeats this but adds the concrete username example 'jane-example' and clarifies that a limit field is absent, which slightly exceeds the schema but is largely redundant.

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?

Strong, specific verb+resource: 'Look up one public LinkedIn profile per call.' Distinguishes itself from the sibling 'linkedin-jobs' by focusing on profiles rather than job listings, and the scope notes (one profile per call, public only) add precision.

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?

Implies correct usage with 'Pass {query} as a username, profile URL or URN; there is no limit field,' which tells the caller what to supply. However, it doesn't explicitly name or exclude alternatives like a hypothetical 'linkedin-search' sibling or explain when looking up en masse would be inappropriate.

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

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint and destructiveHint, so the safety profile is known. The description adds genuinely new behavioral context: per-company stablecoin pricing and the rule that a not-found company is not charged. It omits auth/rate-limit details but adds value beyond the annotations.

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

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

Two sentences, purpose front-loaded, followed by the return-field list and pricing note. No filler, and the output enumeration earns its place since there is no output schema.

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

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

With no output schema, the description compensates by listing the returned fields, and annotations plus the pricing note cover the behavioral contract for this single-parameter read tool. Nothing an agent needs to invoke 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 the single 'companies' parameter is fully documented in the schema (https only, no query string, 1-10 items, per-company pricing). The description restates the 'up to 10 URLs' bound but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('LinkedIn company enrichment') and enumerates the output fields, so an agent immediately knows it returns company-page records. The resource scope (company pages) implicitly separates it from linkedin-profile-email, linkedin-jobs and linkedin-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?

Usage is implied by 'send up to 10 LinkedIn company page URLs and get one JSON record per company', but there is no explicit when-to-use guidance or routing to alternative tools (e.g. when to prefer linkedin-profile-email or linkedin-jobs). Adequate but leaves selection to inference.

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

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

Annotations already declare readOnly, openWorld and non-destructive behaviour, so the description only needs to add context — and it does: results are capped at 50, only public listings are returned, recruiter names are never included, and billing is refunded for unfulfilled paid jobs. The cap and the public/recruiter caveats are behaviour an agent cannot infer from the annotations.

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

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

Purpose is front-loaded in the first clause, followed by return fields and constraints in one dense paragraph with no filler sentences. The billing/refund sentence is slightly tangential to tool selection but is short and self-contained.

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

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

With no output schema, the description carries the return-value burden and discharges it by naming the JSON fields (title, company, location, date, type, seniority, salary, URL, description). Pagination behaviour beyond the 50-item cap and error/empty-result behaviour are unstated, which is the only real gap for a 4-parameter read tool.

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

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

Schema description coverage is 100%, so the schema already documents limit clamping, the posted enum values and location format. The description only restates these at a high level (up to 50, filter by recency, optional location) without adding format or edge-case detail beyond the schema — baseline 3.

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

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

States a specific verb and resource (LinkedIn jobs search) plus the exact retrieval scope: up to 50 public listings from a title/keyword plus optional location. It also enumerates the returned fields, so an agent can distinguish it from indeed-jobs (different source) and from the plain 'linkedin' profile tool without opening the schema.

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

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

Clear context for when to reach for it: pass a job title or keywords, optional location, and optionally narrow by recency. It does not name alternatives (e.g. indeed-jobs) or say when this source is preferable, so the routing guidance stops short of explicit 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?

Annotations already declare readOnly, openWorld, non-idempotent and non-destructive, so the safety profile is covered. The description goes further, disclosing the 20-post cap, stablecoin payment per post, and that empty-result URLs are not charged, which are behavioral facts the annotations cannot express. It stops short of describing pagination 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?

Three tight sentences, front-loaded with purpose, followed by limit/cost and the empty-result billing caveat. Every sentence adds distinct value with no filler.

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

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

With no output schema, a two-parameter tool and rich annotations, the description is sufficient: it explains the input contract, the result shape and the billed/unbilled cases. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the schema already documents both the URL format and the limit bounds/default/clamping. The description restates 'one URL' and 'up to 20 posts per call', adding reinforcement but no syntax or meaning beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('get its recent posts' from a LinkedIn profile or company URL) and enumerates the returned fields, so an agent can tell it apart from the account-oriented siblings like linkedin-profile-email or linkedin-jobs. It never names or contrasts an actual sibling, which is what keeps it short of a 5.

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

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

Usage is implied: supply one profile/company URL and receive its posts. There is no explicit when-to-use vs-when-not guidance and no mention of alternatives like linkedin-company for other data, so the routing burden stays on the agent.

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

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

Annotations only cover the safety profile (readOnly, openWorld, non-idempotent, non-destructive); the description adds the economically important behavior an agent cannot get elsewhere — pay-per-profile in stablecoins, no charge on a miss, and the deliverability criterion ('not a catch-all domain') plus a returned status and quality score. This also explains the non-idempotent hint: repeat calls cost money.

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 the capability front-loaded and pricing/edge-case handling in the tail; nearly every clause carries new information. Slightly packed in the second sentence, but there is no filler or marketing padding.

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 takes on the burden of describing the return payload, and it does so field-by-field while also covering the billing edge case (no verified email = no charge). For a single-parameter, paid, one-shot lookup, nothing an agent needs to invoke 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 description coverage is 100% and the single 'url' parameter is fully documented there (https only, no query string, maxLength 2048). The description only restates 'one LinkedIn profile URL ... one profile per call', adding no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource ('send one LinkedIn profile URL and get the public profile ... plus the work email') and enumerates exactly which fields come back (headline, about, location, positions, education, skills). The differentiator against the sibling 'linkedin' tool — the verified, deliverability-checked email — is stated up front, so an agent can pick between them without opening a schema.

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

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

Usage is implied rather than routed: the description establishes that this is the tool for profile + work email and constrains it to one profile per call, but never names the obvious alternative ('linkedin' for profile data without email) or states when not to use this paid endpoint. The billing note ('a profile with no verified email is not charged') is useful context but not a selection rule.

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?

Goes well beyond the annotations by disclosing the commercial model (pay per place in stablecoins), the refund guarantee for unpaid-for places, and the payment-chain restriction (Base or Polygon, not Solana). These are exactly the operational traits an agent cannot infer elsewhere; only the mechanics of how payment is authorized are left unstated.

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

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

Two dense, front-loaded sentences: what you send, what you get, then the pricing and chain caveats. No filler, though the first sentence is long and packs the entire field list inline.

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, and the description compensates by enumerating the returned fields and the extra scraping results; it also covers cost and refund behaviour. The main remaining gap is how payment/billing is actually settled, which an agent would need before committing to a paid call.

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

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

Schema coverage is 100%, so query, location and limit (1-8, default 3) are already documented in detail. The description only echoes 'up to 8 places' and 'google map search and a location', adding no new semantics such as query syntax or multi-location behaviour.

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: 'send a Google Maps search and a location and get up to 8 places as JSON' with an explicit enrichment payload (name, address, category, rating, phone, website, plus emails, extra phones and social links). The enrichment and the contact-focus clearly separate it from the plain google-maps sibling, though no sibling is named directly.

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

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

Usage is implied (pass a Maps query plus a location to obtain enriched local business contacts) but there is no explicit when-to-use/when-not-to-use guidance and no routing to google-maps or domain-contacts. The 'one location per call' constraint appears in the schema, not the description.

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

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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), yet the description adds substantial behavior beyond them: pay-per-call in stablecoins, no charge on empty search, refund of paid-but-undelivered ads, and a blockchain restriction (not on Solana; pay on Base or Polygon). That is meaningful operational context an agent needs before invoking a paid, open-world call.

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

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

Front-loaded with the core action and resource, and each clause (filters, pricing, refunds, chain restriction) carries real information. It is a dense run-on paragraph, but nothing is 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 compensates by enumerating the returned fields (advertiser, dates, running status, platforms, text, title, CTA, link, format, image URLs) and covering pricing/refund behavior. It is thorough, though error/rate-limit behavior is left implicit.

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

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

Schema description coverage is 100%, so the schema already documents keyword, page, limit, active, and country. The description reinforces country/active filtering and the 100-per-call cap and adds 'each ad once,' but nothing syntax-critical beyond the schema, so the baseline 3 holds.

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: send a keyword or advertiser, get public Meta ad-library ads as JSON. It names the concrete fields returned and the target use case (competitor research), so an agent can tell it apart from the many other platform-scraper siblings.

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

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

Provides a use-case context ('for competitor research') and notes the keyword-vs-advertiser input choice, but never states when to prefer this over another tool or any when-not conditions. Usage is implied rather than explicitly guided.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent), and the description adds substantial context beyond them: the exact record shape, that at most 'limit' posts come back, that comments/profile/subreddit records are excluded, that upvotes and comments_count may be null, and the effect of raw=true.

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 dense paragraph that is front-loaded with the action and mode usage before moving to return shape and caveats. Every sentence carries information (modes, record fields, exclusions, nullability, raw), though it is a long run-on rather than clearly segmented.

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

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

With no output schema, the description compensates by enumerating returned fields (kind, id, url, title, body, author, subreddit, upvotes, comments_count, created_at, members, source) and noting nullability. Combined with annotations covering safety, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the schema already documents mode, query, limit, and raw. The description repeats mode usage and 'no r/' and 'limit 1-20' but adds no semantics beyond the schema, so the baseline 3 applies.

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

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

States specific verbs (search, read) and resources (Reddit posts, subreddit) and the title reinforces scope ('Reddit posts by subreddit, user, search'). The description also clarifies what the tool does NOT return (comments, profile, subreddit records), making its boundary unambiguous despite sibling tools on other platforms.

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

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

Gives per-mode usage: 'hashtag with a subreddit name (no r/), profile with a username, or search with keywords, plus limit 1-20.' This tells the agent how to trigger each path. There is no competing Reddit sibling to route to, so no explicit alternative-routing is needed, but no exclusions beyond the record-type note.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds real beyond-schema context: the base64 JSON return shape, the bot-protection limitation, and a cost note that failed/blank captures aren't charged. These are behaviors an agent cannot infer from annotations alone.

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 dense, front-loaded paragraph: identity and return format first, options next, limitations and billing last. No filler sentences; every clause carries information.

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

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

For a 10-parameter tool with full schema coverage and no output schema, the description supplies the missing pieces: return format, the key limitation, the alternative tool, and cost behavior. Nothing essential to calling it correctly is left out.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only loosely gestures at options ('viewport, full page, dark mode, selector'), which map to parameters the schema already documents in more precise terms, so it adds little beyond the structured fields.

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

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

States a specific verb+resource (screenshot a URL) and enumerates the output formats (JPEG, PNG, WebP, PDF as base64 JSON), so the agent knows exactly what it gets back. It also routes away from itself by naming the sibling 'unblock' for bot-protected pages, cleanly separating it from related 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?

Provides an explicit exclusion ('does not get past bot protection') paired with the correct alternative ('use unblock for those pages' text'). It lacks broader when-to-use framing versus other capture-ish siblings, but the failure-case routing is clear and actionable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds context the annotations do not: a cost model ('pay per call in stablecoins'), a latency expectation (~1 second), and result-shape detail. It omits rate limits or failure behavior, so not a 5.

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

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

A single dense paragraph that front-loads the core purpose before filters, latency and pricing. Almost every clause earns its place; the 'Search API for AI agents' preamble is slightly redundant but harmless.

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

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

With no output schema, the description correctly carries the burden of describing return values (title, URL, query-relevant excerpt) and covers type, limits, categories, domain filtering, cost and latency. The main missing piece is the relationship to the many sibling search 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% and every parameter (type, limit, query, category, include/exclude_domains) is already documented in the schema, including billing in pages of 10 and the mutual exclusivity of include/exclude domains. The description restates category meanings and site filtering but adds no syntax or format beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource (web or news search) plus the result shape (title, URL, excerpt) and count. However, in a sibling set that already contains web-search, google-search and google-news, it never says how it differs from those, so the agent cannot distinguish it from its closest alternatives without extra work.

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

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

There is no when-to-use or when-not-to-use guidance. It never tells the agent when to pick this over web-search, google-search or google-news, and no prerequisites or exclusions are given. 'Fast, about a second' is a selling point, not routing guidance.

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

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

Annotations already declare readOnly, openWorld, non-idempotent, non-destructive, but the description adds substantial context beyond them: pay-per-call billing in stablecoins, a no-charge guarantee for non-Shopify sites or empty stores, and a refund promise for unpaid results. It also enumerates the returned fields, which is valuable given no output schema exists.

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

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

Front-loaded with the core action and scoping bound, then the return fields, then billing terms. The opening phrase 'for AI agents' is mild filler and the return-field list makes the first sentence dense, but the structure is otherwise efficient with no wasted sentences.

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

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

With no output schema, the description compensates by listing returned fields, and it covers billing and failure semantics. What is missing is any guidance on response shape, pagination beyond the 250 cap, or ordering, but for a two-parameter read tool this 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%, and the schema itself documents the limit capping/clamping behavior and the accepted domain formats in detail. The description only restates 'up to 250' and 'send a store's domain', so it adds little beyond the structured fields — baseline 3 is appropriate.

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

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

States a specific verb and resource ('send a store's domain and get up to 250 of its public products'), and the Shopify scoping clearly separates it from siblings like amazon, ebay-sold, or web-search. An agent can identify exactly what it returns without opening the schema.

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

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

Usage context is implied by the title and the required 'store' domain parameter, but there is no explicit when-to-use versus when-not, nor any routing to an alternative sibling when a site is not a Shopify store. Adequate but leaves the agent to infer that this is the Shopify-specific choice among marketplace 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?

Adds behavioral detail well beyond the annotations: 'no expiring media links' (durability of returned URLs), 'raw true returns the original records', and that a leading @ or # is stripped from the query. These are non-obvious operational traits an agent needs, and they are consistent with readOnlyHint=true.

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

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

Purpose and modes are front-loaded, followed by output shape and normalization notes. The output-field list is longer but earns its place since no output schema exists; overall efficient with little wasted text.

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

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

With no output schema, the description fully compensates by enumerating the returned video fields and flagging the absence of expiring media links. Combined with mode, limit, raw, and normalization semantics, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns above baseline by restating the body shape and, more importantly, disclosing normalize behavior (leading @ or # stripped) that the schema does not fully state, adding meaning beyond the field 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?

States a specific verb (Get) and resource (TikTok videos) and enumerates the three retrieval modes (profile, hashtag, search). The resource is clearly distinct from the sibling tiktok-comments tool, so an agent can route correctly without opening the schema.

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

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

The three modes are explained (profile=user's videos, hashtag=videos under a tag, search=keyword→videos), giving clear context for choosing among them. It does not explicitly route the agent away from or toward alternatives like tiktok-comments, so 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?

Goes well beyond the annotations by disclosing the payment model ('Pay per call in stablecoins'), the refund guarantee for undelivered comments, the 100-comment ceiling, and the deliberate omission of commenter names/handles. These are exactly the operational and output-shape facts an agent cannot get from readOnlyHint/idempotentHint.

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

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

Front-loads the core action and output fields, then layers limits, omissions, and billing in short clauses. Only the 'for AI agents' framing is mild filler, but nothing is redundant or 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?

With no output schema, the description carries the return-value burden and does so by naming the exact fields returned and the fields withheld. Combined with the limit and billing/refund disclosure, an agent has everything needed to call and interpret 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?

Schema description coverage is 100%, so both parameters are already fully documented, including the coercion rule for out-of-range limit values. The description only restates the 100-comment cap, adding no syntax or format detail beyond the schema; 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?

Names a specific verb and resource ('send the URL of a video and get its comments as JSON') and enumerates the returned fields (text, time, likes, reply count). An agent can distinguish this from the sibling 'tiktok' (video data) and 'youtube-comments' without opening the schema.

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

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

Usage is implied by 'send the URL of a video', and the 100-comment cap is stated, but there is no explicit when-to-use guidance and no routing to alternatives such as 'youtube-comments' or the generic 'tiktok' tool. The agent must infer platform selection from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so safety is covered. The description adds genuinely non-structural behavior: pay-per-call USDC billing and the chain restriction (not offered on Solana). The enumerated return fields also inform the agent about output shape. No contradiction with annotations.

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

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

Front-loaded with purpose, then parameters, then return fields, then payment constraints in a single dense paragraph. All content is relevant and none is filler, though the long return-field list makes the block slightly heavy.

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, enumerating the returned tweet fields (text, createdAt, counts, isReply, author object) usefully compensates. Payment/auth and limit behavior are covered. The main gap is lack of differentiation from the x-replies sibling, which an agent needs to route correctly.

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

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

Schema description coverage is 100%, so mode, query and limit are already documented in the schema, and the description largely restates them ('limit is 1-20', 'mode search takes keywords'). The inline example {"mode":"profile","query":"nasa"} adds modest practical value, but the baseline of 3 is appropriate when the schema carries the parameter detail.

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

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

States a specific verb+resource ('Tweets from X (Twitter)') and distinguishes its own two modes (profile vs search) with a concrete example. However, it never mentions the sibling x-replies, so an agent must infer which Twitter-related tool to pick from the tool list alone.

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

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

Gives clear selection guidance between its modes ('mode search takes keywords', profile returns an account's tweets) and states a real usage prerequisite (no X developer account needed, pay per call in USDC, Base or Polygon only, not Solana). It stops short of naming when to use this versus x-replies or other social siblings.

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

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

Annotations already declare this a read-only, non-destructive, open-world call. The description adds genuinely new behavioral context the annotations cannot convey: bot-protection bypass, JavaScript rendering, no charge when a fetch fails (blocked, error, or empty), and the payment/auth model (no API key, pay per call in USDC over x402 or MPP). That is a rich disclosure of cost and failure semantics.

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 tightly packed sentences with the core behavior front-loaded, then modifiers (format overrides), then cost semantics. Every clause earns its place; nothing is redundant padding.

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

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

With no output schema, the description compensates by naming the returned fields, and it additionally covers failure handling and the payment path. For a two-parameter page-fetch tool, an agent has everything needed to call it and interpret results.

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

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

Schema description coverage is 100% and the schema itself documents url format, maxLength, the format enum and its default. The description only restates what format can be set to, adding no syntax or edge-case detail beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb and resource ('send {url} and get the page back as clean Markdown') and enumerates the return payload (title, description, language, final URL, HTTP status). It is clearly distinguishable from siblings like screenshot or web-search, which target images and search respectively rather than single-page extraction.

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 usage context (fetching a public page, including Cloudflare-protected or JS-heavy ones) and covers the format switch, but it never says when to pick this over sibling tools such as screenshot or web-search, nor does it state any exclusion beyond 'public page'.

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?

Beyond the safety annotations (readOnly, openWorld, non-idempotent, non-destructive), the description discloses hard behavioral facts: 5-result cap, 20,000-character truncation, failed pages dropped and refunded, stablecoin payment per call, and chain availability (Base/Polygon, not Solana). These are non-obvious operational traits an agent must know before calling.

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

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

Front-loaded with the core capability and return shape, then dense single-clause sentences for limits, refunds, and payment. No filler; every sentence carries operational 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, it enumerates the return fields (title, URL, description, page text) and covers limits, truncation, and payment. It stops short of describing auth/onboarding for the paid flow, which is the only real gap for a pay-per-call 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 both parameters are fully documented in the schema, including the limit clamping rules. The description only echoes 'keywords' and 'up to 5 results' without adding syntax or format 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?

States a specific verb and resource ('web search') plus its distinguishing feature ('with page content... read as clean Markdown, in one call'), which separates it from plain search siblings like google-search. The agent immediately understands the value proposition without opening the schema.

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

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

The description implies usage (get pages in one call, keywords only) but never explicitly names when to prefer this over siblings such as google-search, search-plus, or unblock, nor states exclusions. Usage is inferable from the feature set but not routed.

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?

Beyond the readOnly/destructive/openWorld annotations, it discloses the commercial behavior an agent must plan around: per-call stablecoin payment, a refund guarantee for replies paid for but not delivered, and the supported payment chains. These are material behaviors that no annotation or schema field conveys.

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

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

Purpose, output shape, cap, and payment terms are all front-loaded in three dense, waste-free clauses. The only marginal filler is the "for AI agents" framing, which does not carry information.

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

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

With no output schema, the description compensates by enumerating the returned fields, and it covers the limit cap, pricing, refund policy, and chain eligibility. An agent has everything needed to decide, pay for, and call 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 description coverage is 100%, so both parameters (url and limit, including the 1-50 clamping rules) are already fully documented in the schema. The description only restates the URL input and the 50-reply cap, adding no new semantics beyond the structured fields, 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 opens with a specific verb and resource ("Replies to a post on X"), states the required input (the post URL) and the exact shape of the result (text, time, likes, reposts, replies, views, author handle). An agent can distinguish this from generic 'twitter' or the *-comments siblings without opening the schema.

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

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

It gives clear operational conditions for invocation: you must supply an x.com/twitter.com post URL, results are capped at 50 per call, and payment must be on Base or Polygon (not Solana). It stops short of explicitly naming a sibling as the alternative for other social networks, so it is clear context rather than explicit when/when-not routing.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: limit is capped at 20 and excludes Shorts and live streams, and it enumerates the normalized fields returned per video despite the absence of an output schema. It stops short of covering failure modes or ordering guarantees.

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

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

Two tight sentences, front-loaded with purpose and mode routing before the return-shape list. The field enumeration is long but justified given there is no output schema, so every clause earns its place.

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

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

With no output schema, the field list is a valuable substitute and the mode/limit/exclusion details are all present. It omits error handling and what happens with an invalid channel handle, so it is strong but not fully complete for a two-mode tool.

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

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

Schema coverage is 100% and all three parameters are self-documented in the schema, so the baseline is 3. The description largely restates the schema (mode semantics, channel handle without @, limit range) and adds no syntax or format detail the schema lacks.

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+resource ('YouTube video search by keyword, or the videos of one channel') and pins down the two operating modes. It clearly distinguishes this from siblings like youtube-comments and youtube-transcript, which cover different resources.

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 which input each mode expects ('mode search takes keywords; mode profile takes a channel handle without the @'), giving clear routing between the two modes. However, it never states when to prefer this tool over the sibling youtube-transcript/youtube-comments tools or any exclusion criteria.

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

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

Annotations already cover the read-only, non-destructive, open-world profile, yet the description adds genuinely new operational facts: a hard 100-comment ceiling per call, the deliberate omission of commenter names and handles, per-call stablecoin billing, and a refund guarantee for paid-but-undelivered comments. That is exactly the behavioral context annotations cannot express.

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 packed sentences with no filler. Capability and return shape come first, then the operational caveats (data omission, pricing, refunds), which is the right front-loading for an agent scanning for a match.

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

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

With no output schema, the description carries the return-value burden and does so (field list plus the explicit note that author identities are absent), and it covers cost and refunds. It stops short of describing failure modes for an invalid or non-video URL, which is the one remaining gap for a paid open-world fetch.

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

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

Schema description coverage is 100% and the schema already documents url, sort (with enum) and limit (with defaults, bounds, and clamping behavior). The description only echoes the 100-comment cap, adding no meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (comments under a YouTube video) and enumerates the return fields: text, time, likes, reply count. This cleanly separates it from the sibling youtube-transcript and from review-comment tools for other platforms, so an agent can route correctly without opening the schema.

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

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

Usage is implied by the input shape ('send the URL of a video'), and the per-call cap of 100 comments hints at scope, but there is no explicit statement of when to use this over youtube-transcript or when-not to use it at all. Adequate but leaves routing to inference.

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

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

Annotations already state readOnlyHint, openWorldHint, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: no speech-to-text, uncharged when the requested language is missing, and payment-rail constraints ('Not offered on Solana: pay on Base or Polygon'). Does not mention rate limits or pagination, but for a read-only fetch that is acceptable.

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-loaded with purpose and output shape, followed by constraints. No filler, though it packs many clauses and could be split for readability. Substance outweighs structure issues.

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 3-param read-only tool with no output schema, the description covers purpose, inputs, outputs, language handling, billing behavior, and payment-rail limits. It lacks explicit notes on rate limits or rate-limit errors and does not name sibling alternatives, but it is complete enough 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%, so all three parameters are already documented in the schema, including enum descriptions and defaults. The description restates input forms ('video URL or 11-character id') and format/language options but adds no syntax or edge-case details beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb (fetch subtitles) and resource (YouTube transcript) with scope limits: 'No speech-to-text.' Names the accepted input form (URL or 11-char id) and outputs, so an agent can tell it apart from siblings like youtube or youtube-comments without opening schemas.

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?

Clearly implied usage: send a video URL or id to get subtitles. Gives one exclusion ('No speech-to-text') which routes agents that need transcription elsewhere. Does not name a specific alternative sibling for videos without subtitles or for other YouTube data, so it stops short of a 5.

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