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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's job is to add operational context — and it does: depth governs how many searches and page reads are spent, cache=refresh bypasses cached answers and pages, and the reply is identical in shape to web_research. It stops short of disclosing latency, cost, or what happens when include and exclude domains conflict.

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 with zero filler; the control axes are front-loaded and the reply-parity note is the right closing clause. Nothing redundant or padded.

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

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

For an 8-parameter tool with a nested domains object, the rich schema (100% coverage) and full annotations carry most of the burden, and 'Same reply as web_research' covers the absent output schema. The description is adequate, though it never touches the two required parameters (question, goal) or the cost/latency implications of depth, which matter for an open-world research 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 description coverage is 100%, so the baseline is 3. The description largely restates schema content (depth = searches and page reads, recency, domain filters, cache refresh) rather than adding new semantics such as how 'quick' vs 'deep' differ numerically or precedence rules for include/exclude.

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 ('Research') and enumerates the control axes (depth, recency, domain filters, cache refresh), which differentiates it from web_research via 'full control' and reply parity. It does not distinguish itself from web_lookup, web_read, or web_page, so an agent must infer that this is the multi-step agentic variant.

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?

'Same reply as web_research' combined with 'full control' implies the routing rule (use this when you need to tune cost/recency/domains, use web_research otherwise), but the alternative is never named as a choice or paired with an explicit condition. No when-not-to-use or cost tradeoff guidance is given.

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

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

The annotations already declare readOnly, openWorld, idempotent, and non-destructive, so safety is covered. The description adds value beyond that by disclosing the response contract (short answer plus numbered sources) and that answers are truncated to the goal rather than truncated arbitrarily, which tells the agent how to interpret output length.

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

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

Three short sentences: purpose, return shape, usage trigger. Zero filler, and the answer-format detail is placed before the routing guidance so the agent reads the most load-bearing facts first.

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

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

There is no output schema, and the description correctly fills that gap by stating the return shape (short answer with numbered sources). With rich annotations and a fully documented two-parameter schema, the only real omission is sibling differentiation, which keeps it from a 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?

Schema coverage is 100% and both parameters carry their own descriptions, so the schema does the work. The description adds no field-level guidance (e.g., how to phrase the question, or when to raise max_tokens), so it neither compensates nor detracts — 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 gives a specific verb and resource (answer a question from the web) plus the return shape (short answer with numbered sources), so the agent knows this is a Q&A-over-web tool rather than a fetch tool. However, it never distinguishes itself from close siblings such as web_research or web_investigate, which plausibly overlap in 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?

"Use it for facts you do not know or that may have changed" gives a clear selection condition tied to knowledge gaps and recency. It stops short of naming when NOT to use it or which sibling (web_research, web_investigate) to prefer for deeper investigations.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape (compact answer plus findings), the grounding guarantee (verbatim quotes checked against the page), and the size cap. It doesn't cover failure modes such as unreachable pages or paywalls.

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, no filler, with the core action and scope front-loaded before the return-value detail. Every clause carries information an agent needs.

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

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

With no output schema, the description correctly takes on the job of explaining what comes back (answer, findings, verified quotes, token cap). Parameters and safety are handled by schema and annotations. Only the absence of error/edge-case behavior keeps it from a 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?

Schema description coverage is 100%, including a security warning on 'goal' and the enum meanings for 'format', so the schema does the heavy lifting. The description only restates the max_tokens ceiling already documented in the schema, adding no new syntax or constraint detail. Baseline 3 applies.

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

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

States a specific verb and resource ('Read one known web page') plus the scoping constraint 'for a stated goal', which implicitly separates it from discovery-style siblings like web_lookup and web_research. It stops short of naming those siblings explicitly, so differentiation requires a small inference.

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

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

The qualifier 'one known web page' hints that this is for a single, already-identified URL rather than open-ended search or multi-page investigation. However, no alternative tool is named and there are no stated exclusions, so the when-not guidance 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, idempotentHint, non-destructive and openWorld, so the safety profile is covered structurally. The description adds that results are brief and attributed to a source, which is useful output context, but it says nothing about fetch failures, paywalled/JS-rendered pages, or truncation behavior beyond max_tokens.

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 with no filler, and the core action plus output shape come first. The phrasing is slightly informal ('say briefly what it says') but nothing is redundant.

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

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

There is no output schema, so the description must carry return-value information — and it does, promising a short summary with the source. Combined with full schema coverage of all three parameters and rich annotations, this is close to sufficient; only guidance on failure modes and sibling choice is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented, establishing a baseline of 3. The description reinforces the optional-question semantic ('get only that part') but adds no syntax, format, or edge-case detail beyond the schema.

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

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

States a specific verb and resource ('Read one web page') and even describes the shape of the output ('say briefly what it says, with the source'). The word 'one' implicitly contrasts with the multi-page siblings (web_research, web_investigate), but no sibling is named, so an agent must infer the boundary.

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?

'Give a question to get only that part; omit for a summary' implies the two usage modes (targeted extraction vs. full summary), which is genuine guidance. However, there is no explicit statement of when to prefer this over web_lookup, web_page, web_research, or web_investigate, leaving the agent to guess.

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, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuine context beyond that: the exact shape of the reply and the fact that output length is bounded by max_tokens. It does not disclose latency, cost, or what happens when the web yields nothing useful.

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 filler, and the core action is front-loaded ahead of the return description. The enumerated return fields earn their space because there is no output schema to carry them.

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

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

With no output schema, the description correctly shoulders the burden of describing the return value (answer, confidence, findings, sources, gaps) and the size cap. Safety is covered by annotations and every parameter is documented in the schema. What remains missing is the sibling differentiation and any note on freshness or failure behavior.

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 question, goal, format and max_tokens are already documented, including the notable 'never put secrets here' warning on goal. The description only restates the max_tokens ceiling, adding no syntax or format nuance 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?

States a specific verb (research) and resource (a question on the web) plus the required framing (a stated goal), and goes further by naming what comes back: answer, confidence, verbatim-quote findings, sources, gaps. It never distinguishes itself from the sibling tools (web_lookup, web_read, web_page, web_investigate), so the agent must infer which of the family to call.

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

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

Usage is implied by 'for a stated goal' — a goal-bearing research call rather than a raw fetch — but there is no explicit when-to-use, when-not-to-use, or named alternative among the four sibling web tools. The agent gets a flavor of the tool's role without a routing rule.

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