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

With no annotations provided, the description carries full burden. It discloses key behaviors: parallel execution, automatic deduplication, cache-awareness, per-URL failure isolation, and the return structure. It does not mention rate limits, auth, or redirect handling, but the disclosed traits are sufficient for typical agent decisions. Minor gap is not explaining what 'cache-aware' implies operationally.

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 efficiently written, front-loaded with the core purpose and usage guidance, then parameter details. It repeats the return structure twice (once in prose, once in a return block), which is slightly redundant but not harmful. Structure is logical and skimmable.

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 5 parameters and no annotations, the description covers all needed context: when to use, how to set parameters, return format, failure isolation, and efficiency rationale. It even explains the deduping and default for include_html. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: each parameter gets a meaningful explanation (e.g., 'urls: Target URLs (deduped automatically; empties dropped)', 'prefer: "auto" | "fast" | "stealth" | "llm"', 'timeout: per-URL timeout in seconds'). This adds semantics well beyond the schema's types and defaults.

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 'Scrape MANY URLs in ONE call' with explicit characteristics (parallel, deduped, cache-aware), clearly distinguishing it from the single-URL sibling 'scrape'. The verb-resource pairing is unmistakable and the emphasis on batch capability differentiates it from all sibling 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?

It explicitly states when to use it: 'Use when the user provides multiple URLs or you have a list of pages to fetch.' It also explains benefits over the alternative ('More efficient than calling `scrape` N times'), giving clear routing guidance without needing to inspect the schema.

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

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

With no annotations, the description carries the behavioral burden. It does communicate the basic operation model and even hints at what clearing affects ('stale cached responses'). However, it does not disclose whether 'clear' wipes the entire cache, whether enable/disable persists, or whether any actions are destructive or require privileges.

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: a one-sentence purpose, two concrete use cases, then the parameter details. Every sentence earns its place and there is no redundant or filler content.

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 one-parameter tool with an output schema, the description covers the action values and gives practical usage context. It is nearly complete, but slightly more detail on the side effects of clear/disable/enable would make it fully self-sufficient given the absence of annotations.

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?

Despite 0% schema description coverage, the description fully documents the only parameter: action, its allowed values ('stats' | 'clear' | 'disable' | 'enable'), and its default ('stats'). This adds real meaning beyond the raw schema, which only shows a string with a default.

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 first sentence states the tool's purpose with a specific verb and resource: 'Inspect the response cache' and then enumerates the exact operations supported (stats, clear, enable, disable). This unambiguously separates it from the sibling scraping and search tools, none of which touch the cache.

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 clear, actionable use cases: check hit rates before large batch jobs, and clear stale responses after content changes. It does not explicitly mention alternatives or exclusions, but no alternative cache tool exists among the siblings, so the guidance is sufficient.

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 behavioral burden, and it delivers: it explains the discover-then-scrape flow, flat vs BFS depth behavior, filtering by regex, the `prefer` mode variants, and the exact success/error return shapes. This goes well beyond a minimal statement of what the tool does.

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 well-structured and front-loaded: a crisp one-sentence summary, then usage guidance, then a tight Args block, then the Returns shape. Every line adds information without padding, which is appropriate for a 7-parameter tool with no schema-level parameter descriptions.

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 no annotations, an output schema present, and seven parameters, the description is operationally self-sufficient. It covers purpose, when to use it, alternatives, all parameter semantics, the crawling algorithm variants, filters, and the return contract including the error case.

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 every parameter, and it does. All seven arguments are meaningfully explained, including the regex semantics for include/exclude paths, the meaning of max_depth, and the `prefer` option values.

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, action-oriented definition: 'Multi-page crawl: discover URLs on root, then scrape each.' It also distinguishes itself from siblings by naming `scrape` for single pages and `deep_research` for research questions.

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 says when to use crawl (entire site section, docs, bulk multi-page needs) and gives explicit alternatives for single pages and research questions. However, it does not distinguish crawl from the `batch_scrape` sibling, and its phrase 'multiple pages scraped in bulk' could overlap with that tool, so the routing guidance is not fully exhaustive.

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

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

With no annotations, the description carries the full burden and it delivers: it discloses that no LLM synthesis occurs, that multi-pass runs refine queries and deduplicate by URL, and that failures return a structured error object with a hint. This gives an agent a realistic model of what the tool will and will not 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?

The description is organized with a purpose statement, usage trigger, mode explanation, per-argument semantics, and a complete return shape. While long, every section earns its place and the most important decision-relevant facts are 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?

