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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses session-only scope, that it never writes a persistent agent rule, that it blocks until the turn finishes or needs input, that the server imposes no time limit, and what happens if the client times out. It also states the possible result values and how to respond to 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 front-loaded with the core action and session-scoping rule, then proceeds to blocking behavior, timeout handling, and return values. It is information-dense and mostly earns its length, though a few clauses could be tightened without losing meaning.

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 absence of annotations, three parameters, and an output schema, the description is complete enough for correct invocation. It covers scope, blocking behavior, timeout recovery, and the approval/question result states, leaving no major operational gap.

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 session, approval_id, and wait in detail. The description adds some contextual meaning by explaining that approval_id comes from an approval_needed result, but it does not materially extend the parameters beyond what the schema already says. 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 states a specific verb and resource: allow an approval and stop asking for similar calls in the current session only. It directly distinguishes this session-scoped behavior from a persistent rule and names approve/reject/answer as related choices, so an agent can tell what this tool does 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?

It gives clear usage context: use this to answer an approval_needed result when you want matching requests allowed for the session, and it names approve / allow / reject as the approval alternatives. It also gives explicit timeout guidance to call status or output instead of resending the task. It stops short of explicitly contrasting allow with approve in a single routing sentence, so it is strong but 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 does well: it discloses blocking behavior, no server time limit, timeout resilience with running turn, and the return state that triggers approval vs question. This is rich behavioral context beyond the schema.

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 is front-loaded and most sentences earn their place, but the final sentence repeats return-state information already implied and the blocking sentence is dense.

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 5 parameters, nested content, and an output schema, the description covers critical operational details: blocking, timeout recovery, action semantics, and return-state branching. 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 coverage is 100% (baseline 3), but the description adds meaning by linking content keys to requested_schema and clarifying action defaults and semantics beyond the schema's terse descriptions.

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+resource ('Answer a question the agent asked (question_needed)') and explicitly distinguishes itself from the approval flow (approve/allow/reject) and status/output alternatives for timeouts.

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 says when to use it (question_needed), what each action does, and when to use alternatives (status/output on timeout instead of resending). Leaves no inference required.

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 burden and does so well: it discloses blocking until the turn finishes, no server-side time limit, and that timed-out turns continue running rather than failing. It also describes the two return states and the follow-up actions for each.

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 adds blocking/timeout behavior, which are operationally important. It is dense but every sentence contributes useful information, with no obvious padding.

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?

Because an output schema exists, the description need not explain return values exhaustively, but it still covers the important states. The main remaining gaps are the semantics of option_id and the distinction between approve / allow / reject. For a blocking approval tool with no annotations, it is otherwise complete enough for correct 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 coverage is 75%, so the schema already documents wait, session, and approval_id. The description mentions option_id explicitly but does not explain its allowed values or where it comes from. The wait parameter is not discussed in the description at all.

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: allow a pending tool call or explicitly choose an option. It also names the related result states and sibling actions (approve / allow / reject / answer), making the tool's role reasonably clear. It stops short of sharply distinguishing approve from its siblings allow and reject.

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: use it when a result is "approval_needed" or "question_needed". It also names alternatives for the timeout case (status and output instead of resending). It does not explain when to choose approve versus allow or reject.

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 does disclose the return-state semantics ('cancelling' until the agent confirms, 'done' when already idle), which signals partial idempotence in the already-idle case. It says nothing about whether in-flight work is discarded, whether the call blocks, or what permissions are needed.

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 tightly written sentences: the operation and its scope come first, and the return-state detail follows. Nothing is padded or repeated.

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 and the sole parameter fully documented, this is close to complete; the description's return-value explanation is a small redundancy rather than a gap. What remains unstated, chiefly what cancel does to in-flight work and how it differs from close or reject, is minor for a one-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 coverage is 100% and the single 'session' parameter is documented in the schema as the id returned by open. The description adds no meaning beyond that, 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?

The description uses a specific verb plus a scoped resource ('cancel the current turn'), which is far clearer than a bare 'cancel'. However, it doesn't distinguish itself from similarly named siblings such as reject or close, leaving the agent to 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?

