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

With no annotations, the description carries the full burden and does meaningful work: it discloses the fallback behavior, the 3-URL cap, that return shape stays a list, and that successes gain an output_file key. It omits failure/partial-failure semantics and any auth or rate-limit context, which keeps it below 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?

Two tight sentences, front-loaded with the core action and limit, then the persistence/return-shape contract. No filler and no restatement of the tool name.

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

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

An output schema exists and the 8 parameters are fully documented, so return values need not be re-explained; the description covers the limits and the persistence contract well. What's missing is routing guidance against the many sibling crawl/search tools.

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

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

Schema description coverage is 100% and the schema descriptions are unusually thorough (overwrite error semantics, output_path rejection rules, include_content_in_response token tradeoff). The description restates output_path persistence and adds the output_file key detail, but adds little beyond what the schema already 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 ('Crawl multiple URLs') plus a distinguishing trait ('with fallback') and a hard limit ('Max 3 URLs per call'). It does not name the nearest siblings (multi_url_crawl, batch_search_web, deep_crawl_site), so the agent must still infer which batch tool to pick.

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 an actionable usage cue for output_path ('Use output_path (directory) to persist...') and a size constraint, which implies the batch-of-few use case. But there is no explicit when-to-use/when-not versus multi_url_crawl or deep_crawl_site, and no stated prerequisites.

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

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

Beyond the readOnlyHint annotation, the description discloses that passing output_path causes per-video .md files plus index.json to be written and changes the response shape — behavior an agent cannot see from the schema annotations. The schema adds overwrite=false rejection and failed-item recording, and the description summarizes the persistence behavior well. Note the mild tension: filesystem writes are disclosed while readOnlyHint=true, but since persistence is strictly opt-in and the default call is a pure read, this is disclosed rather than contradicted.

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, zero filler, with the hard constraint (max 3 URLs) and the highest-leverage optional behavior (output_path) placed early. Every sentence carries information the agent needs to act.

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

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

An output schema exists, so return values need not be explained, and the description covers the batching limit and the persistence side effect, which are the two things that most change how the tool is called. What remains missing is guidance on handling more than 3 URLs and how partial failures surface to the caller, a minor gap given the rich schema.

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

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

Schema description coverage is 100% and the request object's description already enumerates urls, languages, include_timestamps, timezone, output_path, include_content_in_response, and overwrite. The description only re-states the URL cap and output_path behavior, adding no format or edge-case detail beyond the schema; baseline 3 applies.

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

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

The description opens with a specific verb and resource ("Extract transcripts from multiple YouTube videos"), and the word "multiple" plus the batch_ name prefix distinguishes it in practice from the single-video sibling extract_youtube_transcript. It never names that sibling explicitly, so an agent must infer the split, keeping this 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 description gives an operational constraint ("Max 3 URLs per call") and explains the output_path option's effect (persist files, get a slim response), which is real usage guidance. However, it never says when to prefer this over extract_youtube_transcript or how to handle larger batches (chunking? repeat calls?), leaving the key routing and batching decisions 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?

The deprecation notice and the equivalence claim ('same request keys and results') are genuine behavioral facts an agent could not infer from annotations or schema. With readOnlyHint=true already covering the safety profile, this is strong, though it does not state whether the alias may be removed or behave differently over time.

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, zero waste, with the deprecation status front-loaded before the redirect instruction.

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 deprecated alias stub, the description supplies everything needed: the equivalence guarantee, the redirection target, and an output schema to explain results. Nothing an agent requires to decide or call correctly is missing.

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

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

Schema description coverage is 100% and the nested request object is exhaustively documented, so the schema carries parameter meaning. The description only asserts the keys match batch_search_web, adding no new syntax or format detail beyond that pointer.

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 precisely what the tool is (a deprecated alias of batch_search_web) and that it takes the same request keys and returns the same results, so an agent immediately knows the underlying resource. It also names the sibling it duplicates, making it unambiguous against the other search tools.

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

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

The final clause, 'Use batch_search_web,' is an explicit directive naming the preferred alternative. There is no ambiguity about when to select this tool versus its replacement.

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?