The tool has five parameters, multiple modes, and a rich return value, and the description covers all of them: arguments, multi-pass behavior, output shape, and error shape. Nothing an agent needs to invoke or interpret the result is missing, and the output schema is effectively described inline.

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 document all five parameters and does: query, limit, scrape_top, prefer (with listed option values), and iterations (with concrete guidance on 1 vs 2-3). The iterations explanation adds behavior beyond the schema's bare integer type.

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, then pull the top sources as EVIDENCE (no LLM synthesis).' It clearly distinguishes this tool from generic search or scrape siblings by labeling it the 'PRIMARY RESEARCH TOOL' and explicitly stating the agent performs synthesis from evidence.

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 explicit trigger conditions: 'use when the user asks to research, investigate, deep-dive, fact-check, or learn about a topic.' It also explains the multi-pass option for deeper research. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the behavioral burden; it adds that extraction is non-browser, content type is sniffed and routed to pypdf/python-docx/python-pptx, and that optional dependencies may need installing. It could mention failure modes or whether any state changes occur, but the read-only extraction framing is clear.

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?

Every sentence adds value and the most identifying information is front-loaded. The usage cases, routing detail, and dependency caveat are each one concise line, with no filler.

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

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

For a simple extracted-text tool with an output schema, the description covers purpose, use case, supported formats, routing, and install needs. It is incomplete for the two optional parameters (`timeout`, `max_pages`), which are not documented in the schema or the description.

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 0%, so the description must explain parameters. It clarifies only `url` by restricting it to PDF/DOCX/PPTX document links; `timeout` and `max_pages` are left completely unexplained beyond their names and defaults.

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 first line names an exact action (extract text), input family (PDF/DOCX/PPTX URL), output (markdown), and an explicit constraint (no browser). It also places the tool relative to `search_papers`, so an agent can distinguish document conversion from generic scraping siblings.

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

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

It gives concrete conditions: use when the user shares a PDF/Word/PowerPoint link and wants text, and after `search_papers` on a pdf_url. It does not explicitly name sibling tools to avoid or state hard exclusions, though 'no browser' implicitly rules out general web pages.

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 must carry the burden. It discloses that this is a scraping/extraction operation and says it returns parsed JSON in `data`. But it omits practical behavioral details like dynamic-content handling, page-size limits, error behavior, and what the `prefer` option controls.

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. The first sentence captures the essence, and the rest provides a concrete example and return-shape note without wasted words.

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

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

The schema example and return mention make the tool callable, but with no annotations and zero parameter descriptions, important usage context is missing—especially around `prefer` and dynamic page behavior. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does a good job for the `schema` parameter by providing a concrete JsonCssExtractionStrategy example, but `prefer` is not explained at all, and `url` is only meaningful by convention.

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 operation ('Scrape + structured extraction') with a clear mechanism (CSS-based JSON schema) and names concrete use cases (tables, lists, product info). This distinguishes it from siblings like scrape or crawl, which are for less structured data collection.

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 explicitly says when to use the tool: when the user wants structured data extracted from a page. However, it does not explicitly name alternatives or state when not to use it, so the contrast with sibling tools is mostly 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 scope of the check (engine versions, dependencies, update status) and implies a read-only diagnostic operation. However, it does not detail any side effects (likely none), how it reports failures (e.g., exit codes, summary output), or whether it performs network calls. For a zero-parameter health check, this is adequate but not rich.

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

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

The description is two sentences that front-load the purpose and then immediately provide usage guidance. Every word earns its place; there is no fluff or redundant phrasing. It is concise and structured optimally for agent parsing.

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 tool, the description explains what it verifies and when to run it. The output schema (not shown in the input but indicated as present) likely covers the exact return format. The description is sufficient for an agent to know why and when to call the tool, though it does not specify what constitutes 'working' beyond installed engines. This is a minor gap, but overall complete for the tool's simplicity.

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

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

The tool has zero parameters, so there is no schema coverage gap. The description does not need to elaborate on parameters. According to the rubric, a 0-parameter baseline is 4, and the description adds no irrelevant parameter details, so this score 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 states what the tool does: 'Verify PyreCrawl is working: engine versions, dependencies, update status.' It uses a specific verb and resource, and the purpose is distinct from sibling tools that perform scraping tasks. An agent can immediately understand this is a pre-flight health check, not a scraping operation.

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 when to use it: 'at the start of a session or before a large scraping job to confirm all engines are installed and up to date.' This gives concrete context. It does not explicitly contrast with alternatives (e.g., 'use rather than scrape when...'), but the purpose and usage are clear enough that an agent would be unlikely to confuse it with a scraping tool.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does add useful constraints — 'internal URLs' scoping, 'reachable from root' traversal semantics, and the 'hard cap' behavior of `limit` — but leaves significant traits undisclosed: auth requirements, rate limits, redirect handling, and whether the tool makes many network requests. Meaningful but incomplete for an unannotated tool.

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

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