'The current turn' implies usage context: you call it mid-turn, not against a whole session. That said, there is no explicit guidance on when to choose cancel over reject, close, or delete, so the selection logic remains inferential.

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. It usefully discloses two consequences: omitting the session closes *all* sessions on this server, and session history is preserved. Still, it does not clarify whether closure is reversible, what happens to running work, or any permission requirements, leaving meaningful gaps for a potentially broad state-changing operation.

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, front-loaded sentence with no wasted language. It states the core action, the omitted-parameter behavior, and the key side effect (history retained) efficiently.

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 one-parameter tool with an output schema and full schema description coverage, the description covers the essential call semantics and a key side effect. It could be richer about permissions or the effect on active work, but it is largely complete for correct 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 coverage is 100%, so baseline would be 3. The description adds meaningful semantics beyond the schema by explaining that omitting the optional 'session' parameter closes every session on the server, whereas the schema only documents the parameter as a session id returned by 'open.'

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 a specific verb and resource: 'Close a session, or all sessions of this server when session is omitted.' This is unambiguous. It indirectly distinguishes itself from 'delete' by noting 'Session history is kept,' but does not explicitly name sibling alternatives such as 'cancel' or 'delete.'

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 through the omission behavior: providing no session closes all sessions, while providing one closes that session. However, the description gives no explicit guidance on when to use this tool versus alternatives like 'cancel,' 'delete,' or 'open,' nor does it state exclusions or prerequisites.

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 for a destructive tool. It hints at a cascade ('and its native agent session') but never says whether the delete is permanent or reversible, whether elevation/permission is required, or what happens when the session is 'archived' or 'unsupported'.

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 front-loaded sentence with the core action first. The trailing parenthetical is the only part that does not clearly earn its place because its meaning is not resolvable from the 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?

An output schema exists, so return values need no explanation. However, for a destructive single-target tool with zero annotations, the description leaves out irreversibility, the distinction from 'close', and failure behavior, which an agent needs before invoking.

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?

Only one parameter, and the schema documents it fully at 100% coverage ('Session id returned by open'). The description adds no meaning beyond the schema, so 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 names a specific verb and resource (delete a session), and adds that the native agent session goes with it. But it never distinguishes itself from the sibling 'close', which for an agent could look like the same intent, and the parenthetical '(deleted / archived / unsupported)' is cryptic enough that the actual effect is unclear.

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?

There is no statement of when to use this versus 'close' or 'cancel', which are the obvious alternatives in the sibling list. No prerequisites, no confirmation guidance for a destructive operation.

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 burden. It discloses the return content (input, output, diffs) but does not state whether the operation is read-only, whether it requires specific permissions, or any rate limits for polling, leaving gaps for a read 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?

Two sentences, front-loaded with the purpose. The phrasing is efficient with no wasted words, though the first sentence is slightly complex due to the embedded return description.

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 a simple 2-parameter tool with an output schema and full schema coverage, the description is nearly complete: it explains what it does and when to use it. The main missing element is explicit disclosure that it is a read-only operation, which would be helpful without 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds minor context about the id coming from snapshot, but provides no additional meaning for the session parameter 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 it retrieves one conversation item in full by id, and specifies the returned content (tool call with input, output, diffs, or any other item). It distinguishes from the sibling snapshot tool by clarifying it provides full details for on-demand viewing.

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 says it is for UI clients that poll snapshot with simplify and show details on demand, implying it should be used after obtaining an id from snapshot. The alternative (snapshot) is named in context, though not with an explicit 'use this instead' phrasing.

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 well: it discloses that creation has an on-disk dimension ('latest closed one on disk'), that reconnect restores prior config (subagent config or later set_config changes), and that a failed reuse silently creates a new session and reports `reuse_skipped`. It stops short of saying whether created sessions need explicit `close`/cleanup or what permissions are required.

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-loaded with the core action, then the mode branches, then the return contract, then the scope exclusion. It is dense but every clause carries information; the semicolon-chained first sentence is the only readability cost.

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 an output schema and no annotations, the description covers the mode logic, side effects, config restoration, failure fallback, and what is returned (session id plus config_options). Only the meaning of `subagent` and the contents/persistence implications of a created session are left unstated.

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 60%, and the description compensates: it defines `reuse` semantics (idle session with same cwd and subagent, else latest closed on disk), clarifies the `session` id came from a prior open, and ties `role` to the role prompt included at setup. `subagent` itself is never explained, leaving one 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?

States a specific verb+resource ('Open a session') and immediately decomposes it into three distinct modes (reconnect by `session`, reuse idle/latest-closed, fresh create). It also explicitly distinguishes scope from the `prompt` sibling ('It takes no task: send tasks with `prompt`'), so an agent can separate it from the other session tools without opening a 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?

Each parameter combination is mapped to an action: pass `session` -> reconnect, pass `reuse` -> take this server's idle session with matching cwd/subagent else the latest closed one on disk, otherwise create. It also names the follow-up alternative for tasks ('send tasks with `prompt`') and explains the fallback when reuse fails.

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, but it discloses almost nothing: whether the call blocks until a turn completes, what happens if no turn has occurred yet, or whether it is a pure read. Only the notion of 'most recent turn' hints at recency semantics.

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 short sentence with no filler, front-loading the returned artifact. It is terse to the point of being a fragment, but 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?

