WebLens

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

With no annotations, the description carries the full burden and does disclose real behavior: it performs a multi-step search/fetch pipeline, answers strictly from retrieved sources (a grounding constraint that affects trust in the output), formats inline citations, and surfaces a $0.05 price. Missing are latency expectations, failure behavior when no sources are found, and any auth requirement.

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 compact clauses with zero filler: the capability and output format lead, followed by the cost disclosure. Every element (grounding, citation format, price) earns its place and the most decision-relevant facts come first.

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

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

For a 2-parameter tool with no output schema and no annotations, the description covers what it does, how the output is cited, and the cost. It stops short of positioning against deep_research or explaining what happens on low-quality/empty source results, which is the main remaining 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 'query' and 'sources' are already fully documented with type, bounds, defaults, and examples. The description adds only the generic notion of fetching sources and no syntax or format 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 (answers a question) plus the mechanism (searches the web, fetches sources, answers strictly from them) and the output shape (inline [n] citations). This distinguishes it from raw retrieval siblings like search_web or fetch_webpage, but it never explicitly contrasts itself with deep_research, the closest-looking alternative.

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

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

Usage is implied — reach for this when you want a synthesized, cited answer rather than raw pages — but there is no explicit when-to-use statement, no exclusions, and no named alternative such as deep_research or search_web. The agent must infer the routing decision from the sibling list 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?

With no annotations, the description carries full burden and does well on provenance: it discloses live reading, per-field source pages, the security.txt restriction to role mailboxes/company pages, and an explicit $0.05 price with 70% cache discount. It says nothing about rate limits, failure modes when a site blocks fetching, or partial-result behavior, which matters for a multi-source live scrape.

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

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

A single dense sentence plus a pricing line; every clause enumerates a distinct returned field, so little is wasted. The core purpose is front-loaded, though the field list is long enough that the price information trails at the end.

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 must describe return values, and it comprehensively enumerates the fields plus notes that each AI-read field names its source page. Missing only failure/partial-result behavior for a live multi-source scrape.

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 domain, cache and cacheTtl are already fully documented, and the description reinforces only the cache discount. The description adds essentially no syntax or semantics beyond the schema, which sets the baseline at 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 resource (company profile from a domain) and enumerates exactly what is returned, so an agent can tell it apart from generic fetch tools. It does not explicitly name the closest siblings (domain_intel, detect_tech, project_due_diligence), which overlap on registrar/tech/SPF data.

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

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

The scope ('read live from its own site') implies when it is appropriate, and the cache/price note hints at a cost tradeoff, but there is no explicit when-to-use guidance or exclusion of alternatives. An agent must infer that this is the aggregate profile call rather than a targeted lookup.

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

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

With no annotations the description carries the full burden and does well: it discloses the traversal strategy (same-host BFS), hard limits (depth, page budget), the robots.txt policy and its override, and a per-page cost plus an x402 payment floor. It stops short of describing error/timeout handling or what happens when the budget is exhausted.

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 opening is front-loaded and tight, but the pricing sentence is duplicated almost verbatim ('$0.0015 per requested page (1-25). Price: $0.0015 per requested page (1-25)...'), which wastes space and reads as boilerplate concatenation.

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 an 8-parameter mutation-free crawl tool with no annotations and no output schema, the description covers traversal semantics, cost, and robots policy well. Return shape is briefly covered ('clean markdown for every page') but pagination, partial-failure behavior, and auth mechanics around x402 are left unaddressed.

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

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

Schema description coverage is 100%, so every parameter including limit, maxDepth, include/exclude and respectRobots is already documented in the schema. The description only restates the per-page price and the 1-25 range, adding no syntax or behavioral nuance beyond what the schema provides.

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

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

States a specific verb (crawl) and resource (site) plus the concrete payoff ('clean markdown for every page, in one call'), so the bulk-crawl intent is unmistakable. It never names the obvious siblings (fetch_webpage for a single page, map_site for URL discovery), so the differentiation is left implicit.

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

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

Usage is implied by the scope ('every page, in one call', same-host BFS) and the depth/page-budget limits, which tell an agent this is the batch option rather than a single fetch. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the 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?