The description is tightly structured — core purpose in the first sentence, usage guidance in the second, then a clean Args block. Every sentence earns its place, and the most decision-relevant information (what it returns, internal scope) is 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?

For a 3-parameter tool with an output schema, the description covers the essentials: purpose, when to use it, related tools, and all parameters with semantics. Minor gaps remain — how traversal handles redirects, depth limits, and protocol variants — but an agent has enough to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: `root` gets a format example, `include_pattern` gets its regex filter semantics explained, and `limit` is clarified as a 'Hard cap on returned URLs'. All three parameters receive meaning beyond the bare schema types, fully covering the parameters that the schema left undocumented.

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 first sentence is a specific verb+resource statement — 'Enumerate all internal URLs reachable from `root`' — which precisely defines the scope and distinguishes this from siblings like `crawl` (which fetches content) and `search` (which queries). The pairing note with `crawl`/`batch_scrape` further clarifies its role as a pre-scrape discovery step.

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

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

'Use when the user wants to map a site's structure or find all pages before crawling' gives clear, actionable context, and naming `crawl` and `batch_scrape` as common companions helps an agent understand the workflow. However, it stops short of explicit exclusions — it never states 'use crawl instead when you need page content only,' so the when-not guidance is implied rather than stated.

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

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

With no annotations, the description carries the burden, and it delivers by disclosing that snapshots persist under PYRECRAWL_MONITOR_DIR, that check returns status values including error, and that a unified diff is produced. It could go further by explaining the side effects of 'forget' and retention behavior, but the core stateful behavior is well 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?

The description is well-structured with a purpose statement, explicit usage trigger, Args block, and Returns block. It is longer than minimal but each section earns its place; the guided-setup sentence adds a useful interaction hint rather than 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 stateful tool with three actions, the description details only 'check' behavior. 'history' and 'forget' are listed but their effects, return shapes, and side effects are unexplained. Since there are no annotations and schema coverage is 0%, this is a meaningful gap for an agent deciding how to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains url, enumerates action values, gives css_selector its diff-scoping purpose, and references the 'prefer' ladder via scrape. The main gap is that 'history' and 'forget' semantics are not expanded, and 'prefer' relies on knowing what scrape does.

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: 'Track a URL over time and report meaningful content changes.' This clearly distinguishes monitor from one-off tools like scrape and crawl, and the concrete use cases (price changes, blog posts, status updates) reinforce the 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?

It explicitly says 'Use when the user wants to watch a page for updates' and provides a guided setup cue. However, it does not explicitly say when not to use this tool or name alternatives like scrape for one-off fetches, so it misses the exclusion aspect.

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 present, so the description carries the full behavioral burden and succeeds. It discloses the auto-escalation path ('fast→stealth→llm when blocked'), explains what each mode does (cheap HTTP, real Chromium + Cloudflare solver, full Crawl4AI browser), and scopes js and wait_for to stealth only. It also documents the success and failure return shapes.

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 tightly structured: a one-line purpose, a single usage sentence, a compact Args block, and a Returns block. Every line is information-dense with no filler, and the most important scoping details are 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?

This is a complex tool with 6 parameters, 4 execution modes, JS evaluation, and async waiting. The description accounts for every parameter, the escalation behavior, return values, and failure output. There are no obvious omissions that would prevent an agent from invoking 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?

The input schema has no descriptions and only bare titles/defaults, so the description must compensate. It does: url is constrained to http/https, prefer enumerates all four modes with escalation semantics, timeout is defined as per-attempt seconds, include_html warns about response size, and js/wait_for get exact behavioral definitions with an example for js.

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-resource statement: 'Scrape a single URL' and 'LLM-ready markdown'. It names a clear trigger ('when the user shares a URL and wants its content'), and 'single URL' separates it from multi-URL siblings like crawl and batch_scrape. However, it does not explain how it differs from sibling extract, so differentiation is incomplete.

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

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

It gives a concrete usage context: 'Use this when the user shares a URL and wants its content (read, analyze, summarize, extract)'. That is clear context, but it does not list exclusions or point to alternative tools such as extract or crawl, leaving the when-not-to-use judgment to the agent.

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

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