readOnlyHint=true is consistent with a search operation, so no contradiction. The description contributes real behavior beyond the annotations: the 3-query cap and the fact that supplying output_path makes the response 'slim' while the full set lands on disk - a consequence the annotation does not convey.

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, zero waste, and the primary action is front-loaded ahead of the operational constraints. Nothing is buried or repeated from the schema.

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

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

Given a rich nested schema at 100% coverage and an output schema, the description needs only the operational gotchas - and it supplies the two most important (query cap, persistence behavior). It could still note that result_type alternatives run on Brave only, but that detail lives in the schema.

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

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

Schema coverage is 100% and the nested request object documents every key, so baseline would be 3. The description earns extra credit for explaining the observable effect of output_path (slim response), which the schema states only as 'full result set written to disk'.

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 ('Perform multiple web searches') plus a hard scope limit ('Max 3 queries per call'). It does not explicitly name siblings like search_web or batch_search_google, so the batch-vs-single distinction is left to the name rather than the description.

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 only concrete guidance is a usage rule for persistence ('Supply output_path ... to persist the full result set'), which covers one scenario well. It never says when to choose this over search_web or batch_search_google, so the selection decision must be inferred from the name.

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

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

With no annotations, the description adds significant behavioral detail: how output_path slimdown works, the interaction between content_offset/limit and the on-disk file, and the include_content_in_response flag. This goes beyond basic functionality.

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 extremely concise: three short sentences that front-load the purpose and quickly cover the most important usage scenarios. No unnecessary words.

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

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

Given 16 parameters and an output schema, the description covers the most important behaviors (JS, pagination, persistence) but omits details on less common params like css_selector or extract_media. Still, the core agent needs are addressed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the interplay between output_path, content_offset, and content_limit, and advises when to use wait_for_js, which is not present in the schema alone.

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

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

The description clearly states the tool extracts web page content with JavaScript support, and provides specific use cases like SPAs and pagination. However, it does not differentiate from sibling tools like 'crawl_url_with_fallback' or 'deep_crawl_site', which lowers the score slightly.

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

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

The description gives explicit usage guidelines for key features (wait_for_js for SPAs, pagination with offsets, persisting content to disk). It lacks guidance on when not to use this tool or alternatives, but provides enough context for common scenarios.

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

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

Annotations already indicate readOnlyHint=true, which is consistent with crawling. Description adds that fallback strategies exist for anti-bot sites, but does not detail what those strategies are or any other behavioral traits.

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

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

Two sentences, front-loaded with core purpose, no fluff. Each sentence adds distinct value: purpose, pagination, and persistence.

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 14 parameters and an output schema (not shown), the description covers the main behavioral aspects (fallback, pagination, persistence). Minor gap: no explanation of the fallback strategies themselves, but overall adequate.

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?

With 100% schema coverage, baseline is 3. The description adds meaningful context for pagination (content_offset/content_limit) and persistence (output_path with behavior rules), going beyond the schema comments.

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') and target ('anti-bot sites') with fallback strategies, but does not differentiate from the sibling tool 'crawl_url' which likely has similar 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 implies usage via mention of pagination and persistence, but does not provide explicit guidance on when to choose this tool over alternatives like 'crawl_url' or 'search_and_crawl'.

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

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

The description adds real behavior the annotations don't convey: setting output_path persists per-URL markdown plus index.json, and the response is then slimmed to metadata only. That is exactly the side effect an agent needs to know before opting into file output. The only gap is that it doesn't reconcile this file-writing behavior with the readOnlyHint annotation, which reads as local-artifact generation rather than a remote-state mutation.

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, zero padding, with the core action front-loaded and the output_path persistence caveat immediately after. Every clause carries information an agent would otherwise have to infer.

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?

Return values need no explanation because an output schema exists, and the schema fully covers the 12 parameters. However, for a 12-parameter tool sitting in a crowded crawl family, the description leaves the sibling-routing decision (deep_crawl_site vs batch_crawl vs multi_url_crawl vs crawl_url) entirely to the agent.

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

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

