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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral detail: each passage includes a context window, relevance score, and character offset for verifiable citations. It does not discuss failure modes or rate limits, but the annotations lower that burden.

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

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

Three sentences with no filler: the first states the action, the second describes the output, and the third gives usage guidance. Information is front-loaded and every sentence earns its place.

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

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

An output schema exists, so return values need not be fully described, and annotations cover safety. The description covers purpose, output behavior, and usage. It could be more complete by naming sibling alternatives or elaborating on max_passages, but those are minor gaps.

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

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

Schema description coverage is 67%, with url and question already described and max_passages constrained by min/max/default. The description adds the notion of relevance and passage context but does not clarify max_passages behavior beyond what the schema provides. This is a baseline 3 situation.

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 action ('Fetch a URL and extract the passages most relevant to a specific question') and a clear resource. It differentiates itself from sibling tools like fetch_url and search_web by emphasizing evidence extraction with context windows and verifiable citation offsets.

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 sentence gives an explicit trigger condition: 'Use this when you want to drill into a specific source for evidence on a narrow claim.' This clearly indicates when the tool is appropriate, though it does not explicitly name alternatives or state when not to use it.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: it uses Jina Reader, handles JS rendering and bot detection, and returns readable markdown text. This goes beyond the schema and annotations without contradicting them.

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 three concise sentences, each serving a purpose: declaring the core function, explaining the underlying mechanism, and listing suitable use cases. There is no filler or redundancy.

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

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

For a single-parameter tool with annotations and an output schema, the description is sufficiently complete. It covers the intended use, the behavior of the underlying reader, and the return format, leaving no critical gap for an agent deciding to invoke it.

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

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

Schema description coverage is 100%, with the 'url' parameter described as 'HTTP(S) URL to fetch.' The description adds little beyond this, only generalizing to 'any URL,' so it provides no significant additional parameter semantics beyond the schema baseline.

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

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

The description states a specific verb and resource: 'Fetch any URL and return clean markdown content.' This clearly differentiates fetch_url from the search-oriented siblings by describing a direct retrieval action on an explicit input.

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, noting it is 'Ideal for reading articles, papers, docs, or blog posts,' and explains that Jina Reader handles JS rendering and bot detection on the user's behalf. It does not explicitly name alternative tools or state when not to use it, but the contrast with search siblings is implicit.

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

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

Annotations already declare readOnlyHint=true, so the description's 'without executing it' aligns with that. Beyond annotations, it adds that the tool returns JSON with sub-questions, recommended sources, and cost estimates, and explains the workflow of passing the result to 'research'. This adds meaningful behavioral context without contradicting 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 four sentences with no filler. The primary purpose is stated first, followed by the return value, the usage scenario, and the follow-up action. Each sentence earns its place and the structure is front-loaded for quick comprehension.

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 read-only, has a simple two-parameter schema, and an output schema exists, so the description doesn't need to detail the return structure. It explains the full workflow (plan → review → execute with 'research') and is consistent with the sibling tool set. Nothing essential 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% – both 'question' and 'depth' have descriptions, and 'depth' includes enumerations. The tool description does not introduce any additional parameter semantics beyond that, so it meets the baseline for a fully described schema. It does add a hint that the question should be 'complex', but that's not a parameter-level detail.

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

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

The description names a specific verb ('Build'), a clear resource ('structured research plan'), and explicitly states it does NOT execute the research. It contrasts with siblings like 'research' by noting it returns a plan for review, differentiating it unambiguously.

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 ('when you want to review or edit the plan before committing') and implicitly when not to use it (when you want execution) by directing the agent to pass the returned JSON to the 'research' tool. This provides clear routing to the correct sibling.

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 are minimal (readOnlyHint, openWorldHint), so the description must carry the behavioral burden — and it does. It names the specific upstream sources (Wikipedia, arXiv, Hacker News, Stack Exchange, Crossref, Brave/Tavily), explains the config-dependent availability of some, describes the decomposition and evidence-extraction pipeline steps, details the exact ResearchReport structure, and explicitly assigns the synthesis-writing responsibility to the model ('the server does the gathering, not the writing'). This goes well beyond the annotations without contradicting them.

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 long, but every component earns its place: operation → pipeline mechanism → sources → return structure → model's responsibility → depth guidance. The front-loading of the core 'run a pipeline' phrase followed by progressive detail creates a logical, scannable flow. Minor stylistic blemishes (the semicolon-heavy middle and parenthetical digression about keys) are the only reason it doesn't get a 5; it could be slightly tightened without losing 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?