No annotations are provided, so the description carries the full burden. It discloses the use of DuckDuckGo HTML, no API key requirement, the smart ladder bypass, and the return format including error handling. It doesn't mention rate limits or other limitations, but for a search tool it is fairly transparent.

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

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

The description is mostly concise but repeats the return format twice (once as a list, once as a structured object). The 'smart ladder' phrase is vague. Overall, it is structured and not overly verbose.

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, the description covers usage guidance, return format, and error handling. However, it fails to explain parameters and does not mention any rate limits or usage constraints. With no annotations, more detail on parameters and limitations would improve completeness.

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 does not explain the 'limit' or 'prefer' parameters, and only implies the query. This leaves ambiguity about what these parameters control, especially 'prefer' which is unclear. The description adds minimal 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 'Web search via DuckDuckGo HTML' which identifies the verb (search) and resource (web via DuckDuckGo). It also differentiates from siblings like deep_research and web_search, making its purpose 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?

Explicitly provides when-to-use guidance: targeted searches needing anti-bot bypass, with alternatives for simple searches (web_search) and research questions (deep_research). Also mentions the smart ladder for bot detection, leaving no ambiguity about selection.

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

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

With no annotations, the description carries the full burden. It discloses that no API keys are needed, specifies per-source result limits (1-25 arXiv / 1-20 Crossref), describes the return fields (id/url/pdf_url/title/authors/summary/published), and mentions the error return format. It also notes that pdf_url is optional (indicated by the '?' in the return example). This is strong, though it could explicitly state the operation is read-only and has no 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 well-structured with a heading, a bulleted Args list, and a Returns section. Every sentence carries useful information: examples, default values, and a downstream workflow hint. It front-loads the purpose and keeps the details organized, 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?

The description is complete for a 4-parameter tool. It covers all parameters, provides return format details, notes the error case, and suggests an integration with the 'document' tool. Given the existing output schema (not shown but present), the description does not need to repeat return values, and it supplies enough for an agent 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 0%, so the description fully compensates. It explains each parameter: query with an example ('transformer attention scaling laws'), limit with per-source ranges, source with defaults and meanings ('arxiv' for preprints, 'crossref' for DOI-backed), and category with an example format ('cs.LG'). This adds significant meaning beyond the bare schema, making parameters self-explanatory.

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 purpose: 'Search academic papers via arXiv or Crossref — no API keys.' This is a specific verb (search) and resource (academic papers) with two named sources, and it naturally distinguishes from siblings like the general 'search' tool or 'document' for extraction. The mention of specific sources and the absence of API keys adds clarity.

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 clear context for when to use this tool: when searching academic papers via arXiv or Crossref. It also gives a workflow hint by suggesting to feed the returned pdf_url into the 'document' tool for full-text extraction. However, it does not explicitly state when not to use it or compare with alternatives like 'search' or 'deep_research', so it falls slightly short of full 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 full burden and meets it: it enumerates every action (open, click, fill, type, eval, wait, content, screenshot, cookies, close, list) with their effects, explicitly states 'close — destroy the session' as destructive, and specifies the return format ('Returns {session, action, ...result, elapsed_ms}; errors as {error}'). It also discloses persistence of cookies and JS state.

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 well-structured: it opens with purpose, then usage guidelines, then the stateful vs one-shot distinction, followed by a concise action-by-action list and return format. Every sentence adds value; the length is justified by the tool's complexity but remains scannable 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?

For a tool with 10 parameters and 12 actions, this description is extraordinarily complete: it covers purpose, invocation conditions, all actions with their inputs and outputs, return and error formats, and distinguishes from siblings. An output schema exists, so return values don't need further explanation. Nothing essential for correct use 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 has 0% description coverage, so the description must compensate. It does so well by detailing parameters under 'Args:' including session, and for each action the relevant parameters (url, selector, text, key, js, full_page, timeout_ms). However, the `headless` parameter is never mentioned in the description, leaving its purpose undocumented—a minor gap given the otherwise thorough coverage.

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 purpose: 'Drive a persistent browser session — cookies & JS state kept across calls.' This clearly identifies the tool as a session manager and differentiates it from one-shot tools like scrape and deep_research, which are explicitly named as alternatives.

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

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

Provides explicit usage guidance: 'Use for login walls and multi-step flows the one-shot ladder can't handle' and tells exactly when to use alternatives: 'For simple pages use `scrape`; for research use `deep_research`.' Also clarifies the key distinction: 'One-shot scrape has no session memory; here each action runs against the same live page.' This leaves no ambiguity about when to invoke this tool.

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