Schema coverage is 100%, so the schema already documents all 12 parameters including ranges and defaults. The description nonetheless reinforces the highest-impact one — output_path as a directory with a response-shape consequence — adding value beyond the schema's own wording. Baseline 3 is exceeded slightly for that targeted emphasis.

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 ('Crawl multiple pages from a site with configurable depth'), and 'multiple pages' implicitly contrasts with the single-page crawl_url sibling. It does not explicitly differentiate itself from batch_crawl, multi_url_crawl, or search_and_crawl, so an agent still has to disambiguate among the crawl family by name alone.

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

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

Usage is only implied: crawl a site (not a single URL) to a given depth. There is no explicit 'use this when you need X instead of batch_crawl/multi_url_crawl' guidance, and no statement of prerequisites or when the tool is a poor fit (e.g., across many domains).

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

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

The annotations declare readOnlyHint=true, but the description states the tool persists data to disk, which is a write operation. This is a direct contradiction. Additionally, the description does not disclose other behavioral traits such as required permissions, rate limits, or side effects.

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

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

The description is two sentences long, directly stating the core functionality and key usage advice. Every word earns its place with no fluff.

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

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

Given the tool's 14 parameters and existence of an output schema, the description is minimal but covers the main point. However, it lacks details about return structure, error conditions, and behavioral nuances beyond the output_path feature.

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

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

Input schema has 100% coverage for all 14 parameters, providing clear descriptions. The description adds value by explaining the effect of output_path and the slim response, which enhances understanding beyond the schema.

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

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

The description clearly states it processes large content with chunking and BM25 filtering, and mentions persisting to disk. It distinguishes itself from siblings by specifying the advanced processing features, though it doesn't explicitly differentiate from similar tools like 'process_file'.

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

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

No guidance is provided on when to use this tool versus alternatives. It only implies usage via the description but lacks explicit context, exclusions, or comparisons with sibling tools.

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

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

Annotations only declare readOnlyHint=true, and the description adds real behavioral context: with output_path set, the full extraction is written to disk as JSON and the response is slimmed. However, this creates an unaddressed tension with readOnlyHint (a file is written) and the description says nothing about regex-vs-LLM mode consequences, which drive most of the tool's actual behavior.

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

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

Two sentences, front-loaded with the core action and followed by the highest-value operational hint. No filler or repetition, though the second sentence could be tighter.

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 11-parameter tool, the description leans heavily on a fully documented schema and an existing output schema, so return values and per-parameter semantics are covered elsewhere. The remaining gap is the absence of any routing guidance among the many extraction siblings.

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

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

Schema description coverage is 100%, so every parameter including entity_types, custom_patterns, and overwrite is already documented in detail. The description's note about output_path duplicates what the schema already states, adding no syntax or default information 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?

Names a specific verb and resource ("Extract entities") and scopes it to web pages, with examples of the entity kinds (emails, phones). It does not explicitly differentiate itself from close siblings like extract_structured_data or intelligent_extract, which an agent could plausibly confuse it with.

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

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

There is no statement of when to choose this over extract_structured_data, intelligent_extract, or crawl_url, and no exclusions or prerequisites. The only guidance is operational (use output_path to get a slim response), not selection guidance.

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

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

Annotations indicate readOnlyHint=true, which matches the extraction purpose. The description adds useful behavioral context about output_path persisting full data and slimming the response, but does not disclose other behaviors like rate limits or auth needs.

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

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

The description is concise with two sentences, no wasted words. It front-loads the main purpose, but could be better structured by separating the core function from the output_path detail.

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

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

Given the tool's complexity (12 parameters) and presence of an output schema, the description covers the key behavior of output_path but lacks context on when to use different extraction types or how they differ. This is adequate but not comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents parameters thoroughly. The description adds minimal value beyond restating extraction types and output_path behavior, meeting the baseline expectation.

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 the tool extracts structured data using CSS selectors or LLM, which is specific and clear. It distinguishes from sibling crawling tools but does not explicitly differentiate from other extraction tools like intelligent_extract or extract_entities.

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 mentions the output_path behavior but lacks prerequisites or when-not-to-use instructions, which is a gap given the large set of sibling extraction 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?

Description describes a side effect (writing comments to disk) that contradicts the readOnlyHint annotation, which implies no mutations. This is a serious inconsistency.

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 concise sentences; first states core function, second explains key persistence feature. No superfluous 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?