No annotations exist, so the description carries the full burden, and it does disclose the internal pipeline, the synthesized output structure, and per-tier cost/effort. Gaps remain around latency (multi-step search is presumably slow), timeouts, and failure behavior, so it is not fully transparent.

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

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

The tier/price block is duplicated verbatim within the same description ('Tiers: ...' immediately followed by 'Price: ...' with identical content), which is wasteful and makes the description feel machine-assembled. The opening pipeline sentence is strong and front-loaded, but the redundancy is a clear structural flaw.

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 describe the return shape (citations, key findings, gaps), which is the key missing piece for a research tool. Cost and effort tiers are complete. Only latency/error expectations are absent, a minor gap for a 2-parameter 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 the description's tier breakdown is verbatim identical to the depth parameter's schema description, adding no new meaning. The query parameter gets no elaboration beyond the schema's example. Baseline 3 applies.

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

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

Specific verb chain (plans, searches, fetches, dedupes, synthesizes) and resource (multi-step research) that an agent can distinguish from single-shot siblings like search_web or answer_question. The output artifact is also named (inline [n] citations, key findings, gaps), so the tool's identity 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?

Tier selection is well covered (quick/standard/deep with cost and effort), but there is no guidance on when to reach for deep_research versus answer_question or search_web. Usage is implied by the name and pipeline description rather than stated with alternatives or exclusions.

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

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

With no annotations, the description carries the full burden. It usefully discloses that results come from a single fetch and includes the proving marker (header or HTML tag) for each detection, plus the $0.005 price. It omits failure modes, auth requirements, and behavior on obfuscated/CDN-fronted sites, leaving meaningful gaps.

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 sentence with the capability front-loaded, the evidence mechanism stated, and the price appended. No filler and nothing that fails to earn its place.

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

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

For a single-parameter, no-output-schema tool, the description gives enough to invoke correctly and previews the kind of returned data. It stops short of describing the response shape or result reliability, but nothing critical for a correct call is missing.

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

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