Given the tool's complexity — multi-step orchestration across 6+ external sources, configurable depth with nonlinear cost implications, and a rich structured output — the description covers all critical dimensions explicitly. It addresses dependencies ('if keys are configured'), delineates agent vs. server responsibility, enumerates the output contract, and offers per-level trade-offs. The output schema presumably details the ResearchReport shape, so the description's lack of that detail is acceptable. No meaningful gap left for an agent deciding whether and how to invoke this.

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 schema already documents both parameters well, establishing a baseline of 3. The description adds semantic value on top by re-framing the depth values by intent ('fast overviews,' 'normal research,' 'thorough multi-source investigations') and by showing how the parameter's granularity maps to pipeline trade-offs. It reinforces rather than merely restates the schema's mechanical counts (sub-questions, fetches).

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 precise verb+object pair ('Run a full deep-research pipeline on a complex question') and immediately unpacks what 'pipeline' means: decompose, fan out, fetch, extract, return structured output. It distinguishes itself from the search_* siblings by being the full orchestrated pipeline versus point lookups, and from plan_research/extract_evidence by stating that gathering and planning happen server-side while the model handles synthesis. An agent could confidently discriminate this from its siblings without opening the schema.

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

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

The description gives explicit, actionable when-to-use guidance via the depth parameter: "Use `depth='quick'` for fast overviews, 'standard' for normal research, 'deep' for thorough multi-source investigations." It also clarifies the model's post-call responsibilities (write the synthesis). However, it never explicitly says when NOT to use this tool versus calling one of the many search siblings directly (e.g., 'for a single fact check, prefer search_web'), which given 9 siblings would be the crowning touch.

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 read-only and open-world behavior MAP. The description adds the useful fact that no API key is required # and clarifies the output fields. However, it does not mention potential rate limits, pagination, or that results are limited to arXiv only, which would be additional transparency value.

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

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

The description is two concise sentences. The first immediately states the tool's purpose and scope; the second lists the output fields and notes no API key is needed. Information is front-loaded and there is no extraneous text.

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 presence of an output schema and a simple search use case, the description covers the essential aspects: what is searched, what is returned, and that no key is required. It does not detail search operators or pagination, but for a straightforward query on arxiv, the provided context is sufficient for an agent to make a reasonable 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?

With schema description coverage at 50% (only 'query' has a description, max_results does not), the description fails to compensate. It does not explain query syntax or the behavior of max_results beyond what the schema implicitly provides (a bounded default integer). This leaves the agent under-informed about parameter usage.

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

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

The description clearly states the resource (arXiv), the action (search), and the scope (academic preprints across all fields). This immediately distinguishes it from sibling search tools like search_web or search_news, and the inclusion of return fields (title, authors, abstract, PDF URL) further clarifies its role.

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 academic literature but does not explicitly compare against alternatives like search_scholar_meta or mention when not to use this tool. No guidance on query formatting or result limits is provided, so an agent would need to rely on external knowledge.

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 provide readOnlyHint and openWorldHint; the description adds the useful behavioral fact that no API key is required and discloses the return fields. It does not discuss rate limits or result ordering, but the annotation coverage lowers the burden.

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 no filler; the core action and resource are front-loaded, and the return fields and auth note each add value.

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

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

With an output schema present, return value details are already structured. The description covers the key selection signal (Hacker News source), simplicity, and auth. It could mention that it only searches Hacker News rather than the general web, but the tool name already conveys that.

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 50%: 'query' is minimally described and 'max_results' lacks a description. The tool description adds no parameter-specific meaning beyond the schema, and does not compensate for the undocumented max_results parameter.

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?

Description states a specific verb ('Search') and resource ('Hacker News') with a scope ('tech news, discussions, and trending links'), and lists the returned fields. This clearly distinguishes it from sibling search tools like search_web or search_wikipedia.

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

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

Usage context is implied by the Hacker News resource and the 'No API key required' note, but there is no explicit guidance on when to choose this over search_web or other search siblings, nor any when-not-to-use conditions.

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 declare readOnlyHint=true and openWorldHint=true, so the tool's safety profile is already known. The description adds valuable behavioral characteristics, such as 'No API key required' (lowering barriers) and specifying the coverage of publishers. It also implies the tool returns DOI, citation count, publication date, and abstract, which is useful but somewhat redundant with the output schema. No contradiction with 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 no waste. It front-loads the primary purpose and includes key differentiators (coverage of publishers, returns fields, no API key). It is structured well for an agent to quickly grasp the tool's function.

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 relatively simple with two parameters, both documented, and it has an output schema that presumably describes return fields. The description covers the key aspects: what it searches, what it returns, and the fact that no API key is required. It could mention pagination or result formats, but given the output schema likely handles that, the description is reasonably complete. The comparison to arXiv adds helpful context.

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

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