Covers main behavior, pagination, and file persistence, but the annotation contradiction undermines completeness. Output schema exists to cover return values.

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

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

Input schema has 100% description coverage, so baseline 3. Description adds marginal value beyond schema, clarifying output_path behavior but not essential.

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 verb 'Extract' and resource 'YouTube video comments'. Differentiates from sibling tools like extract_youtube_transcript.

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

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

Implies usage for extracting comments with pagination and optional file persistence, but lacks explicit when-to-use or alternative comparisons.

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?

readOnlyHint=true already tells the agent this is a safe network read. The description adds useful context – crawl fallback and that output_path writes the full unsliced transcript to disk, plus that the response copy is slimmed. However, it doesn't surface the heavier behaviors (auto_summarize, llm translate) that the tool also exposes, leaving a gap relative to what the tool can do.

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

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

Four short sentences, front-loaded with the core action, no filler. Every sentence earns its place; each covers a distinct concern (what, constraint, fallback, persistence).

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

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

An output schema exists, so return-value explanation isn't required, freeing the description to focus on behavior. For a 20-param tool it's reasonably complete, though it never acknowledges the translation/summarization features, so an agent must read the schema to discover them.

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

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

Schema description coverage is 100%, so the input schema fully documents all 20 params; baseline is 3. The description does add real meaning for output_path (persists unsliced transcript, response slimmed) and timestamps, but says nothing about translation, summarization, or language ordering beyond what the schema states.

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

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

States a specific verb+resource: 'Extract YouTube transcripts'. Adds scope details (with timestamps, public captioned videos, fallback to page crawl). It does not explicitly distinguish itself from batch_extract_youtube_transcripts or extract_youtube_comments, so sibling 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?

'Works with public captioned videos' gives a constraint, and the output_path sentence implies a persistence workflow. But there is no explicit when-to-use versus the batch or comments variants, and no mention of prerequisites beyond the public-captioned hint.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds no further behavioral details such as whether the genre list is static or dynamic, or any rate limits. It is minimally adequate given the annotations.

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

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

The description is a single concise sentence with the verb 'Get' front-loaded, containing no unnecessary words.

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

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

For a simple tool with no parameters and an output schema, the description sufficiently conveys the tool's purpose. The agent can rely on the output schema for return structure details.

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

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

The input schema has zero parameters, so the description does not need to explain them. The baseline score of 4 is appropriate as the description does not contradict or fail to add value.

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

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

The description clearly states the tool retrieves available search genres for targeted searching, using a specific verb ('Get') and resource ('search genres'). It is distinct from sibling tools that perform searches themselves.

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

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

The description implies usage when needing genre options for a targeted search, but does not explicitly state when not to use it or provide alternatives among siblings.

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

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

Annotations indicate readOnlyHint=true. The description adds context by specifying it returns format capabilities, which goes beyond the annotation. No contradictions.

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 concise sentence that front-loads the action and examples. No extraneous words.

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

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

Given zero parameters and the presence of an output schema, the description sufficiently informs the agent about the tool's purpose and return value.

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?

There are no parameters, so the description does not need to add meaning beyond the input schema. The schema is fully covered.

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 retrieves supported file formats and their capabilities, with specific examples (PDF, Office, ZIP). It is distinct from sibling tools which focus on crawling, extraction, or processing.

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

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

The context is clear: this tool is used to check which formats are supported before using other file-processing tools. No explicit exclusions or alternatives are needed given the tool's simplicity.

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

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

The description usefully discloses the file-persistence side effect and the response-shape trade-off (slim response when output_path is set), which goes beyond the readOnlyHint annotation. It says nothing about the LLM-backed summarization path being invoked by summarize_transcript, which carries latency and cost implications for an agent, and it omits any noting of the tension between a filesystem write and readOnlyHint=true.

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

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

Two tight sentences with the core capability front-loaded and the persistence behavior second. Nothing is padded and every clause carries information.

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

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

With eleven parameters, an output schema, and only a readOnlyHint annotation, the description should convey the tool's full capability set. It never says the tool can summarize the transcript or return full content in the response, leaving two of the most consequential modes to be discovered only by reading the schema.

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

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