An output schema means return values need not be explained, but with 16 siblings and a generic name like 'output', the description should clarify retrieval semantics, blocking behavior, and error conditions. Too much is left to inference for an agent choosing among close alternatives.

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% and the single required 'session' parameter is documented in the schema as an id returned by open, so the schema does the heavy lifting. The description adds nothing about which session or how the parameter scopes the returned turn.

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 fragment 'Final reply of the most recent turn' implies a retrieval of the last assistant reply for a session, which is a discernible purpose. However it omits the verb entirely and gives no way to distinguish it from siblings like progress, status, item, or snapshot, which could all plausibly return per-session content.

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?

There is no statement of when to call this versus the many sibling read/monitoring tools. An agent must infer that this is the way to read the last reply, with no conditions or exclusions offered.

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 key traits: it is cheap, never blocks, and is non-essential to task execution. It does not state error behavior for an invalid session id or whether the snapshot is live or cached.

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, content listed first and the usage caveat plus cost note after. Every clause carries information; nothing is repeated from the schema.

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 described further, and the one required parameter is fully documented in the schema. The description is sufficient for correct invocation, with only minor gaps around stale/error 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% and the single parameter is documented as "Session id returned by open", so the schema does the work. The description adds nothing about the session parameter, which is acceptable at baseline 3.

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 the resource precisely — plan, context usage, session title, slash commands — so an agent knows it retrieves execution progress for a session. It does not explicitly differentiate itself from siblings like status or output, which read as similar diagnostic 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?

"Not needed to run a task; call it only when you want to know" gives a clear when-not-to-use rule, which is unusual and valuable. It stops short of naming an alternative sibling (status/output) for agents that need diagnostics.

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 and does so: it discloses blocking semantics, that the server imposes no time limit, what happens to the turn on client timeout, and the connection staying alive. It also names the two terminal return states ("approval_needed", "question_needed") and the tools that resolve 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?

Front-loaded with the primary action and the exception states, and the timeout guidance is placed where it prevents a costly mistake. Slight redundancy in the closing sentence, which restates the approval/question return values already introduced in sentence two and partly covered by the output schema.

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 blocking, state-dependent tool with no annotations, this covers preconditions, failure mode, recovery path, and return states. An output schema exists, so the description needn't detail payload shape, and the named return markers are a helpful addition rather than a gap.

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% — wait is documented in the schema and session points at open, but text has no description anywhere. The description implies the task content and that session is a live IDLE session, yet adds no format, size, or content guidance for text beyond what the schema already implies. Baseline 3 is appropriate at this coverage level.

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 ("Send a task to an IDLE session") and immediately distinguishes behavior from the approval/question path and from the sibling tools status/output/approve/answer. An agent can tell what this does versus open, status, and output without opening any 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?

Explicit preconditions (session must be IDLE; ASKING/QUESTIONING returns the pending approval instead; idly-closed sessions are reopened first) plus an explicit anti-pattern: on client timeout, do not resend — call status and output instead. Alternatives are named by name.

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 does so well: it discloses blocking behavior, no server time limit, client-specific turn outcomes, timeout behavior, connection persistence, and the approval_needed/question_needed return states. This is unusually rich behavioral context for an agent.

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 packs several important behavioral details without filler. It is dense and semicolon-heavy, but each clause conveys operational 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?

For a blocking action with no annotations and an output schema, the description is complete enough to invoke safely: it explains blocking behavior, timeout handling, return states, and what to do instead of retrying the task. No critical invocation context appears 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%, and the schema already documents session, approval_id, and wait. The description adds workflow context around approval_id but does not materially extend the meaning of the individual parameters beyond what the schema provides.

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: "Reject this tool call." It also situates the action in the approval workflow by naming approve, allow, reject, and answer as related responses. It does not explicitly contrast with the sibling cancel tool, so sibling differentiation is useful but not complete.

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 names approve, allow, reject, and answer as alternatives, and says to call status/output after a client timeout instead of resending the task. However, it never explicitly says when to choose reject over approve/allow or cancel, so the selection guidance is mostly 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?

With no annotations, the description carries the full burden, and it does disclose useful traits: the data source ("on disk"), sort order, and the returned fields. It omits pagination/result limits, whether this only sees sessions in the current directory, and any read-vs-mutation framing beyond the verb "List".

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, with the output shape and ordering front-loaded before the usage hint. Nothing is repeated from the schema or restated from the title.

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 fields need not be spelled out, and the description is adequate for a simple list call. But with no annotations and an undocumented `cwd` parameter, it should say whether listing is scoped to a directory and whether results are capped.

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 only 50%: `status` is documented in the schema, but `cwd` has no description anywhere. More importantly, the description never mentions that the result set can be filtered by `cwd` or `status` at all, so an agent reading only the description would not know these filters exist.

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 ("List sessions on disk") plus ordering ("most recent first") and the fields returned, so the agent knows exactly what it gets back. It does not explicitly distinguish itself from the sibling `subagents`, which also enumerates things, so the differentiation is implied rather than stated.

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 to find a session id after an interrupted open" gives a concrete triggering scenario, which is more than most list tools offer. It stops short of naming alternatives (e.g. `status` for a single session) or saying 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?