Schema coverage is 100%, so the single 'url' parameter is already documented as the site URL to fingerprint. The description adds no parameter-level detail (e.g., http vs https handling, redirect following), so the baseline 3 for schema-driven coverage 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 names a specific capability (fingerprinting a site's tech stack) and enumerates the exact categories detected: frameworks, CMS, ecommerce, CDN, analytics, payments, widgets, web server. This clearly separates it from generic siblings like fetch_webpage or crawl_site, which retrieve raw content rather than a technology inference.

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

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

Usage is implied: the agent infers you call this when it needs to know what a site runs on, and 'from a single fetch' hints that no crawl is required. However, there is no explicit when-to-use/when-not framing and no naming of an alternative sibling, so guidance remains inferred 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?

No annotations are provided, so the description carries the full burden; it does disclose the exact data returned (registration fields, DNS record types, derived providers, risk signals) and notably the cost ('$0.005'), which is genuine behavioral context. It stops short of describing response format or any rate/limit behavior, keeping it from 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 front-loaded sentence that leads with the value proposition and then delivers a dense but all-relevant enumeration of outputs, closing with the price. Every clause earns its place; nothing is redundant.

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

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

With no output schema, the description must describe return values, and it does so thoroughly by listing each category of intelligence returned. It is nearly complete for a one-parameter read tool, though it omits any note on response structure or granularity.

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

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

Schema description coverage is 100% and the single parameter (domain) is already fully documented in the schema, including the URL-to-hostname normalization behavior. The description adds no parameter-specific 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+resource ('Domain intelligence in one call') and enumerates the exact data domains it returns: RDAP registration, live DNS, providers, SaaS vendors, SPF/DMARC posture, and risk signals. This lets an agent distinguish it from siblings like detect_tech or company_profile 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 only implied by 'in one call,' which suggests a comprehensive one-shot lookup, but the description never states when to prefer this over detect_tech, company_profile, or other siblings, nor any prerequisites. No explicit when/when-not or alternatives are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses cost ($0.03, up to 3x on bot-protected or complex sites) and that extraction is AI-powered with page-context understanding, but says nothing about authentication, rate limits, failure behavior, or what happens to pages it cannot render.

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, mechanism, and cost, with the core capability front-loaded. No filler, and the pricing caveat is placed after the value proposition.

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-parameter tool with no annotations and no output schema, the description covers purpose, mechanism, and cost but never states the return shape (structured JSON matching the supplied schema is only implied) or error behavior. Nested-object input and AI-driven extraction would benefit from a note on expected output.

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 url, schema, and instructions are already documented in the schema, and the description adds no syntax or format detail beyond them. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (extract) and resource (structured data from a webpage) plus the key mechanism (JSON schema), which separates it from plain fetch tools like fetch_webpage or get_contents. It never names a sibling, so the differentiation is implied rather than explicit.

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

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

The description conveys the extraction scenario but gives no when-to-use routing against siblings such as fetch_webpage, get_contents, crawl_site, or extract_pdf, and no prerequisites. The price mention hints this is a metered/premium call but does not say when that cost is warranted.

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

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

No annotations are provided, so the description carries the disclosure burden. It usefully states that it returns structured content and discloses a price ($0.004), which is real behavioral context. However, it omits limits (file size, page count), auth or URL constraints, and failure behavior for an external-URL-driven tool.

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

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

Three short sentences, front-loaded with the core purpose before the optional capability and pricing. Every sentence carries distinct information with no redundancy 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?

No output schema exists, so the description's vague 'returns structured content' is the only return-value signal and leaves the structure undefined. With only two simple parameters and no annotations, the description is adequate but does not address extraction limits or error behavior an agent would need.

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

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

Schema description coverage is 100%, so both 'url' and 'pages' are already documented in the schema. The description's reference to 'page-specific extraction' aligns with the pages parameter but adds no syntax or default detail beyond the schema's own 'omit for every page' note. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Extract text and metadata from PDF documents', which clearly identifies the operation and input type. It distinguishes itself from generic siblings like extract_data or get_contents by scoping to PDF documents, though it doesn't explicitly name an alternative. Clear and 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?

No guidance on when to choose this over siblings such as extract_data, get_contents, or fetch_webpage. The mention of 'page-specific extraction' hints at a use case but provides no conditions or exclusions for selecting this tool. The agent must infer usage entirely.

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

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

With no annotations, the description carries the full burden and does well: it discloses the escalation sequence, that the response reports which tier served it, and full cost mechanics ($0.008 base, 70% cache discount, $0.004 x402 payment floor). It stops short of stating auth mechanics, error/retry behavior, or rate limits, but the cost and latency-relevant context is unusually thorough.

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, front-loaded with the core behavior before the pricing detail. Each sentence carries distinct information (mechanism, fallback trigger, cost). The pricing sentence is dense but not redundant with the schema's cache description.

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

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

For a 5-param tool with no annotations and no output schema, the description covers what it does, how it escalates, what the response signals, and what it costs. Remaining gaps (error handling, auth flow, response shape beyond the tier field) are minor but real, so it falls short of fully self-sufficient.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including cache pricing and the Pro-tier restriction on waitFor. The description reinforces the cache discount and tiering but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate 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+resource ('resilient fetch') and immediately explains the mechanism: native scraper first, headless Chromium fallback. An agent understands it is a scraping fetch with tiered escalation. It does not explicitly name the siblings it overlaps with (fetch_webpage, fetch_webpage_pro, get_contents), so differentiation is left to inference.

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

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

It describes the conditions that trigger the fallback tier (client-rendered pages, sites refusing bare HTTP clients), which implies when this tool is the right pick. However, it never tells the agent when to choose this over fetch_webpage or fetch_webpage_pro, nor when not to use it. Usage is implied rather than directed.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits beyond schema: a static-only, no-JS rendering limitation, a speed claim, and an explicit cost model including the x402 payment minimum. It omits failure/retry and redirect behavior, but the cost disclosure is genuinely useful for a paid tool.

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

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

Three short sentences, front-loaded with the core purpose and output format before the cost note. The pricing detail is relevant for a metered tool and does not feel padded, though it is stated twice (per-call and per-cache).

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

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

For a tool with no output schema and no annotations, the description covers purpose, output format, static-content limitation, and cost sufficiently to call it correctly. Remaining gaps (failure modes, whether redirects are followed) are minor for a fetch-and-convert utility.

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 documented in the schema. The description adds no parameter-level syntax or format detail, so the baseline of 3 applies. The schema's 'waitFor (Pro tier only)' note is not reconciled by the description.

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

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

States a specific verb+resource (fetch a webpage) and the output transformation (convert to clean markdown), which is more than a restatement. It also scopes itself with 'no JavaScript rendering,' implicitly differentiating it from the JS-capable siblings like fetch_webpage_pro, though it names no sibling explicitly.

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

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

'Perfect for static content, articles, and documentation' implies when to use it, and 'no JavaScript rendering' implies the exclusion of JS-heavy pages. However, no alternative tool is named for those excluded cases, so the routing is left to inference.

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

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

With no annotations, the description carries the full burden and does disclose a genuinely actionable trait: a per-call cost model ($0.006 base, up to 3x on bot-protected sites, 70% cache discount, x402 minimum). This lets an agent reason about budget before calling. It still omits what the response contains (raw HTML vs. extracted text) and failure/timeout behavior, so it is not complete.

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 a targeted use-case list and then pricing. Every sentence carries information an agent can act on; the pricing sentence is dense but earns its place for cost-aware routing.

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

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

For a 5-parameter tool with no annotations and no output schema, the description covers purpose and cost but says nothing about the return format or what happens on render failure/timeout. The schema covers inputs fully, but the agent is left guessing at the output contract.

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% – every parameter including cache, timeout, waitFor, and cacheTtl is documented in the schema itself. The description adds no parameter-level syntax or constraint detail beyond reinforcing the cache discount already stated in the cache property. 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 ('Fetch webpage') and immediately distinguishes itself by mechanism ('full JavaScript rendering using headless browser'), which is the key differentiator from plain fetch siblings. However, it never names or contrasts with fetch_webpage or fetch_resilient, so the agent must infer which sibling to prefer.

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?

'Perfect for SPAs, React/Vue apps, and dynamic content that requires JS execution' implies when this tool is the right choice, giving usable context. But there are no explicit exclusions or named alternatives (e.g. 'use fetch_webpage for static HTML'), leaving the routing decision to inference.

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

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

With no annotations, the description carries the full burden and does disclose useful traits: markdown output, per-page truncation, and per-URL pricing with an x402 floor. It omits auth requirements, failure modes, and whether truncation is lossy vs. flagged, so it is only partially transparent.

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

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

The first sentence is well front-loaded, but pricing is stated redundantly: '$0.0015 per URL' appears and is then immediately restated as 'Price: $0.0015 per URL (1-20).' That duplicated sentence dilutes otherwise tight prose.

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

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

For a 3-param tool with no output schema and no annotations, the description covers output format and cost but leaves selection among the many fetch/crawl siblings ambiguous. It is adequate but not complete for the surrounding tool set.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by implying the per-page cap (maxChars) and the 1-20 URL bound, but says nothing about the timeout parameter beyond what the schema documents.

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 URLs, get clean markdown) with scope (1-20 URLs) and the word 'bulk,' which implicitly distinguishes it from the single-page fetch_webpage siblings. However it never names those siblings, so differentiation is left to inference.

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

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

