Unstuck

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real non-annotated context: per-call cost ($0.03 per successful call, failed calls free) and the exact field set returned. It omits rate limits and the free-tier/API-key behavior, which the schema partially covers.

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 with zero filler: what it returns first, then when to use it, then cost. Pricing is placed last where it belongs, and nothing is repeated from the schema or annotations.

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

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

An output schema exists, so return values need not be explained, and the description still previews them usefully. Coverage of purpose, use cases and cost is complete for a small read-only lookup tool. The one missing piece is sibling routing to business_reviews for review-level detail.

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, limit and api_key are each fully documented in the schema with examples. The description only echoes 'of a kind in a city', adding no format, default-count, or validation nuance beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb and resource ('Find local businesses'), the scope ('in a city'), the data source ('as listed on Google Maps'), and enumerates the returned fields. It is unmistakable what the tool does. It does not distinguish itself from the sibling business_reviews, which touches the same star-rating/review data, so it falls short of a 5.

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

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

Gives concrete usage contexts ('build a lead list, find competitors, or look up a business's contact details'), which is clearer than mere implied usage. However, it names no alternatives or exclusions — e.g. routing the agent to business_reviews when it needs review text rather than a listing.

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/idempotent/openWorld, so the bar is lower; the description adds genuinely non-obvious context by disclosing the $0.05 per successful call cost and that failed calls are free. It omits freshness guarantees beyond 'most recent' and any rate-limit behavior.

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

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

Three tight sentences: what it returns, how to supply input, when to use it, plus cost. Front-loaded with the resource and output fields, with no filler.

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

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

An output schema exists so return values need no further explanation, and the description still names the key returned fields. Inputs, usage intent, and pricing are all covered, leaving nothing an agent needs in order to call this correctly.

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

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

Schema description coverage is 100%, so the schema already documents limit, api_key, business, location and place_id. The description only restates the business/location vs place_id choice, adding no syntax or format 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?

Specific verb ('Read') plus resource ('most recent Google reviews of a local business') and it names the returned fields (star rating, review text, date). It also distinguishes itself from business_listings by citing it as the source of place_id.

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

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

Explicitly states the use case ('judge a business's reputation or see what customers complain about') and offers two input routes (name + city, or place_id from business_listings). It stops short of stating when NOT to use it or how it relates to other lookup 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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the SEC EDGAR data source, the non-affiliation disclaimer, and the pricing model ('$0.02 per successful call; failed calls are free'), which is behavior an agent cannot get from structured fields. Pagination/limit behavior is left to the schema.

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

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

Front-loaded with the core action and scope, followed by data source and price in compact sentences. No filler, though the price/disclaimer sentence is somewhat boilerplate-heavy relative to the tool's core purpose.

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

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

With an output schema present, return values need not be explained, and the description covers source, cost, and lookup keys adequately for a read-only list tool. The main remaining gap is guidance on selecting this tool versus adjacent financial/data siblings.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema itself, establishing a baseline of 3. The description reinforces the ticker-or-CIK duality and lists returned fields, but adds no syntax or format detail (e.g., amendment handling) beyond what the schema already provides.

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

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

States a specific verb and resource ('List a US public company's recent SEC filings'), enumerates the form types covered, and names the lookup keys (stock ticker or CIK). An agent can distinguish it from company_financials or insider_trades 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?

The description implies usage via 'by stock ticker or CIK' and the form-type scope, but never says when to choose this over siblings like company_financials or insider_trades, and states no exclusions or prerequisites. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds non-obvious behavioral context the annotations cannot: the data source (SEC EDGAR XBRL), the pricing model ($0.03 per successful call, failed calls free), and that results carry latest annual and quarterly values with period/form/filing date.

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 return fields, then source and pricing. Dense but every clause carries information; the SEC non-affiliation disclaimer is the only mildly expendable element.

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

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

An output schema exists, so return-shape explanation is unnecessary. The description covers source, cost, default metrics, and value granularity (annual + quarterly with period/form/filing date), leaving only minor gaps such as error/empty-result behavior.

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

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

Schema description coverage is 100%, so both ticker_or_cik and metrics are already documented in the schema, including the default metric set and the Revenues fallback concepts. The description restates the metric examples 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 resource (key financial numbers for a US public company) and the keying method (ticker or CIK), then enumerates the concrete metrics returned. An agent can clearly separate this from company_filings or insider_trades 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?

The description implies when the tool fits (getting financial statement values) but never names an alternative or an exclusion condition relative to siblings like company_filings or insider_trades. The default metric list and the 'or any XBRL concept you name' note give context but not routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-redundant behavior: the pricing model ($0.03 per successful call, failed calls free) and the exact shape of the returned review fields, which an agent needs for cost/benefit decisions.

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 and returned fields, then the required input, then use cases, then cost — every sentence earns its place with no repetition or 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?

For a read-only, idempotent lookup with an output schema and full schema coverage, the description supplies everything extra an agent needs: what the reviews contain, the required domain input, intended use cases, and the per-call price. Nothing material is missing.

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

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

Schema description coverage is 100%, so the schema already documents domain, limit (default 20, max 40) and api_key. The description only reinforces the required 'domain' parameter and omits limit entirely; baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb and resource ('Read a company's most recent Trustpilot reviews') and enumerates the returned fields (star rating, headline, review text, date, reply status, overall rating, count). Naming Trustpilot specifically differentiates it from the sibling business_reviews without needing 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 ('vet a supplier or prospect', 'find a competitor's weak spots'), which tells the agent when this tool is the right choice. It stops short of naming alternatives or stating when not to use it (e.g. versus business_reviews for non-Trustpilot sources), so it falls just 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 read-only, idempotent, open-world and non-destructive behavior, and the description adds genuinely new operational context: a $0.005 per successful call price, free failed calls, a no-key free tier of a few calls a day, and the RDAP source. It also hedges appropriately with 'appears free to buy', signalling registry-lookup limits rather than guaranteeing purchasability.

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 behavior come first, followed by usage and then cost/access details in compact sentences with no filler. Slight redundancy between 'says whether it is already taken or appears free to buy' and the opening availability statement, but the structure is well front-loaded.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description still covers the remaining agent-facing unknowns: cost per call, free failures, no-key trial limits, and the data source. Nothing an agent needs in order to decide to call this tool 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 both parameters are documented in the schema (including the example domain and the optional api_key/free-trial semantics), so the description is not required to compensate. It adds nothing about parameter formatting or edge cases beyond what the schema already states, matching the baseline for full-coverage schemas.

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

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

States a specific verb and resource ('Check if a domain name is available to register') and even names the lookup mechanism (official registry / RDAP), so the agent knows exactly what the tool returns. It does not explicitly differentiate itself from the sibling domain_info, which an agent might reasonably confuse it with, so it falls short of a 5.

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

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

Gives a concrete use case ('find an available domain for a new business, product, or website name') that tells the agent when this tool is appropriate. It offers no when-not guidance or named alternatives (e.g. use domain_info when the domain is already registered and you want details), so it stops short of explicit 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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful non-obvious context the annotations cannot convey: $0.01 per successful call, failed calls free, and a free tier of a few calls per day without a key — a real cost/rate consideration for an agent deciding whether to 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?

The capability list is front-loaded in one dense sentence and the usage sentence follows immediately; the pricing sentence is arguably promotional but is short and decision-relevant. No wasted preamble or redundancy.

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

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

With an output schema present, the description need not explain return structure, and it does summarize the data categories returned. Combined with the required domain parameter and the free-tier/pricing note, an agent has enough to call it correctly, though the missing differentiation from 'domain_check' leaves a small routing gap.

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

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

Schema description coverage is 100%, so both parameters (domain, api_key) are already documented in the schema, including an example value for domain. The description adds no syntax, normalization, or format guidance 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?

The description states a specific verb ('look up') and resource (a domain) and enumerates exactly what is covered: RDAP/WHOIS registration data, DNS records, SPF/DMARC, and SSL certificate issuer/expiry. It does not, however, distinguish itself from the sibling 'domain_check', which sounds like an overlapping capability an agent could confuse it with.

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

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

It gives four concrete usage contexts (research a company's domain, check domain/certificate expiry, debug DNS or email deliverability, verify who hosts a site), which is clear when-to-use guidance. It offers no when-not-to-use or explicit alternative routing, 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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses the guessing strategy, that the first confirmed pattern is returned with a confidence value, the catch-all-domain edge case where confirmation is impossible, and the billing model ($0.10 per successful call, failures free). That is exactly the operational detail an agent cannot get from structured fields.

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

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

Front-loads the core action, then the algorithm, the edge case, the use case, and finally pricing — a sensible ordering with no filler. It is a touch long, and the "first.last, flast, first, and so on" enumeration is illustrative rather than load-bearing.

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

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

With an output schema present, return values needn't be explained, and the annotations cover the safety profile; the description fills in algorithm, confidence, catch-all behavior and cost. The only unaddressed element is the optional api_key parameter's role in this specific tool, which the schema already documents.

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

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

Schema description coverage is 100% with per-parameter descriptions for first_name, last_name, domain and api_key, so the schema carries the burden. The description only restates that inputs are a name and a company website and adds nothing about formats, length limits, or the api_key/payment behavior. Baseline 3 applies.

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

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

States a specific verb and resource (find a person's work email) plus the inputs it derives from (name and company website), which cleanly separates it from the sibling email_verify that checks an address already in hand. An agent can pick this 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?

"Use it to reach a specific person at a company" gives a clear usage context, and the description implies the agent should have a name and domain rather than an existing address. It never names the obvious alternative (email_verify) or states when not to use it, so it stops short of explicit 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), but the description adds genuinely new operational context: per-call pricing ($0.02 per successful call, failed calls free) and the specific risk categories it detects. It does not mention rate limits, latency, or auth failure behavior beyond what the api_key schema field already states.

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

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

Three sentences, each earning its place: purpose first, detection categories second, use cases and cost last. 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?

An output schema exists, so return values need not be spelled out. For a simple two-parameter read-only lookup, the description supplies purpose, detection scope, intended use, and cost — everything an agent needs to select and 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%, with both 'email' and 'api_key' documented in-schema, so the baseline is 3. The description adds no syntax, normalization, or format guidance for the email parameter beyond the schema's own example.

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

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

States a specific verb and resource ('Check whether an email address is real and safe to send to') and enumerates the verdicts it returns (deliverable, undeliverable, risky, unknown). That framing clearly separates it from the sibling email_find, which discovers addresses rather than validating them.

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

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

Gives concrete when-to-use contexts: 'before sending outreach' and 'to clean up a sign-up list.' It stops short of naming a when-not or an explicit alternative (e.g. use email_find to discover addresses), so it is clear but not fully 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 cover the read-only/idempotent/non-destructive profile, but the description adds real value beyond them: the data provenance (SEC EDGAR, unaffiliated), a per-call cost model ($0.03 per successful call, failed calls free), and the edge case that an option/RSU vest produces two rows in one filing. These are exactly the behavioral facts an agent needs.

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

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

Front-loaded with the core purpose, then efficient supporting sentences on the vesting edge case, data source, and pricing. Dense but each sentence carries distinct, useful information; only minor trimming would help.

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

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

With an output schema and rich annotations already present, the description still fills the remaining gaps: provenance, cost model, and the two-row vesting behavior. Nothing an agent needs to invoke or interpret the call correctly is missing.

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

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

Schema coverage is 100%, so ticker_or_cik, limit, and api_key are fully documented in the schema itself. The description adds no parameter syntax or format detail 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+resource (recent insider buying and selling at a US public company), names the identifying key (ticker or CIK), and enumerates the exact fields returned. This clearly distinguishes it from the generic sibling company_filings.

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

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

The description makes the use case (insider Form 4 activity) clear, but never names an alternative or states when NOT to use it. It does not route the agent to company_filings for broader filing needs, leaving comparison 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 read-only, idempotent, open-world, non-destructive behavior, so the safety bar is covered. The description adds genuinely useful behavioral context beyond that: the 100-phrase batch ceiling and the cost model ($0.15 per successful call, failed calls free). Auth handling is left to the api_key schema field.

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

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

Four tight sentences, front-loaded with what the tool returns, followed by capacity, use case, and price. No filler; each sentence carries decision-relevant 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 an output schema present, return values need no explanation, and annotations carry the safety profile. The description supplies the remaining decision inputs an agent needs: batch capacity, intended use, and cost, making it complete for a read-only data lookup.

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. The description only reinforces the batch limit ('up to 100 phrases'), matching maxItems, and adds nothing about language or location defaults beyond what the schema states. 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 ('how many people search Google for each phrase per month') and enumerates the returned metrics (volume, cost per click, competition). No sibling tool overlaps this function, so the agent can identify it immediately.

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 a clear context for use ('pick keywords for a website, blog post, or ad campaign') but names no alternatives or exclusion conditions. Since no sibling covers keyword data, the absence of alternatives is low-risk, but explicit when-not guidance is still missing.

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

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

Goes well beyond the annotations: discloses the pricing model ($0.03 per company returned, charged only for what is returned, failed calls free), the default/cap on results (25/50), and how api_key behaves (leave empty for free tools or to get a payment link). Annotations already cover read-only/idempotent/open-world safety, so this is pure added value.

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

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

Front-loaded with the core purpose and a concrete example, then layered with limits, filters, use case and pricing. Slightly redundant in stating the pay-per-returned-site rule twice ('you pay only for sites returned' and again in the Price sentence), which costs a point on tightness.

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

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

Covers everything an agent needs for a discovery tool with an output schema present: what it returns (phone, emails, social profiles), how many, cost, and filter surface. Since an output schema exists, return-value detail need not be spelled out further.

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, country, keyword, technologies and api_key with examples and constraints. The description restates the default 25 / up to 50 limit and mentions country/keyword filtering but adds no new syntax or conjunction semantics beyond what the schema says. 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 ('Build a lead list of websites that use specific software') and immediately grounds it with concrete examples ('every Shopify store using Klaviyo, or dental sites on WordPress'). This distinguishes it from the neighboring per-site tech_stack tool, which inspects one known site rather than discovering sites by technology.

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 intended context ('Use it to find prospects who already use (or need) what you sell') and notes the country/keyword filters, so the agent knows when this is the right tool. It stops short of naming alternatives or stating when NOT to use it (e.g. use tech_stack to inspect a known domain), so not a 5.

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

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

Annotations already cover read-only/idempotent/open-world safety, and the description goes well beyond them: data source (Crossref), metadata-only with no abstracts, pricing ($0.002 per successful call, failures free), and the no-key free tier. These are exactly the operational facts an agent needs 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?

Two tight sentences: the capability and returned fields come first, then the usage cue, data source and cost. Every clause carries distinct information with no 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 an output schema present, return-value detail is unnecessary, and the description covers everything else an agent needs: domain, data source, cost model, free-trial behavior, and the metadata-only limitation. Nothing material 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 limit, from_year and api_key are already documented in the schema. The description adds only that results are metadata-only and searchable by topic or title, which is marginal over the structured fields; 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 (search) and resource (scholarly papers, articles, books, preprints) and enumerates exactly what is returned: title, authors, year, venue, DOI, link, type, citation count. This is clearly distinguishable from generic siblings like web_search or read_page.

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?

"Use it to find sources or citations for a research question" gives a concrete use context. It does not, however, state when to prefer this over the sibling web_search or note any exclusions, so it stops short of explicit alternative 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavioral facts: the text-layer limitation with no OCR fallback, the $0.005 per successful call price, free failures, and a keyless free trial tier. That is real context an agent cannot get from the annotations or schema.

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

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

Three tight sentences, front-loaded with the action and output format, followed by applicability, a hard limitation, and cost/auth terms. No filler and nothing buried that an agent needs to decide whether to call.

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

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

An output schema exists, so return-value documentation is not required, yet the description still names the markdown/page-by-page format. Combined with the OCR limitation, pricing, and auth notes, an agent has everything needed to call this correctly or route elsewhere.

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

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

Schema description coverage is 100% for both parameters, including maxLength constraints, so the structured fields already do the work. The description only implies the URL input and hints at keyless usage via the free-tier note; it adds 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?

States a specific verb and resource ('Extract the text from a PDF file at a URL') plus the output shape ('return it as markdown, page by page'). This distinguishes it cleanly from siblings like read_page and screenshot, which operate on web pages rather than PDFs.

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

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

Provides concrete use cases ('read a PDF, parse a form, report, paper, invoice, or document, or convert a PDF to text') and an explicit when-not condition: scanned image-only PDFs are unsupported because there is no OCR. It stops short of naming a sibling alternative, but the usage envelope is unambiguous.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, yet the description adds real behavioral context beyond them: JavaScript is rendered in a real browser, so results differ from a plain fetch, plus the cost model ($0.005 per successful call, failures free) and an unauthenticated free tier. These are operational facts an agent cannot infer from structured fields.

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

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

Four short sentences, each earning its place: capability, differentiator, use cases, cost/free tier. The core capability is front-loaded and nothing is redundant with the schema or annotations.

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

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

An output schema exists, so return-format detail is unnecessary, and the description covers the remaining agent-relevant unknowns: rendering behavior, cost, and authentication/free-try mechanics. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and both parameters (url, api_key) are documented in the schema itself, so the description adds nothing parameter-specific. Per the baseline rule for high coverage, a 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 ('Fetch any URL and get the page's main content as clean markdown') and immediately differentiates from sibling readers by noting JS rendering in a real browser. An agent can distinguish it from screenshot, pdf_to_text, or web_search without opening any schema.

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

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

Gives concrete usage contexts ('read articles, docs, product pages or search results') and implicitly scopes it to modern JS-heavy sites where a plain fetch fails. It does not explicitly name when to prefer a sibling like web_search or screenshot instead, so it stops short of full when-not 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, so the safety profile is covered. The description adds genuinely new context beyond that: the pricing model ($0.01 per successful call, failed calls free) and the fact it uses a real browser, both operationally relevant. It doesn't mention rate limits or latency.

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

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

Four tight sentences with the core action and output front-loaded, followed by use cases and cost. No filler; every sentence carries information an agent can act on.

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

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

With an output schema present the return format needn't be described, and the description covers action, use cases, auth (via the api_key param), and cost. Slightly incomplete on failure/pagination behavior for a paid external call, but otherwise self-contained.

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 parameters are self-documented and the baseline is 3. The description adds meaning beyond the schema by explaining the viewport-vs-full-page choice ('either the visible area or the full page'), reinforcing the full_page flag's purpose.

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 (take a screenshot of a website, open any web page URL in a real browser) and names the output artifact (PNG image), with the viewport/full-page distinction. The 'capture as image' framing cleanly separates it from text-oriented siblings like read_page and web_search.

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

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

Gives clear use cases ('see what a site looks like, check a page layout, or capture visual proof'), which tells the agent when this tool fits. It stops short of naming alternatives (e.g., use read_page for extractable text) or stating when-not to use it.

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

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

Annotations already declare read-only, idempotent and open-world, but the description adds information the structured fields cannot: listings can include used, refurbished, rental and bundle offers, so titles and sellers must be inspected before trusting a price, plus a per-call cost model ($0.25 per successful call, failed calls free).

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

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

Four sentences, each doing distinct work: purpose, return shape, data-quality caveat, intended use, cost. The core purpose is front-loaded and nothing is redundant.

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

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

With an output schema present, return values need not be re-explained, yet the description still sketches the payload. Combined with the cost note and the offer-quality caveat, an agent has everything needed to decide and invoke correctly.

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

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

Schema description coverage is 100%, with product, location and api_key all documented including defaults and examples, so the schema carries the parameter burden. The description adds no location/product formatting guidance beyond what the schema already says, matching the baseline 3.

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

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

States a specific verb ('Compare') and resource ('what stores charge for a product right now') and immediately clarifies the return payload (Google Shopping listings with price, currency, seller, link). No sibling tool covers price comparison, so it is unambiguously distinct.

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 usage contexts: checking competitor pricing or finding the going rate before buying or listing. However, it names no alternatives or conditions under which another sibling (e.g. web_search) would be preferable, so it falls short of an explicit when-not.

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 substantial behavior beyond the annotations: the data comes from a refreshed crawl rather than a live visit, 'last_checked' indicates scan time, small/new sites may show only partial stacks, and pricing is $0.05 per successful call with failed calls free. With readOnly/idempotent/openWorld already declared, this freshness, coverage, and cost disclosure is exactly the extra context an agent needs.

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

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

Content is front-loaded: what the tool returns first, then use cases, then freshness caveats, then price. Sentences carry distinct information, though the dense enumeration of categories makes the opening clause 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?

An output schema exists so return fields need not be explained, and the description still covers data provenance, freshness caveats, partial-result risk, and cost. Nothing an agent needs to call this 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 schema itself documents both 'domain' (format and URL tolerance) and 'api_key' (when to leave empty). The description adds no additional 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 specific verb and resource ('See what a website is built with') and enumerates the returned categories — store platform, CMS, email marketing, analytics, payments, hosting, plus contact/social data. This clearly separates it from siblings like domain_info or leads_by_tech, though no sibling is named explicitly to sharpen the contrast.

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 usage contexts: 'qualify a sales lead, size up a competitor, or find out what software a company already pays for.' That is clear when-to-use guidance, but it offers no exclusions or named alternatives (e.g., when to prefer leads_by_tech or domain_info instead).

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful non-structured context: the NVD data source, a per-call price of $0.002 with free failed calls, and a keyless free tier.

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 purpose and search semantics are front-loaded in the first clause; the returned-fields list and pricing are compact. The mandatory NVD endorsement disclaimer is boilerplate that costs a sentence, but the rest earns its place.

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

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

An output schema exists, so return-value detail is not required, yet the description still enumerates the key fields (CVSS, severity, CWE, known-exploited). Combined with annotations covering safety and the description covering pricing and data provenance, an agent has what it needs to call 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% (limit default/max, cve_id pattern and example, keyword length and example, api_key purpose), so the schema carries the parameter burden. The description adds no parameter syntax beyond what the schema already documents, matching the baseline 3.

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

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

States a specific verb ('look up'/'search') and resource (security vulnerability / CVEs), and clearly names both invocation modes (exact CVE id vs. keyword search). No sibling tool in the list covers CVEs, so it is trivially distinguishable.

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 two modes are named and the keyword example ('product, library, attack; newest first') hints at search semantics, but there is no explicit rule for choosing cve_id over keyword or any when-not guidance. Usage is implied rather than stated.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond those: the output fields returned, that results are live Google results, and the pricing model ($0.01 per successful call, failed calls free). It does not cover auth requirements or rate limits, but the cost disclosure is valuable.

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

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

Four short sentences, front-loaded with the core action and output, then scope, usage context, and cost. Every sentence carries distinct information and there is no waste.

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

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

For a straightforward web search tool with a full schema, rich annotations, and an output schema, the description covers purpose, output shape, scope, usage context, and cost. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds only marginal semantic detail ('any country or city' loosely maps to location), so the baseline of 3 is appropriate.

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

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

The description states a specific verb (Search), resource (the web), and output shape (title, URL, snippet as clean JSON), plus scope (live Google results, any country or city). It clearly distinguishes the tool from siblings like paper_search or read_page in practice, but does not explicitly name or contrast any sibling.

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

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

It gives a clear when-to-use condition: 'Use when you need current information, sources, or links.' This is direct context for selecting the tool, but it offers no when-not-to-use guidance or explicit alternatives among the many sibling tools.

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