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

Goes well past the annotations: it explains that my_view is deliberately withheld from the remote model so answers stay independent and is echoed back for comparison, that lenses are answered independently in parallel, and that results are UNVERIFIED output from a weaker model to be weighed below your own analysis. This is exactly the behavioral context the readOnly/openWorld hints cannot convey.

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

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

Front-loads the purpose and trigger in two short lines, then uses a compact per-parameter list where every line adds distinct information. The closing warning about unverified suggestions is a third short sentence that earns its place by changing how the agent should weigh results.

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, the description correctly omits return-value details and instead covers cost model, independence semantics, and result trust level. The one omission is the 'thinking' parameter (high/max), which an agent could not infer from the description alone.

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 carries the full burden and does it: question, context (including what to include and what was already ruled out), lenses with a concrete example and a hard cap of 4, my_view with its unusual non-transmission semantics, and project_dir with a precise conditional ('only if Deputy picked the wrong folder'). Only the 'thinking' enum parameter is undocumented, which is a minor gap against five well-specified parameters.

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 — brainstorm with a cheaper model to surface ideas, risks and alternatives — and adds a scope note ('not on every task') that separates it from exhaustive siblings like review or investigate. It stops short of naming a sibling tool to contrast against, so the differentiation is inferred rather than explicit.

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 trigger ('when you are unsure between approaches or stuck') and an explicit exclusion ('not on every task'), which most definitions omit. It never points at the sibling tools (review, investigate, delegate) as the alternative for cases outside this trigger, leaving the routing decision partly to inference.

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

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

Beyond the annotations, the description discloses that Deputy operates autonomously in the workspace, edits files, runs commands, and returns a short report listing changed files. It also adds an important operational warning to verify results and run tests, which is exactly the kind of behavioral context needed for a destructive, open-world delegation 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 front-loaded with the core action and then uses compact parameter notes. Every sentence contributes either selection guidance, parameter semantics, or necessary verification advice.

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 complex, destructive delegation operation, and the description covers autonomy, scope, reporting, verification, and all five parameters. Because an output schema exists, it does not need to explain return structure further.

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%, and the description compensates fully: it explains task, context, thinking modes, workdir semantics, and the narrow use case for project_dir. This adds meaning well beyond the bare schema titles 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 a specific verb and resource ('Hand a well-specified coding task to Deputy') and explains that Deputy autonomously reads/edits files and runs commands. It implicitly distinguishes this from siblings such as review or consult by emphasizing autonomous coding work, but does not explicitly name or differentiate those 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?

It gives a clear usage rule: in accuracy mode, delegate only when the user explicitly asks for delegation. It still leaves the exact boundary versus consult, review, and investigate implicit, so it is strong but not fully explicit about alternatives.

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 read-only, non-destructive, idempotent, and open-world behavior. The description adds useful operational context beyond that: Deputy can only list, read, and search files, returns compact answers with file:line evidence, and its output should be treated as leads. It does not cover latency, cost, or depth of investigation, but it meaningfully extends the 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?

The description is compact and front-loaded with the primary use case before adding the evidence caution and project_dir note. Every sentence contributes, though the final project_dir sentence is somewhat awkwardly appended rather than integrated. It is appropriately sized for an invocation guide.

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 does explain the answer format as compact with file:line evidence. However, with five parameters and 0% schema description coverage, the description leaves too much unexplained for reliable invocation. It is adequate for understanding the tool's purpose but incomplete for tuning parameters like context, workdir, and thinking.

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% across five parameters, so the description must carry the burden of explaining them. It only explains project_dir as an absolute path to use if Deputy picked the wrong folder; context, workdir, question, and thinking are left undocumented. The most important parameter, question, is implied by the overall purpose but not given semantic guidance.

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 use case: asking Deputy a question that requires extensive reading across files, with examples like locating handling logic, understanding a flow, or interpreting a large log. It clearly states what the tool returns, compact answers with file:line evidence. It does not explicitly differentiate itself from siblings such as consult or review, so it falls short of a 5.

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

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