The '1-20 URLs' and 'bulk' framing implies this is for multi-page fetches rather than single pages, but there is no explicit when-to-use, when-not, or named alternative among fetch_webpage, fetch_webpage_pro, fetch_resilient, or crawl_site.

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

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

With no annotations, the description carries the full burden, and it does disclose real mechanism: robots.txt sitemap directives, sitemap.xml, nested sitemap indexes, and homepage link-extraction fallback, plus a price. It omits failure behavior, rate limits, and whether results are deduplicated or sorted.

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 plus a price tag; the core capability is front-loaded and the fallback chain is compressed into one clause 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?

No output schema exists, but the return is self-evident from the name and the 'limit'/'Maximum URLs to return' parameter. Given full schema coverage and no annotations, the description covers what an agent needs to call it correctly, though it never states the response shape explicitly.

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 (url, limit, exclude, include, timeout) are already documented in the schema. The description adds no syntax or filtering nuance beyond that, so baseline 3 applies.

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

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

Specific verb+resource: 'Discover a site's URLs.' The phrase 'without fetching page content' implicitly distinguishes it from fetch/crawl siblings, which is genuinely useful differentiation. However, it never names crawl_site, the closest sibling, so an agent must infer the boundary itself.

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 'without fetching page content' but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. crawl_site for full-page content). An agent can guess the intent but gets no 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior beyond the schema: it enumerates the returned signals, confirms it is a read-style lookup, and adds cost/payment semantics ('Price: $0.003; an x402 payment is at least $0.004') that an agent cannot get from structured fields. It stops short of covering failure modes (unknown package, unsupported registry) 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?