With no annotations, the description carries the full behavioral burden and discloses the return value, failure behavior with available choices, and the side effect of reopening an idle session. It does not discuss permissions, reversibility, or persistence, so it is strong but not complete.

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 tight sentences, front-loaded with the core action. Each sentence adds useful information: return value, validation failure, and idle-session reopening.

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 an output schema and no annotations, the description covers the key mutation behavior, error handling, and reopening behavior. The remaining gap is fuller parameter semantics for config_id and value.

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 only 33%, so the description must compensate. It helps by naming example config ids and explaining that unknown ids or values fail with available choices, but it still leaves config_id and value formats somewhat implicit.

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 uses a specific verb, "Change," and a specific resource, "session config option," with examples like model, reasoning_effort, and mode. It is clearly distinct from sibling session lifecycle tools, though it does not explicitly route against any alternative.

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 when to use it: changing a session configuration option. It also explains error behavior and idle-session reopening, but gives no explicit when-not guidance or alternative comparison.

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 well: it discloses that output can be large, supports incremental retrieval via seq, has special behavior for ack and simplify, and can be reduced to header fields for polling clients. It does not discuss permissions or sensitivity, but the core behavioral traits are covered.

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 dense but front-loaded with what the tool returns, then immediately covers size, filtering, incremental retrieval, and UI-client patterns. Every sentence is relevant, though the paragraph is long and somewhat run-on.

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 eight optional parameters, an output schema, and no annotations, the description provides enough context to call the tool correctly: it explains content scope, output size risk, filtering strategies, incremental updates, and polling-client behavior. No critical agent-facing information appears 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 coverage is 100%, so the baseline is 3, but the description adds meaningful usage semantics beyond the schema: how to keep results small, how server_id and seq feed into since, and how ack/simplify are intended for UI polling clients. It does not explain every parameter individually, but it adds practical interpretation.

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 that this returns a full conversation snapshot for open sessions, including prompts, replies, thinking, tool calls, plans, approvals, and related state. It is specific about the resource and contents, but does not explicitly differentiate itself from most sibling tools; the reference to 'item' is the only routing signal.

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 usage guidance: pass session to narrow scope, use last/types/exclude_types to keep results small, use since with server_id and seq for incremental changes, ack for notification-relaying UI clients, and simplify plus item for polling UI clients. It names the alternative, item, for retrieving one full item.

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 well: it discloses that calls are cheap, that closed sessions report CLOSED with last values, and that a blocking call may be waiting. It does not explicitly state that the operation is read-only or side-effect free, but the nature of status reporting makes that largely implicit.

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: it first enumerates what status reveals, then notes polling cost, then points config decisions to siblings. Every sentence provides useful information 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?

Given an output schema, the description need not explain return values. It still covers the important behavioral edge cases (closed sessions, blocking calls, repeated polling) and routes config-related needs away from this tool. For a one-parameter status tool, 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?

The single 'session' parameter is fully described in the schema as the id returned by open. The description does not add syntax or format detail beyond the schema, so the baseline 3 applies for high schema 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?

The description states precisely what the tool reports: session state, cancelling flag, config values, pending approvals/questions, and blocking-call waits. It also distinguishes its scope from config-related siblings (open, set_config, snapshot). For a broadly named 'status' tool, this is specific and actionable.

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 clearly supports repeated polling ('Cheap to call repeatedly') and redirects config inspection to open, set_config, and snapshot. It does not explicitly route pending approvals/questions to approve, answer, or reject, so the alternative-selection guidance is strong but not 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?

No annotations are provided, so the description carries the full behavioral burden and does not meet it. It says "list" but never states whether disabled/unconfigured subagents are excluded, what ordering applies, or whether the call is side-effect free — all of which an agent must know before relying on the result.

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 front-loaded sentence with no filler, which is the right shape for a no-argument listing tool. It is efficient rather than padded, though it is arguably too thin for a tool with no annotations.

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 structure needn't be explained and there are no parameters to document. Still, with zero annotation coverage the description should say more about what "configured" means and what the list is scoped to, so it is only minimum viable.

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 nothing for the description to disambiguate; the baseline of 4 applies. The description introduces no spurious parameter expectations either.

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 ("List") and resource ("configured subagents"), which is more than the bare noun in the tool name. It does not, however, distinguish this from siblings like sessions or status, so an agent must infer scope from the name alone.

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?

No guidance on when to call this versus reading status, sessions, or set_config. There are no exclusions or prerequisites, leaving the agent to guess whether this is the canonical way to discover available subagent names.

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