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

With no annotations, the description must disclose behavior on its own. It states that it extracts all links, checks each one's HTTP status, and returns a report with broken links, redirects, and statistics. It does not mention rate limits or external-link handeling, but core behavior is transparent for a read-only checker.

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-load the purpose and then add mechanism and report contents without fluff. Every sentence earns its place.

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

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

For a simple two-parameter tool, the description covers purpose, behavior, and report contents, and an output schema exists. The missing timeout semantics and lack of alternative-routing guidance leave a measurable gap for correct invocation.

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

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

The schema has zero description coverage, so the description needed to compensate for both parameters. It only implies the URL via 'web page' and never explains the timeout parameter or its units, leaving the default 10 ambiguous.

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

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

The description names a specific verb ('Check') and resource ('web page') and explains that it inspects HTTP statuses of extracted links, which separates it from generic web_fetch/crawl tools. It does not explicitly name sibling alternatives, so it stops just short of a 5.

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

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

The intended use is clearly implied: use it when you need a broken-link audit of a page. It does not say when to prefer this over web_fetch, web_crawl, or content_quality, nor does it give exclusions, so the guidance remains implicit.

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

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

With no annotations, the description carries full burden. It discloses the action ('clear') and the return value (count), but does not warn about irreversibility or potential system impact. For a destructive operation, more cautionary detail is expected.

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

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

The description is a single, focused sentence that imparts both the action and the return value with no filler. It is perfectly concise for the tool's simplicity.

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

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

For a zero-parameter, simple operation, the description covers the action and result adequately. However, it omits any mention of side effects (e.g., performance degradation, need for re-fetching) or safety warnings, leaving a complete picture slightly lacking.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and no parameter information is omitted since the schema is empty.

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

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

The description clearly states a specific action ('Clear') on a specific resource ('all cached entries'), which is distinct from sibling tools like web_search or cache_stats. No ambiguity about the tool's function.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, contexts (e.g., when cache is stale), or warn against misuse. Sibling tool cache_stats exists but no differentiation is offered.

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 states the tool 'returns' statistics, implying a read-only operation with no side effects, but it does not explicitly affirm that it does not modify the cache, nor does it mention any access requirements or potential large payloads. The listed return fields add transparency, but the lack of explicit behavioral caveats keeps this at a passing but not exceptional level.

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

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

The description is a single, efficient sentence that front-loads the core purpose and then lists the specific statistics returned. Every word contributes value; there is 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?

Given the tool's simplicity (zero parameters, no annotations) and the presence of an output schema (which likely documents the return format), the description covers the essential behavior. It could be slightly more complete by explicitly stating that this is a read-only inspection and noting any prerequisites, but nothing critical is missing.

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

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

The input schema is empty (0 parameters), so there are no parameters to describe. Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter information because none exists, which is appropriate.

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

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

The description clearly specifies a verb ('return') and a resource ('cache statistics'), and enumerates exactly what is returned (entry count, total size, TTL, limits). It is unambiguously distinct from sibling tools like web_search or cache_clear, which are about web operations or cache clearing.

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 indicates the tool is for inspecting cache state, which provides clear context for when to use it (when cache statistics are needed). However, it does not explicitly mention alternatives or exclusions, though the distinct resource and zero parameters make usage fairly obvious without further 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 provided, the description carries the burden of behavioral disclosure. It states what the tool evaluates and that it returns improvement suggestions, which signals a read-only analysis. However, it does not mention any constraints (e.g., public URL requirement, JS-heavy page limitations) or explicitly confirm an absence of side effects, so some transparency is missing.

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

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

The description is brief and front-loaded with the core purpose, followed directly by the evaluation criteria. There is no redundant or filler content; 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?

Though the tool has only one parameter and an output schema supplies the return value shape, the description provides the key evaluative dimensions. It does not mention network prerequisites or usage boundaries, but these are not essential for a simple analysis tool. Overall, an agent can invoke it correctly with just a URL.

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

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

The schema has a single 'url' property with zero description coverage, so the description must compensate. It does so by naming the resource as a 'web page,' making the parameter's purpose clear. However, it does not specify URL format or expected scope, relying on common sense. This is sufficient for a simple parameter but not a robust semantic addition.

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

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

The description uses a specific verb ('Analyze') and resource ('content quality of a web page') and lists concrete evaluation dimensions (Flesch-Kincaid, Gunning Fog, keyword density, content structure, metadata quality). This distinguishes it from siblings like metadata_extract and web_extract, which focus on extraction rather than quality scoring.

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

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

The description clearly implies this tool is for content quality auditing of a web page, but it does not explicitly state when to choose it over siblings such as metadata_extract or web_extract, nor does it provide when-not-to-use conditions. It relies on the agent to infer usage context.

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

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

With no annotations provided, the description must carry the full behavioral burden. It clearly states what data is extracted, but it does not disclose operational traits such as network fetching behavior, caching, failure modes, or whether only static HTML is processed.

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

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