Front-loaded with the decision question, then a compact payload list, then pricing. Efficient overall, though the payment sentence is slightly ambiguous ('an x402 payment is at least $0.004') and could be trimmed or clarified.

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

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

There is no output schema, so the description correctly takes on the job of describing return contents, and it does so thoroughly for a two-parameter tool. The gaps are edge behavior (invalid package, unsupported registry) and any auth nuance behind the x402 payment mention.

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 only two parameters, so the baseline is 3. The description's 'npm or PyPI' wording reinforces the registry parameter's meaning but adds no format, default, or syntax detail beyond the schema.

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

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

The opening question 'Should you depend on this package?' frames a specific decision, and the enumerated payload (version, license, deprecation reason, downloads, release date, maintainers, npm scores, health signals) makes the resource and scope unambiguous. It also pins the two supported registries ('npm or PyPI, one call'), so an agent knows exactly what it retrieves versus unrelated siblings like search_web or company_profile.

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 framing question implies the use case (evaluating a dependency before adopting it), but there is no explicit when-not guidance, no prerequisites, and no mention of alternative tools for adjacent needs. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses cost (free), why live runs are restricted (would burn upstream credits), that previews are truncated/summarised, and that output may be a recorded sample rather than live. It stops short of covering auth needs or rate limits, but the behavioral profile is otherwise rich.

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

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

Front-loaded with 'FREE' and the core purpose, then dense but purposeful detail. Every sentence carries information; the endpoint-class distinction is a long clause but earns its place. Slightly heavy for a preview tool, but not padded.

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

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

No output schema exists, so the description must explain return values, and it does: price, summary, and response-shape sample. Combined with the live-vs-recorded distinction, an agent has what it needs to call and interpret the tool, though it could note any pagination or size limits.

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, but the description adds real meaning by tying the url parameter to live-preview behavior for fetch-backed endpoints and the domain parameter to /domain summarised previews. It clarifies the conditional semantics the schema only hints at.

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 (preview) and resource (endpoint), and precisely enumerates what the tool returns: live price, one-line summary, and a recorded sample of the response shape. It is clearly distinguishable from all the paid sibling endpoints it previews.

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 frames the use case ('before paying') and then goes further, splitting endpoints into two behavioral classes: fetch-backed ones (/fetch/basic, /contents, /map) that run a live truncated preview, versus SerpAPI/Anthropic-backed ones that return only the recorded sample. That is exactly the when/when-not routing an agent needs.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation is read-only ("Reads nothing on-chain"), names the output shape (weighted risk signals and an A-F grade), and discloses cost ($0.05). It stops short of permissions, rate limits, or latency expectations.

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

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

A single dense sentence with an em-dash, front-loading the core purpose before enumerating the checks. It is information-rich without padding, though the length and clause density push it slightly past the ideal.

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 composite screening tool with no output schema and no annotations, the description supplies the essential missing context: what is inspected, that it is off-chain only, the return format, and the price. An agent has enough to select and call it correctly; only auth/rate-limit context is absent.

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

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

Schema description coverage is 100%, so the schema already documents domain, chain, and tokenAddress thoroughly. The description reinforces how tokenAddress is used (cross-check against addresses printed on the site), but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb and resource — off-chain due diligence on a project's web presence — and enumerates exactly what is inspected (domain age, team page, whitepaper, docs, socials, template detection, address cross-check). It clearly distinguishes itself from on-chain rug checkers, but it does not differentiate from web-oriented siblings like domain_intel, detect_tech, or crawl_site, which overlap in surface.

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

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