Schema description coverage is 100%, so all eleven parameters are already documented in the schema, including the slim-response behavior of output_path. The description restates that one behavior but adds no syntax or semantic detail for llm_model, max_tokens, summarize_transcript, summary_length, or include_timestamps, 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 gives a specific verb and resource ("Get YouTube video metadata and transcript availability") that an agent can act on immediately. However, it never distinguishes this tool from close siblings like extract_youtube_transcript or batch_extract_youtube_transcripts, and it understates its own scope by framing the output as mere "transcript availability" when the schema shows summarization and full-transcript retrieval options.

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 second sentence gives one concrete usage rule — set output_path to get a persisted markdown transcript plus a slim response — which is implied guidance on when the parameter matters. But there is no statement of when to prefer this tool over extract_youtube_transcript, no exclusion of cases where it is a poor fit, and no mention of when to enable summarize_transcript.

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

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

Annotations indicate readOnlyHint=true, so the tool is non-destructive. The description adds the behavior of output_path enabling slim responses. No further details on rate limits, error handling, or LLM behavior are provided. Does not contradict annotations.

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

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

Two sentences: first states purpose, second explains key workflow parameter. No extraneous information. Efficient and front-loaded.

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

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

Given the tool's complexity (12 parameters, output schema present), the description covers the main purpose and the critical output_path behavior. It could be improved by clarifying when to use this over crawling or batch tools, but overall it is sufficient for an agent to understand the tool's role.

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 most parameter meanings are already clear. The description adds context for output_path, explaining its effect on response structure. This provides marginal additional value beyond the schema.

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

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

The description clearly states the tool extracts specific data from web pages using LLM, distinguishing it from sibling tools like crawl_url which likely return full content. The verb 'extract' and resource 'web pages' are specific.

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

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

The description implies usage for extracting data from web pages with optional output persistence, but does not explicitly state when to use this tool versus alternatives like batch_crawl or search_and_crawl. No exclusions or prerequisites are mentioned.

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

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

Adds genuine behavioral detail beyond the lone readOnlyHint annotation: the return stays a list and successful items gain an output_file key. However, it omits that URLs are processed sequentially and that output_path causes local filesystem writes (which sits in uneasy tension with readOnlyHint), so the side-effect profile is only partly disclosed.

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

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

Three short sentences, front-loaded with the capability and limit, then the persistence behavior. Minor ambiguity from "URL patterns" colliding with the pattern_matching parameter, but 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?

An output schema plus fully described parameters carry most of the load, so the description is adequate. Still missing sibling differentiation and the sequential-processing caveat, which are the two things an agent most needs to make a correct call.

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

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

Schema coverage is 100%, so every parameter already carries its own description, including the 5-URL cap and the output_file behavior. The description restates max 5 URLs and the output_file key without adding format or syntax detail, so baseline 3 applies.

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

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

States a specific verb+resource ("Multi-URL crawl") plus scope ("Max 5 URL patterns per call") and the pattern-based config angle. It doesn't name or distinguish itself from the obvious siblings crawl_url, batch_crawl, or deep_crawl_site, so an agent has to infer the difference from the batch/limit constraint alone.

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

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

Implies usage (batch of up to 5 URLs; use output_path if you want files on disk) but never says when to choose this over batch_crawl or crawl_url, nor any prerequisite/exclusion. With four overlapping crawl siblings, the routing decision is not resolved by the description.

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

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

The description states the tool 'converts' files, implying a write/mutation operation, but the annotation declares readOnlyHint=true. This is a direct contradiction and severely misleads the agent about the tool's side effects.

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

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

Two sentences: first states core purpose, second explains key usage pattern. Every word is necessary and front-loaded.

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

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

Essentials covered: conversion types and output_path. With full schema coverage and output schema present, the description is sufficiently complete for a complex 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%, baseline 3. The description adds value by explaining the output_path behavior (slim response, full unsliced disk persistence) and slicing effect, going beyond schema descriptions.

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

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

The description clearly states the tool converts PDF, Word, Excel, PowerPoint, ZIP to markdown, and mentions the key output_path feature. It is specific and informative.

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 versus siblings like batch_crawl or crawl_url. The description does not mention 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?