The description is two short, purposeful sentences. The first is a concise one-line summary, and the second adds a useful enumeration of what is extracted, with no filler or repetition.

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

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

For a single-parameter tool with an output schema, the core invocation is mostly covered. However, the description lacks usage boundary guidance relative to sibling tools and does not mention operational limitations, leaving some selection and invocation context incomplete.

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

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

The schema has 0% description coverage, and the description only says 'from a web page' without adding details about URL format, allowed schemes, encoding, or required forms. The parameter name 'url' is self-explanatory, but the description does not meaningfully compensate for the schema's silence.

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

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

The description opens with a clear verb-object statement, 'Extract metadata from a web page', and then enumerates the specific metadata types returned, including JSON-LD, OpenGraph, Twitter Cards, images, and links. This makes the tool's purpose precise and readily distinguishable from sibling tools like web_extract or web_fetch.

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 explicit when-to-use or when-not-to-use guidance is given, and no alternatives are mentioned. The specialized vocabulary implies this is for structured metadata extraction, but an agent receives no direct cue about how to choose between metadata_extract, web_extract, and web_fetch.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that the tool fetches feeds, supports specific formats, and returns a defined set of fields. It does not address failure modes, limits, or side effects beyond the network fetch, and it does not explain how max_entries affects the result. This is partial transparency.

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

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

The description is compact and front-loaded, with the core action in the first sentence and supporting details following. It is slightly repetitive when stating supported formats twice, but overall every sentence contributes.

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

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

The tool is simple, but the description omits any explanation of the max_entries parameter and offers no guidance on selecting the tool relative to siblings. The return fields are listed, and an output schema exists, so return semantics are covered. Overall it is adequate for a basic call but not fully complete.

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

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

The input schema provides only parameter names (url, max_entries) with no descriptions, and the description adds no parameter-specific meaning. There is no mention of what max_entries controls or the expected URL format. With 0% schema description coverage, this is a significant gap.

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 leads with a specific verb and resource: 'Parse an RSS or Atom feed and return its entries.' It further specifies supported formats (RSS 2.0, RSS 1.0, Atom) and output fields, making its function unmistakable and distinct from sibling web-fetching tools.

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

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

The description clearly frames the tool as the dedicated RSS/Atom parser, which implies the appropriate context. However, it does not explicitly state when to choose it over sibling tools like web_fetch or web_extract, nor does it mention exclusions or alternatives. The context is clear but guidance is implicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the exact content of the report (overall score, per-backend statuses, circuit breaker state, request statistics) and reveals the ordering behavior with active SearchService health first and legacy SearchEngine health as fallback during migration. It does not explicitly state that the operation is read-only, but as a health report this is strongly implied; the disclosed details go well beyond a minimal summary.

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

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

The description is concise and well structured: a one-line purpose, a sentence listing outputs and use case, and a final clarifying sentence about the migration fallback. Every sentence earns its place, and the core purpose is front-loaded in the first line 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?

For a zero-parameter health check with an output schema present, the description is complete. It states what the tool does, when to use it, what it returns, and includes relevant legacy migration context. The presence of an output schema means the description doesn't need to detail return structures, and it adds all necessary usage and behavioral context.

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

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

The tool has zero parameters and an empty input schema, so the baseline for this dimension is 4. The description doesn't need to explain parameters and correctly focuses on the tool's output and purpose. It adds no parameter-specific information because there is none, which is appropriate.

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

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

The description opens with a specific verb and resource: 'Get health report for all search backends.' This clearly states the tool's function and differentiates it from siblings like cache_stats, which target cache health rather than search backend health. The rest of the description enumerates concrete outputs, leaving no doubt about the tool's purpose.

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 explicitly says 'Use this to diagnose search failures,' providing a clear when-to-use context. It doesn't name alternatives or exclusions, but among the sibling tools there is no close alternative for search backend health, so the guidance is adequate without needing exclusionary language.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful details: concurrent fetching per depth level and robots.txt respect by default. However, it omits important behaviors such as how limits (max_pages, max_depth) are enforced, what happens on redirects or errors, and how same_domain_only is applied. Some behavior is disclosed, but the coverage is partial.

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

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

The description is two short sentences, with the core purpose front-loaded. The second sentence adds relevant behavioral details without fluff. Every phrase earns its place; 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?

For a crawl tool with six parameters, no annotations, and an output schema that is not explained, the description is thin. It does not cover how results are returned, how same-domain restrictions work, error handling, or how the crawl terminates. While the output schema exists, the description still lacks context about default behaviors and edge cases that an agent needs to invoke the tool safely and effectively.

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

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