Usage is implied rather than stated: "the contract address you are about to trade" signals a pre-trade screening context, and the composite scope hints at when the full package beats single-purpose tools. However, there is no explicit when-to-use/when-not and no named alternative among the many overlapping web tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the mechanism (headless browser) and the price ($0.008), which is valuable, but says nothing about the return format (image URL vs. binary), authentication, or failure behavior for a tool with six parameters.

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

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

Two short sentences, front-loaded with the core action and ending with the pricing detail. Nothing redundant, though the pricing clause occupies the slot a usage hint would fill more usefully.

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?

Six parameters, no annotations, and no output schema. The description omits the most consequential unknown for a screenshot tool: what the caller actually receives (image URL, base64 payload, or file reference). For a tool with no output schema, that gap matters.

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 every parameter is already documented in the schema with types, bounds, and defaults. The description adds no syntax or interpretation beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (capture screenshots) and resource (webpage), so the purpose is immediately clear. It does not, however, distinguish itself from siblings like fetch_webpage, preview_endpoint, or get_contents, which an agent must disambiguate before choosing.

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

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

The description gives no when-to-use guidance, no conditions, and no alternatives. An agent must infer that this is the tool for rendering a page visually rather than fetching its contents.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a price ($0.015), but says nothing about region/language localization of suggestions, return format, or rate limits — meaningful gaps for a lookup tool with zero annotation coverage.

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

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

Three short sentences, purpose front-loaded, usage second, cost last. Every sentence carries information and nothing is wasted.

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

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

For a two-parameter, no-output-schema lookup tool, the description covers what it does, when it helps, and what it costs. The remaining gaps (localization behavior, response shape) are modest given the tool's simplicity.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the baseline is 3. The description's phrase 'partial query' does add nuance beyond the schema's generic 'Search query', nudging toward a prefix-style input, but it does not clarify limit behavior or max length.

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 Autocomplete suggestions') and clarifies the input is 'a partial query', which distinguishes it from full-query tools like search_web. It does not explicitly name a sibling, so an agent must infer the boundary itself.

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?

'Useful for keyword research and intent discovery' gives a use context, but there is no when-not guidance and no reference to neighboring tools such as search_trends or search_web. Usage is implied rather than prescribed.

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

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

With no annotations, the description carries the full burden and does well: it enumerates return contents (stories, points, comment counts, thread links, aggregate totals, top domains, first/last discussion time) and even discloses cost ($0.004). It stops short of stating rate limits, auth needs, or failure modes, keeping it from 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 front-loaded sentence leads with the resource and value, then enumerates outputs and appends the price. It is efficient with little waste, though the aggregate 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?

There is no output schema, so the description appropriately describes the return payload in detail and adds pricing. For a read-only search tool with full schema coverage, this is nearly complete; only rate-limit or permission behavior is left unstated.

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

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

Schema description coverage is 100%, so query, sort, and limit are already fully documented in the schema. The description adds no parameter syntax or format meaning beyond that, so the baseline of 3 applies.

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

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

The description states a specific resource (Hacker News stories/discussions) and what is retrieved (matching stories with points, comment counts, thread links, plus aggregates). It clearly distinguishes itself from generic siblings like search_web or search_news by scoping to Hacker News, though it never names those alternatives.

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

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

Usage is implied by the topic ('What Hacker News said about a topic'), but there is no explicit when-to-use guidance, no when-not-to-use, and no routing to alternatives such as search_news for general news or search_web for the broader web.

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

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

With no annotations, the description carries the full burden. It does disclose the return shape (direct image URLs with dimensions, thumbnails, source pages) and the per-call cost ($0.015), which are genuinely useful behavioral facts, but it says nothing about rate limits, auth requirements, or pagination beyond the limit parameter.

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

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

Two short sentences, front-loaded with what the tool is and what it returns, followed by the cost. Nothing is padded and nothing important is buried.

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

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

With no output schema and no annotations, the description adequately covers the two things an agent most needs: the return contents and the price. It is thin on safety profile (read-only is only implied) and lacks any routing guidance versus sibling search tools, but for a 2-parameter read call it is largely sufficient.

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

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

Schema description coverage is 100%, so both parameters (query, limit) are already documented in the schema. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Google Images search') and immediately says what it returns, which cleanly separates it from the other search_* siblings like search_web and search_news. It does not explicitly name an alternative, but the resource qualifier makes the domain 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?