The description provides clear when-to-use guidance: questions that need a lot of reading, where something is handled, how a flow works, or what a large log says. It also warns that the answer should be treated as leads and cited lines should be read before acting. It does not name alternatives or when not to use it, so it is strong but not complete.

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

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

Beyond readOnlyHint the description discloses the default input source (git diff against HEAD plus new files), the default lens set, the default low thinking budget, and that findings are UNVERIFIED and may be false positives with instructions to confirm and report rejections. This is exactly the operational context annotations cannot carry.

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?

Purpose, applicability, defaults, parameters and the verification caveat arrive in that order with no filler. The per-parameter lines are terse and each conveys a default or a decision the caller must make.

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, the description need not explain return values, and everything else an agent needs is covered: when to call, what gets reviewed by default, how to override inputs, how to bound cost via lenses/thinking, and how to treat the output. Nothing material is missing for a 7-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: focus, diff, base (with a 'main' example), paths, lenses (with the actual default list), thinking (with default and 'high'/'max' meaning), and project_dir with a narrowing condition. Each of the 7 parameters is explained in terms of intent, not just 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 first sentence names the operation ('review'), the mechanism ('independent cheap reviewers... one per lens, in parallel') and the object ('a change'). That mechanism is distinct from siblings like investigate, consult and delegate, so the agent can tell them apart without further reading.

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

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

It gives an explicit when ('risky or large changes') and when-not ('not routine ones whose tests pass'), which is stronger than most definitions. It stops short of naming alternative tools, so the agent must infer that routine work should skip this and use nothing or a lighter 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Makes no network calls' largely restates the closed-world hint. The one genuinely additive signal is 'roughly', which tells the agent the figures are approximate and not billing-grade. No further behavioral context (e.g. what 'saved' is measured against) is given.

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 substantive content (what is reported and over which time windows) front-loaded. The trailing 'Makes no network calls' is the weakest clause since annotations already convey a closed-world read operation, but the overall size is appropriate.

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, rich annotations, and no parameters, the description only needs to state what the report covers — which it does, including the time buckets and the approximation caveat. The remaining gap is the lack of differentiation from the 'status' sibling.

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 takes zero parameters, so there is no parameter semantics burden; the schema is empty and nothing needs compensating. Baseline 4 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 names a concrete verb ('Show') and a concrete resource (token and money savings attributed to Deputy), plus the scopes reported (session, today, 7 days, all time). It does not, however, distinguish itself from the sibling 'status', which an agent could reasonably assume overlaps with a stats/savings report.

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

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

Usage is only implied: an agent infers it should call this when it wants a savings summary. There is no explicit when-to-use/when-not statement and no reference to the alternatives (status, review, investigate), so the routing decision is left to the reader.

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, non-destructive, and openWorldHint=false; the description reinforces the last one with the concrete promise of no model-provider network calls, which is meaningful cost/latency context rather than repetition. It also characterizes the payload (session spend and savings), which is behavioral detail not present in 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?

Two sentences, no filler, with the capability enumeration front-loaded and the network-call caveat placed correctly as a secondary qualification. The comma-separated list is dense but each item is load-bearing, so nothing could be cut 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?

Return values need not be spelled out since an output schema exists, and the safety profile is fully covered by annotations. The description covers what is inspected and the no-network guarantee. The one real hole is the unexplained `project_dir` argument, which leaves a caller guessing on an otherwise complete definition.

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 single `project_dir` parameter has 0% schema description coverage and a bare empty-string default, so the description is the only place its meaning could be conveyed — yet it is never mentioned. The agent cannot tell whether project_dir scopes the workspace reading, affects spend accounting, or is optional in practice.

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?

A specific verb ('Show') tied to an enumerated resource set: mode, model, thinking level, workspace, key presence, and session spend/savings. An agent can tell exactly what comes back. It stops short of 5 because it never distinguishes itself from the sibling `stats`, which plausibly overlaps on the spend/savings portion.

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

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

Usage is only implied — an agent infers this is the cheap diagnostic/configuration check, aided by 'Makes no network calls to the model provider' which signals it is safe and low-cost to call. There is no explicit 'use this when X, use stats/consult when Y', and no stated prerequisite or trigger condition.

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