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

With no annotations, the description must carry the behavioral burden, and it does disclose one important constraint (the answer must come from the user, not the agent). However, it says nothing about what recording an answer triggers, whether the answer is final, or what the choice values (extend, session, deny, end) mean in effect.

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

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

A single sentence with zero filler; the operative constraint is placed in parentheses right after the core action, so the most important guidance is front-loaded and hard to miss.

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

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

An output schema exists, so return values need no explanation, and the description covers the critical safety rule for this mutation tool. It is thin on the approval lifecycle (what recording the answer causes), but nothing an agent needs to invoke it correctly is absent.

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

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

Schema description coverage is 67%: 'choice' and 'user_reply' are documented in the schema (including the allowed values), while 'approval_id' is undescribed in both places. The description adds no parameter-level meaning beyond what the schema already states, so the 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?

Names a specific verb ('Record') and a specific resource ('the USER's answer to an APPROVAL REQUIRED message'), so an agent knows exactly what data flows into this tool. It does not compare itself to the siblings (research_start, web_search, web_fetch), but those are in unrelated domains, so the risk of confusion is low.

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 parenthetical gives an explicit precondition and prohibition: 'ask the user first; never answer for them.' That tells the agent the condition under which this tool may be called. It stops short of naming alternatives or describing the surrounding approval workflow, which would be needed for a 5.

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 behavioral burden. It discloses that the call returns a session_id, today's date, budget and rules, but says nothing about whether repeated calls create duplicate sessions, whether sessions expire, or any side effects -- gaps that matter for a session-creating tool with zero annotation coverage.

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 the prerequisite front-loaded and zero filler. The trailing enumeration of return values is mildly redundant given an output schema exists, but it is brief enough not to waste space.

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 5-parameter tool with full schema coverage and an output schema, the description supplies the critical missing piece: the mandatory ordering before searching. It leaves minor gaps around session lifecycle and reuse, but nothing that would cause an obviously wrong invocation.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters (including the depth-to-budget link). The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource ('Start a web research session') plus the ordering constraint '(required before searching)', which lets an agent distinguish this prerequisite call from the search tools. It does not explicitly differentiate itself from the sibling research_approve, so it stops short of a 5.

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

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

Gives a clear condition for use -- it must be called before any searching -- which is the key routing signal an agent needs. It stops short of naming alternatives or stating exclusions (e.g. when research_approve is appropriate, or whether a session is reusable).

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 does disclose two non-obvious traits: output is filtered to focus-relevant passages rather than the full page, and the fetched content is untrusted data (a prompt-injection safety signal). It omits rate limits, error behavior, and how session_id is obtained.

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, fully front-loaded: action and scope first, safety note second. No filler, every clause 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-value detail is not required, and the description covers formats, filtering, and trust level. Remaining gaps are minor: session_id's origin and max_tokens interaction with the filtered output are left implicit.

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 75% and the schema already documents focus, target, and max_tokens ('output cap'). The description reinforces what focus does (passage filtering) but adds no syntax or format detail for target or session_id, so the baseline of 3 applies.

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

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

States a specific verb ('Read') and resource ('one page (HTML/PDF/text)') and adds scope ('returning only passages relevant to focus'). It is clearly distinguishable from web_search by implication (read one page vs search), though it never names the sibling or contrasts explicitly.

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: give a URL or result id and a focus to get extracted passages. There is no explicit when-to-use vs web_search, nor any statement of prerequisites (e.g. obtaining session_id or a result id from web_search).

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 usefully discloses two behaviors an agent could not otherwise predict: results come back ranked with ids (S1..), and each call consumes a limited budget. It says nothing about rate limits, quota exhaustion, or error/auth behavior when the budget runs out.

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

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

Two short sentences, front-loaded with the purpose and then the return shape. Every clause earns its place, with no restatement of the title or name.

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

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

An output schema exists, so the description is not obliged to detail return values, yet it still surfaces the ranked-id convention and the budget dimension. Missing only prerequisites linking session_id to research_start and any fallback behavior, which keeps it just under 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 80% and the schema itself documents site, query, freshness, and max_results, so the description need not re-explain them. The description adds no parameter-level meaning beyond the schema, which is the expected baseline here.

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 ("Search the web") plus its scope ("within a research session"), which is enough to separate it from research_start and research_approve. It does not explicitly distinguish itself from the closest sibling, web_fetch, so it stops short of a 5.

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

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

"Within a research session" implies the tool requires a session established by research_start, but there is no explicit when-to-use or when-to-prefer-web_fetch guidance and no exclusions. Usage is inferable rather than stated.

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