There is no when-to-use guidance, no statement of when to prefer this over search_web or screenshot, and no prerequisites. Usage is only implied by the word 'Images'; an agent must infer the routing decision itself.

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

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

With no annotations, the description carries the full burden. It does add real behavioral value by disclosing the return shape (ranked articles with source, date, thumbnail) and a per-call price ($0.015), but says nothing about authentication, 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?

Three tight sentences: purpose first, return contents second, cost last. No filler and nothing an agent has to wade through.

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 steps in to describe the return payload (ranked articles with source, date, thumbnail). Params are fully covered by the schema. Only auth/rate-limit context is missing, which is minor for a 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% — both query and limit are documented in the schema, including the limit's min/max bounds. The description adds no parameter detail beyond 'search', so the baseline 3 is appropriate.

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

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

States a specific verb and resource (news search) and names the underlying source (Google News), which naturally separates it from search_web, search_scholar, and search_images. It never explicitly names or contrasts a sibling, so it falls just short of the top tier.

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 says nothing about when to choose this over search_web or the other search siblings, nor about any prerequisites or exclusions. 'Real-time news search' implies a use case but gives no explicit 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?

With no annotations, the description carries the full behavioral burden. It helpfully discloses the returned fields and the per-call cost ($0.045), which is real added context, but it says nothing about auth requirements, rate limits, error behavior, or whether results are paginated.

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

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

Three short front-loaded sentences covering purpose, return content, and price, with no filler. Slightly terse, but every sentence 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?

Since there is no output schema, the description appropriately enumerates return fields, and it discloses cost. It is nearly complete for a simple 3-parameter search, though it omits result-shaping details like whether 'limit' caps the count and how many results a single call can return.

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 all three parameters (query, location, limit) documented including examples and bounds, so the baseline is 3. The description adds no param-level detail 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 (search) and resource (local businesses via Google Local), and enumerates the return fields, which clearly separates it from siblings like search_web, search_news, and search_images. It never explicitly names those siblings as alternatives, so it stops just short of full differentiation.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing ('use search_web instead for general pages'). Usage is only implied by the phrase 'Local business search', leaving the agent to infer that this is for physical places.

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

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

With no annotations, the description carries the full burden. It usefully discloses the return shape (snippets, publication info, citation counts) and a per-call price of $0.015, which is real behavioral value. However, it omits rate limits, authentication needs, pagination, and the 20-result cap, so a mutation-free read tool still leaves notable gaps.

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

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

Three short sentences with no waste: purpose, return contents, and cost. The core capability is front-loaded and each sentence earns its place.

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

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

For a simple two-parameter search with no output schema, the description covers purpose, return contents, and cost adequately. It lacks guidance on the limit cap or result-quality caveats, but 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 both 'query' and 'limit' are already documented in the schema, and the description adds no syntax, format, or constraint detail beyond that. Baseline 3 is appropriate 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+resource ('Google Scholar academic search') and lists what the results contain, which separates it from the generic search_web/search_news siblings by scope. It does not name a sibling directly, so it falls just short of the 5 bar.

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

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

Usage is only implied by the word 'academic' — an agent can infer this is for scholarly literature rather than general web queries. There is no explicit when-to-use, when-not, or routing to alternatives such as search_web or deep_research.

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

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

With no annotations, the description carries the full burden. It does disclose two genuinely useful behavioral traits: the return shape (prices, sellers, ratings, links) and the per-call cost ($0.015). It says nothing about rate limits, auth requirements, or result pagination beyond the schema's own limit cap.

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

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

Three short sentences, front-loaded with what the tool is, then what it returns, then what it costs. Every sentence earns its place and nothing is padded.

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

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

For a two-parameter search tool with no output schema, the description covers purpose, return fields, and cost — enough for an agent to call it correctly. The remaining gap is routing guidance relative to the many sibling search_* tools, plus pagination behavior at the 20-result cap.

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 only two parameters, both documented in the schema including the limit maximum of 20. The description adds no syntax, format, or interpretation guidance for query or limit, 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 combination ("Google Shopping product search") that is immediately distinguishable from search_web, search_images, and search_places. It never names a sibling or states its distinguishing boundary explicitly, but the domain qualifier does the disambiguation work implicitly.

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

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