Schema description coverage is 50%: both query and max_results have descriptions, but they are minimal ('Search query' and default/max/min values). The description does not add much detail on what constitutes a good query or how max_results affects results. However, it does mention typical query types (e.g., searching for scholarly metadata) and implies that max_results controls result count. Given the schema already handles the basics, a baseline 3 is appropriate.

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

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

The description clearly states the tool performs a search on Crossref for scholarly metadata across multiple named publishers. It specifies the resource (Crossref) and the purpose (searching scholarly metadata), which differentiates it from siblings like search_web and search_wikipedia. The mention of 'peer-reviewed papers that arXiv may not' further distinguishes it from potential academic 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 description provides clear context for when to use this tool, such as when searching for scholarly metadata with DOIs, citation counts, and abstracts. It notes that it covers peer-reviewed papers that arXiv may not, implying a comparison with other academic sources. However, it does not explicitly state when not to use it or name specific alternatives like search_academic, which could be more explicit. Still, the context is useful enough.

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, so the agent knows this is a safe read operation. The description adds that no API key is required, which is useful context. It does not mention rate limits or result format, but given the readOnlyHint, the baseline for transparency is met. The description doesn't 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?

The description is concise, two sentences, with the most important information (what it searches, default site) front-loaded. The examples of alternative sites are useful and efficiently stated. No filler or redundant 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?

The tool is a simple search with a clear output schema (not provided but implied from signal). The description covers the core purpose, site parameter usage, and the no-API-key requirement. It lacks mention of result format or rate limits, but for a read-only search tool with a straightforward purpose, this is acceptable. The output schema likely covers return values, so the description doesn't need to.

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 67%: 'query' and 'site' have descriptions, but 'max_results' has no description in the schema. The description mentions the 'site' parameter and its examples, adding value beyond the schema. However, it doesn't explain the 'max_results' parameter semantics, leaving a gap. Since coverage is moderate, the description partially compensates but not fully.

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: searching Stack Exchange sites for technical Q&A, with a default of Stack Overflow. It distinguishes itself from siblings like search_web by specifying the platform. However, it doesn't explicitly differentiate from search_academic or other specialized search tools, but the platform specificity 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?

The description gives clear context on when to use this tool: when you need technical Q&A from Stack Exchange. It also provides examples of alternative sites via the 'site' parameter. It doesn't explicitly state when not to use it (e.g., for general web searches), but the focus on Stack Exchange is inferable from 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 discloses meaningful behavior beyond the annotations: results are aggregated from Brave Search and/or Tavily based on configured keys, deduplicated, cross-source scored, and returned with title, URL, snippet, and source. The readOnlyHint and openWorldHint are consistent with a read-only multi-source search tool, and the extra aggregation detail adds useful context.

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 three tightly packed sentences with no filler. The core purpose is front-loaded, followed by useful behavioral details and a clear default-use instruction, making each sentence valuable.

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 covers purpose, output shape, behavior with multiple sources, and default usage context. Combined with the output schema and annotations, it provides enough for an agent to use the tool correctly, though it could slightly improve by noting what happens if no API key is configured.

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 67%, with query and pro_mode described in the schema, but the description itself adds no parameter-specific meaning. The max_results parameter is self-evident by its name and schema constraints, so this is adequate but the description could have clarified that max_results applies after deduplication.

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: 'Multi-source web search.' It clearly states the aggregation behavior and return fields, making it easy to distinguish from specialized siblings like search_wikipedia and search_academic, even though those siblings are not explicitly named.

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

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

The description explicitly says 'Use as the default "search the web" tool,' which gives clear direction on when to choose it. It does not explicitly list what it should not be used for, but the 'default web search' framing strongly implies it is the broad general-purpose option among the more domain-specific 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?

The description shows the return data format (titles, URLs, snippets) and the 'No API key required' note is a useful practical detail about usage friction. Annotations carry weight here and are not 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, each carrying unique information: what it does, what comes back, and a friction detail. Nothing is wasted.

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

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

For a simple search tool with a small parameter surface and a defined response shape, the description covers the essentials. The main shortfall is lack of explicit routing guidance, which is common and minor here. An explicit 'if you need scholarly sources, use search_scholar_meta' would push this to 5.

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 50% schema description coverage, the description partially compensates by naming the return type and surfaces an important detail ('No API key required') that isn't in the schema. However, it doesn't add details about query format or semantics beyond what 'Search query' already states, so it doesn't fully cover the gap.

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

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

The description clearly states the verb+resource action ('Search Wikipedia') and lists the return payload contents. It doesn't explicitly distinguish itself from siblings like search_web or search_news, but its focus on the Wikipedia domain is enough to generally separate it.

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 states a clear benefit ('No API key required') that helps determine when to use it, but there's no explicit when-not-to-use guidance or alternative tool naming. The sibling list and scoping might be clear enough for some agents, but explicit exclusions (like 'for general web, use search_web') would strengthen it.

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