The input schema has 0% description coverage, so the description must compensate by explaining parameter roles. The description only vaguely hints at depth and page limits ('respecting depth and page limits') and concurrency ('Fetches pages concurrently'), but does not explicitly define any of the six parameters: seed_url, extract, max_depth, max_pages, concurrency, or same_domain_only. This is minimal compensation for a schema with no descriptions.

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

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

The description clearly states the tool's action: 'Crawl a website starting from a seed URL, respecting depth and page limits.' The verb 'crawl' is specific and distinguishes it from siblings like web_fetch (single page) and web_search (query-based). No ambiguity about the resource or scope.

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

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

The description gives no explicit guidance on when to use web_crawl versus alternatives. It does not mention web_fetch, web_search, or other siblings, nor does it state conditions like 'use this for multi-page traversal or when you need to discover links.' The only implicit clue is the word 'crawl,' which is not enough for an agent to reliably choose it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the core action. It doesn't describe behavior for selectors that match nothing, whether the page must be pre-fetched/cached, rate limits, or error handling. For a network tool this is a notable gap.

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

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

A single efficient sentence with zero filler, front-loading the core purpose and mechanism. It earns its length, though it could have used its brevity to add a critical detail about the rules format.

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

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

The output schema covers the return format, but the tool has two required parameters, one of which (rules) has an unspecified format, no usage guidance relative to siblings, and no behavioral expectations. For a 2-param tool this is thin — the agent lacks enough to invoke it correctly on the first try.

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 0%, so the description must compensate. It tells us the tool uses CSS selectors (hinting at the rules parameter) and that url is the target page, but it doesn't specify the rules string format — is it a JSON mapping of field names to selectors, a list, or a single selector? This ambiguity puts the burden on the agent to guess.

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 (extract) + resource (web page) + mechanism (CSS selectors), and the phrase 'structured data' signals it differs from simply fetching raw content. This conceptually distinguishes it from siblings like web_fetch and web_crawl, which an agent could infer even without explicit sibling comparison.

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

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

No guidance on when to use web_extract versus web_fetch or web_search. The description doesn't state when extraction is preferable to a raw fetch, whether extraction works on JS-rendered pages, or any conditions under which a sibling should be chosen 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?

With no annotations, the description carries full burden. It only mentions fetching and optional extraction, but says nothing about caching (despite bypass_cache parameter), content truncation (max_chars), output format (output_format), or error behavior. The term 'return its content' is vague and omits behavioral details that would help an agent understand side effects or 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?

A single sentence that is front-loaded with the core action and includes a useful qualifier. No wasted words; appropriate length for the content provided.

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

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

Given 5 parameters, no schema descriptions, and no annotations, the description is drastically incomplete. It fails to cover output format, caching, truncation, or any operational constraints. An agent cannot safely invoke this tool correctly without additional undocumented knowledge.

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 0%, and the description fails to explain any parameters beyond the vague reference to extraction. It does not clarify what url, max_chars, bypass_cache, or output_format do, leaving the agent to rely solely on parameter names and defaults, which are insufficient for correct usage.

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?

Clearly states a specific action (fetch a URL), the resource (URL), and the outcome (return its content) with an optional behavior (extracting the main article). This distinguishes it from sibling tools like web_search (search) and web_crawl (multiple pages).

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

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

No guidance on when to use this tool instead of alternatives like web_crawl or web_extract. The 'optionally extracting the main article' hint is only about a parameter, not about selecting this tool over others. Lacks exclusions or recommended contexts.

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

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

With no annotations, the description must carry behavioral disclosure on its own. It reveals that Bing is tried first, DuckDuckGo is a fallback, and no API key is needed—useful behavioral traits. However, it does not describe the output format (beyond 'structured results'), error behavior, pagination, or rate limits. It adds some value but is not comprehensive, so a 3 is appropriate.

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

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

Two sentences with zero filler. The core action is front-loaded, then the fallback and no-key facts are added efficiently. Every word earns its place; this is a model of concise writing.

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

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

Given the tool has 4 parameters (1 required), no annotations, and an output schema, the description is incomplete. It fails to explain parameter meanings/format, does not guide tool selection relative to siblings, and does not describe the structure of results explicitly. While the output schema may cover return format, the absence of usage guidance and parameter semantics leaves an agent under-informed.

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 0%, so the description must compensate for all parameter ambiguity. It does not mention query, region, max_results, or safe_search at all. An agent gets no hint about what 'region' expects (e.g., language/country code) or the meaning of safe_search beyond its name. This is a significant gap.

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

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

The description clearly states the verb ('Search') and resource ('the web'), and adds 'return structured results,' which is specific and distinguishes it from fetch/crawl/extract siblings. However, it does not explicitly name any sibling or contrast with alternatives, so it does not fully earn a 5.

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

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

No explicit guidance on when to use this tool versus the sibling tools (web_fetch, web_crawl, web_extract). There is no mention of prerequisites, exclusions, or scenarios where this tool is inappropriate. The context is only implied by the name, so the description does not help an agent decide between alternatives.

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