No when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer this over search_web for product queries, or whether it covers local/in-store pricing the way search_places might. Usage must be inferred entirely from the word "Shopping" in the purpose statement.

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

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

No annotations are provided, so the description carries the full burden and does add real context: the 0-100 relative normalization (peak=100), worldwide geographic scope, and an explicit price of $0.04. It omits latency/caching behavior, time-range or granularity limits, and failure modes, which keeps it from a 5.

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

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

Three sentences, front-loaded with what it returns and its scale, then when to use it, then cost. Every sentence earns its place with no 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 no output schema, the description appropriately explains the return value (per-period relative interest scale) and scope. For a single-parameter tool this is nearly sufficient, though it could say more about the time window returned and data resolution.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already documents 'query' fully. The description's mention of product/technology/brand/keyword and worldwide scope adds marginal framing but no syntax, format, or constraint detail beyond the schema.

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

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

States a specific verb+resource ('Google Trends interest over time for a topic') and pins the scope ('worldwide') plus the metric semantics ('timeline of relative search interest per period, 0-100'). This makes it clearly distinguishable from sibling search_web/search_news despite no explicit sibling naming.

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 see whether interest in a product, technology, brand or keyword is rising, falling or seasonal' gives a concrete when-to-use with example query domains. It stops short of naming alternatives (e.g. search_web for current results) or stating when this tool is the wrong 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?

With no annotations, the description carries the full behavioral burden; it usefully discloses the cost model ($0.015 base, $0.0015 per fetched page) and the return contents, which is real value beyond the schema. It omits rate limits, auth/quota behavior, ranking guarantees, and any failure modes, so the disclosure is partial rather than complete.

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 compact sentences, front-loaded with purpose then return shape then the includeContent condition then pricing; no filler. The pricing sentence is information-dense but earns its place given no annotation coverage.

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

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

There is no output schema, so the description correctly supplies the return shape (ranked titles/URLs/snippets, markdown pages when includeContent is set) and the cost implications. For a five-parameter read tool with no annotations, this is nearly complete; only routing relative to sibling search tools 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 five parameters are already documented structurally; baseline is 3. The description's mention of includeContent semantics and contentResults implicitly duplicates what the schema already states, adding no syntax or format detail beyond it.

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

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

States a specific verb+resource ('Real-time web search powered by Google') and the return shape (titles, URLs, snippets), so the agent knows what it does. However, it never distinguishes itself from the many sibling search tools (search_news, search_scholar, search_discussions, search_images), leaving the generic-vs-specialized boundary implicit.

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

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

It gives one conditional instruction — 'Set includeContent to also fetch the top result pages' — which tells the agent when to toggle a parameter. But there is no guidance on when to choose this tool over search_news, search_scholar, or answer_question, which is the primary routing decision among these siblings.

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

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

With no annotations, the description carries the full burden, but it does add two real behavioral facts: the output includes timestamps and the call costs $0.03. It omits error conditions (missing/disabled captions), rate limits, and whether the operation is read-only (implied but not stated).

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

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

Three short sentences, each earning its place: output shape, accepted input, and price. Front-loaded with the core purpose and 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?

There is no output schema, so the description should characterize the return payload, and it gives only a minimal hint ('full transcript with timestamps') without format, structure, or handling of missing transcripts. For a tool with no annotations and no output schema, this is adequate but leaves gaps.

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

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

Schema coverage is 100%, with both videoId and lang fully documented, so the schema does the heavy lifting. The description's 'Accepts a video ID or any YouTube URL' reinforces the videoId flexibility but adds no meaning beyond the schema baseline.

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

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

States a specific resource (YouTube video transcript) and verb-like action (returns the full transcript), plus scope 'any YouTube video' and format 'with timestamps'. It is unambiguous, though there is no sibling YouTube tool to distinguish it from, so the differentiation dimension is moot.

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

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

The description never says when to use this tool versus alternatives, nor any prerequisites (e.g. video must have captions). It only describes what the tool returns, leaving the agent to infer applicability on its own.

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