Goes well beyond readOnlyHint=true by disclosing the filesystem side effect: per-page markdown plus index.json written to output_path, and that the response becomes 'slim' in that mode. It even notes persisted bodies are 'unsliced', i.e. written before max_content_per_page truncation, which is a non-obvious behavioral detail. Missing only permission/overwrite semantics and failure behavior, which the schema covers instead.

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 action and ending with the optional persistence mode, so an agent skimming gets the essential behavior first. The final sentence is dense but every clause carries a distinct fact.

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 moderately complex (nested request object, dual search/crawl behavior), the schema is fully documented, and an output schema exists, so return values need not be explained. The description covers the compound behavior and the two response modes, which is what an agent needs to call it correctly.

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

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

Schema description coverage is 100% and the nested request description already enumerates every key, including output_path, include_content_in_response, overwrite and failure handling. The description adds modest value by clarifying that output_path is a directory with a specific artifact layout and that persisted content is pre-truncation. That is useful but largely restates schema content, so baseline 3 fits.

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 compound action: search the web and crawl the top results, with full content extraction. It anchors the engine parameter to the sibling search_web, so an agent can see this is search_web plus page fetching. It does not explicitly contrast itself with the pure crawl siblings (crawl_url, deep_crawl_site, batch_crawl), leaving the boundary 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?

'Combines search with full content extraction' implies the condition for use: when snippets alone are insufficient and page bodies are needed. The third sentence describes the persistence mode. However, there is no explicit when-not or named alternative (search_web for listings only, batch_crawl for known URLs), so the routing decision is only implied.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely non-obvious context: the tool is deprecated, and despite its name the engine is not limited to Google. It does not say whether calls emit deprecation warnings or when removal is planned, which would be useful for an agent deciding whether the alias is safe to keep calling.

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

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

A single sentence that front-loads the critical fact (deprecated) and closes with the actionable directive. Nothing is wasted 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?

For a deprecated alias with a fully documented nested schema and an output schema, the description covers what an agent needs: what it is, what it is not (Google-only), and what to use instead. Only the lifecycle details — warnings surfaced, removal timeline — are 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% and the nested request object documents every key, including engine and search_genre enums, in detail. The description only asserts 'same request keys and results,' adding no parameter 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?

The description identifies the tool precisely as a deprecated alias of search_web with identical request keys and results, which lets an agent distinguish it from siblings like search_web or batch_search_google. It never states the underlying operation (web search) in its own words, relying on the reader knowing what search_web does, but the alias framing 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?

It gives an explicit directive — 'Use search_web' — which is the strongest possible when-to-use guidance for a deprecated tool, and it names the alternative by name. No inference is required about which sibling to prefer.

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 readOnlyHint=true covering the safety profile, the description still adds real behavioral detail: output_path writes the full unsliced result set to disk BEFORE content_limit/content_offset slicing and returns a slim response. That persistence side effect is useful context not present in the annotations, though it sits somewhat in tension with readOnlyHint and is not reconciled.

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 dense sentences, front-loaded with the core action and back-loaded with the persistence nuance. Nothing is wasted, though the parenthetical engine clause is slightly compressed to the point of ambiguity about what 'engine key' means.

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

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

An output schema exists so return values need no explanation, and the description cross-references get_search_genres for the one enum-like parameter that matters. The main gap is the absence of routing guidance among six search siblings, which the rich schema cannot supply.

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

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

Schema coverage is 100%, so baseline is 3, but the description earns extra credit by surfacing the two highest-leverage parameters and their semantics: search_genre routing to get_search_genres, and output_path plus the pre-slice write ordering. It does not restate engine/result_type behavior, but the schema already does that thoroughly.

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

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

The description opens with a specific verb and resource ('Search the web') and immediately names the four backends, which implicitly separates it from the single-engine sibling search_google. It does not explicitly contrast against search_google, batch_search_web, or search_and_crawl, so an agent must infer the boundary, but the multi-engine scope is clear.

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 rather than stated: use search_genre 'see get_search_genres' for file-type or language operators, and add output_path when persistence is needed. There is no explicit when-to-use-this-vs-search_google or batch_search_web guidance despite six closely related siblings.

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