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 the state gate, that digits select-and-submit in option dialogs, that option lists treat letters as hotkeys, and that Escape cancels the question and ends the turn with no answer. It omits what happens on an invalid status call and any permission requirements, keeping it at 4 rather than 5.

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 and precondition are front-loaded in the first sentence, followed by a compact, well-delimited enumeration of the accepted answer forms. Every sentence carries information; nothing is 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?

An output schema exists, so return values need not be described, and the description covers the state gate and the main side effects (submit vs. cancel). Given it is a stateful mutation tool with zero annotation coverage, it is close to complete, with only error/invalid-status behavior 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 0%, so the description must compensate, and it does for `answer`: key names, single-digit option selection semantics, free-text-with-Enter, and the text-field-focus caveat are all spelled out. `terminal_id` is left entirely unexplained, though its meaning is largely self-evident from context.

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 the question a terminal is blocked on') and immediately narrows scope with the precondition 'Only valid while its status is waiting_user_answer'. It does not explicitly distinguish itself from the nearby sibling send_session_message, which is the most likely confusion point, 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 state precondition (only valid while waiting_user_answer) tells the agent exactly when to reach for this tool, and it documents the Escape path as an explicit 'no answer' exit. It stops short of naming alternatives (e.g. what to use when the terminal is not blocked), so no explicit when-not routing.

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. It does disclose meaningful delivery behavior — the message is queued and each terminal receives it when next idle, with semantics 'exactly as send_session_message does' — but says nothing about permissions, failure handling, or whether queued messages can be retracted. Adequate but incomplete for a mutation 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 scoping rule is front-loaded in the first sentence, and the tool is short overall. The second paragraph's illustrative examples ('a change of plan', 'commit what you have and report') are somewhat conversational but do earn their place by pinning down typical payloads.

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 addressing default is covered. However, for a no-annotation mutation tool with a 0% schema coverage, the description should say more about targeting precedence and side effects; it stops at delivery timing.

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 all three parameters, so the description must compensate. It does explain the default behavior when no target is named ('the whole fleet'), but never clarifies the relationship between terminal_ids and session_names, whether both may be supplied, or what message content accepts. Partial compensation only.

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 ('Queue one message for many terminals at once') plus the scope default ('the whole fleet when none is named'), and explicitly contrasts with 'send_session_message', which handles the single-target case. The only blur is the terminal/session distinction, which the description never sorts out despite both being addressable parameters.

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 concrete when-to-use context ('a change of plan, "commit what you have and report", a constraint you forgot') and implies the alternative is the single-target sibling. No explicit when-not-to-use or exclusion criteria are stated, so it falls short of 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?

With no annotations, the description carries the full burden, and it does disclose the payload shape (status, progress, stuck, model, profile, working directory, worktree, pending_messages) plus the semantic meaning of needs_attention and totals. It does not state read-only/side-effect behavior or data freshness, which are the remaining gaps for a no-annotation 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?

Front-loaded with the value proposition and the sibling comparison, then the returned fields, then the actionable field. Every sentence earns its place; 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?

An output schema exists so return values need not be enumerated, yet the description's summary of key fields and the routing guidance make the tool fully callable as-is. Zero params and no annotations leave no unaddressed 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly spends no space on argument syntax.

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 ('The whole fleet in one call: every session, every terminal') and immediately scopes it against the sibling pattern it replaces. An agent can distinguish it from list_sessions and get_session_info 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?

Explicitly says 'Prefer this over list_sessions plus a get_session_info per session' and gives the reason (one call, one block of context). This is a direct when-to-use rule with a named alternative, not implied guidance.

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. It does disclose the payload ('full system prompt and settings'), implying a read-only lookup, but says nothing about permissions, behavior for unknown profile names, or sensitivity of the returned prompt data.

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?

One tightly written sentence that front-loads the verb and resource. Nothing extraneous.

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 restated. However, for a lookup tool the description omits how to obtain a valid profile_name and what happens on an unknown profile, leaving a modest 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 0% and the description never mentions the single required parameter. It gives no guidance on naming format, case sensitivity, or where valid profile names come from (e.g., list_profiles).

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?

Specific verb ('Return') and resource ('a profile's full system prompt and settings') make the purpose obvious. It distinguishes itself implicitly from list_profiles by promising a single profile's full contents rather than a listing, though it never names that sibling.

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 when-to-use guidance and no alternatives referenced. It never says to call list_profiles first to discover valid names, nor when this is preferable to other profile-related tools.

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 disclosure burden. It adds real value by stating the ordering convention ('oldest terminal first') and that statuses are live, which the schema does not convey. It still omits any read-only confirmation, error behavior, or permission requirements, so it is only partially transparent.

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?

It is a single short clause with no filler and the content is front-loaded, which is efficient. But it reads as an under-specified fragment rather than a complete statement, so brevity comes at some cost to clarity.

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 spelled out, and the description adds the ordering detail. For a simple one-parameter read tool it is nearly adequate, but the total absence of parameter and usage context leaves gaps.

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

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

Schema description coverage is 0% for the single session_name parameter, and the description never mentions it. No format, naming convention, or expected value shape is given, so the description fails to compensate for the schema gap.

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

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

The description names the resource (a session plus every terminal in it) and its content (live statuses), which is informative. However, it is a verbless noun phrase, so the actual action (retrieve) is only inferred, and it does not distinguish itself from siblings like get_terminal_status or list_sessions. Purpose is conveyed but not sharply 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_sessions or get_terminal_status. The agent gets no signal about which sibling to prefer in a given situation.

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. It usefully discloses that ``last`` returns Claude's final answer while ``full`` returns the rendered scrollback, which is real behavioral content. It omits read-only confirmation, any permission/auth notes, and whether output is paginated or bounded.

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, front-loaded with the core purpose and immediately followed by the mode semantics. 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?

An output schema exists, so return values need not be explained, and the mode semantics are covered. What is missing is sibling differentiation (read_session_output) and any hint about terminal_id provenance, which matters given the crowded terminal/session tool family.

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 must compensate. It explains the ``mode`` values (last vs full), which is valuable, but says nothing about ``terminal_id`` (e.g. how to obtain it) and does not enumerate mode as a formal enum in 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?

The description states a specific verb+resource ("Read a terminal's output") and clarifies the two modes. However, it does not differentiate from the very close sibling read_session_output, leaving the agent to guess which terminal-output reader to use.

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 guidance on when to use this tool versus alternatives such as read_session_output or get_terminal_status. The mode semantics are explained, but no usage context or exclusions are provided.

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 usefully enumerates the five terminal states and 'Live' implies the value is current at call time, but it says nothing about permissions, failure modes for an invalid terminal_id, or rate limits.

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 key scope constraint ('one terminal') first and the state enumeration after. 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?

The tool is simple (one required param) and an output schema exists, so return values need not be explained – though the state list partly duplicates it. What is missing is how to source terminal_id and any usage context, leaving the definition minimally 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?

Schema description coverage is 0% – terminal_id has no description at all. The description only says 'one terminal' and never explains the id's format or where to obtain it (e.g., from list_sessions or launch_session), so it fails to compensate for the schema 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+scope ('Live status of one terminal') and enumerates the possible states, which lets an agent distinguish it from get_terminal_output (output text) and fleet_status (aggregate). It does not explicitly name any sibling, 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?

There is no when-to-use guidance, no mention of alternatives such as get_terminal_output or fleet_status, and no prerequisites. 'Live' hints at a polling/monitoring context but the agent must infer when this tool is the right choice.

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 it well: it defines the metric direction ('percentages are utilisation, so 100 means spent'), the meaning of resets_at, and the failure mode ('Unavailable... comes back as ok: false rather than a made-up number'). That last disclosure is exactly the kind of non-obvious behaviour an agent needs to avoid misreading a degraded result as real data.

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 answer in the first clause, then rationale, then edge-case semantics. Slightly verbose in the middle sentence and split across hard line breaks, but every sentence carries distinct 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?

An output schema exists, so return values need not be spelled out, yet the description still supplies the interpretation layer (units, direction, resets_at, error signalling). The only real gap is the format/timezone of resets_at, which an agent must read from the output schema to act on.

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 for a 0-parameter tool is 4. No parameter-related content is missing.

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 resource and scope: 'How much of the Claude subscription is left: the 5-hour and weekly windows.' That is a concrete verb+resource (read remaining subscription quota across two named windows) and is unambiguously distinct from every sibling, which deal with profiles, sessions, terminals, and worktrees.

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 concrete usage conditions: 'Worth a look before opening a large fleet, and when deciding whether to run the stronger model everywhere.' Two real decision points, but it names no alternative tool and states no when-not-to-use case, so it stops short of explicit routing.

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 the state guard, the refusal on idle, the ~2 s observation delay, the expected resulting statuses, and that queued messages are subsequently delivered. It omits permission/auth requirements and error behavior for an invalid terminal_id.

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?

Four short sentences, front-loaded with the action, then precondition, then post-condition. Every clause (state guard, refusal, ~2 s delay, queued-message follow-up) 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?

An output schema exists so return values need not be explained, yet the description still covers timing and post-conditions, and with no annotations it supplies the needed behavioral context (refusal conditions, side effects). Missing only auth/permission notes and invalid-id 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?

One required parameter at 0% schema description coverage; the description only implies that terminal_id identifies the terminal whose turn is interrupted. The parameter is largely self-evident, so no real syntax or format detail is added 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 ('Stop a terminal's current turn') plus the escape-key equivalent, and scopes it to the turn rather than the session, which cleanly separates it from sibling tools like shutdown_session or restart_terminal.

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 concrete trigger ('when a worker is going in circles') and an explicit precondition/exclusion ('only while its status is processing or waiting_user_answer; an idle prompt ... is refused'). No sibling alternative is named for comparison, so it falls just short of the top band.

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 it well: discloses the ~90 s blocking wait and why (failures surface immediately), the worktree branch scheme mx/<terminal_id> from repo HEAD, the merge/cleanup semantics on terminal deletion, and that provider only supports claude_code. This is substantially more than the schema provides.

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 core action is front-loaded in the first line, with parameter detail following in scannable sentences. The worktree paragraph is long but each sentence carries behavioral information (branch naming, merge instructions, deletion semantics), so it mostly earns its 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?

Output schema exists, so return values needn't be described, and the description still explains the result's 'worktree' field. Behavior around blocking, cleanup, and branch retention is covered; agent_profile and session_name semantics remain undefined for a required parameter.

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 must compensate, and it does for most parameters (working_directory Linux path format, model values opus/sonnet, initial_message delivery timing, provider compatibility, use_worktree effect). Only session_name and agent_profile are left implicit, which is a minor gap given a 7-param tool at 0% 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?

Opens with a specific verb and resource plus concrete elaboration ('one full Claude Code process in its own tmux window'), so the agent knows exactly what is created. It does not name or contrast with the sibling launch_sessions (batch variant), which is the one obvious ambiguity left.

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 real selection guidance: use_worktree for parallel workers on one repo, provider accepted for compatibility only. It lacks explicit when-not/alternative routing (e.g., 'use launch_sessions for multiple') but context is clear enough for correct invocation.

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 at all, the description carries the full burden and does so well: it discloses that each launch blocks until its Claude is ready, that failures are isolated per entry while the rest still start, and that max_parallel (1-8) throttles concurrency. It omits permission/auth requirements and any rate-limit or side-effect profile, which keeps it from a 5.

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 purpose, then parameters, then a justification sentence. The third paragraph's cost comparison is decision-relevant rather than filler, though it is somewhat repetitive of the opening 'one call' framing.

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. Given a batch tool with an undocumented nested array, the description supplies the field list, concurrency cap, and failure semantics an agent needs to call it correctly, though it could say more about what a partial-failure result looks like.

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 must compensate, and it does: it enumerates the per-entry fields (agent_profile, session_name, working_directory, model, initial_message, use_worktree) that the opaque sessions array schema does not document, and gives the 1-8 range for max_parallel. It does not explain the type/format of individual fields or the max array length, but coverage is substantially better than the schema alone.

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 ('Launch several sessions at once, in parallel') and immediately frames the scope distinction from the sibling launch_session ('One call for a whole fleet'). An agent can tell this is the batch variant 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?

Provides a clear rationale for choosing this tool over repeated launch_session calls ('Ten sessions launched one by one cost ten calls ... this is one call'). It lacks an explicit when-not-to-use (e.g. single session, or when per-session control matters), so it stops short of 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 behavioral burden. 'List' strongly implies a non-mutating read, and the enumerated return fields describe the payload, but it never states read-only safety, pagination behavior, or whether the profile set is static or session-dependent. Adequate but not rich for a zero-annotation 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?

A single front-loaded sentence with no filler. The verb and resource come first, with the launch context and returned fields following in a tight parenthetical.

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 needn't explain return values, and it still names the key fields. For a zero-argument listing tool under a session-launch workflow, the definition is essentially complete; only the absence of any stated relationship to get_profile_details leaves a small 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?

The tool takes zero parameters (100% schema coverage of nothing), so there is nothing for the description to disambiguate and the baseline is 4. The parenthetical field list describes the output rather than inputs, so it adds no parameter meaning but no gap 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?

States a specific verb (List) and resource (agent profiles) with additional scope detail: the profiles a session can be launched with, plus the fields returned. It implicitly distinguishes from the singular get_profile_details via plurality and the launch-oriented framing, but never names that sibling to make the contrast 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?

The phrase 'a session can be launched with' implies this is the discovery step before launch_session, which is useful implied guidance. However, there is no explicit when-to-use statement or routing against get_profile_details, so the agent must infer the choice from the tool names alone.

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 discloses that only running sessions are returned and that terminal counts are included, but it does not cover permissions, pagination, or other behavioral traits beyond the basic scope.

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 concise sentence with zero waste. The most important qualifier, "running," is front-loaded and immediately visible.

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 do not need to be fully explained. However, with no annotations and no sibling differentiation, the description lacks enough context to fully guide selection among related session and status tools.

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 has zero parameters, so parameter semantics are inherently simple. The description does not need to compensate for missing parameter documentation, and the baseline for 0 params 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 ("list_sessions") plus a clear scope ("running sessions") and a key returned attribute ("terminal counts"). It does not explicitly distinguish itself from siblings like fleet_status or get_session_info, but the purpose is still clear.

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

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

Provides no guidance on when to use this tool versus alternatives such as fleet_status, get_session_info, or list_profiles. Usage is only implied by the tool name and short description.

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

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

With no annotations, the description carries the full behavioral burden and mostly does: it discloses that orphaned checkouts are never removed on their own, and that deleting a terminal commits leftovers on the branch, removes the checkout, and keeps the branch when it has commits the repo's HEAD lacks. Those are non-obvious side effects an agent would otherwise get wrong. It never explicitly states this call is read-only/non-mutating, which is the remaining gap.

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 scope statement, then the entry fields, then the merge/removal lifecycle. Each sentence carries information; the only mild inefficiency is that the fragment style makes the first line read as a header rather than a sentence.

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 re-explained, yet the description still summarizes the entry keys. Combined with the merge instructions and the orphaned-entry caveat pointing at remove_worktree, an agent has everything needed to list, interpret, and act on the result correctly.

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 the baseline is 4. The description adds nothing parameter-related (there is nothing to add), and instead spends its budget on the entry shape and lifecycle, which is the right trade.

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

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

The description opens by scoping the resource precisely: 'Every live terminal that runs in its own git worktree,' which is a specific verb (list) plus resource (worktrees) with a defined subset. It also names the sibling remove_worktree in the context of orphaned checkouts, so the agent can separate this from that tool. The phrasing is slightly indirect ('what there is to merge' rather than 'lists worktrees'), which keeps it just 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?

It gives concrete next-step guidance: merge a finished entry with `git -C <repo> merge <branch>`, and for orphaned entries 'merge what you want, then `remove_worktree`.' That is an explicit alternative tool plus the condition that selects it. It does not state when this tool should be used instead of list_sessions or get_terminal_status, but the operational routing is strong.

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 does disclose one trait — that max_chars truncates to the tail rather than the head — but says nothing about the 'mode' parameter's behavior, whether reads are non-destructive, whether output is consumed, or whether the call blocks.

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 primary addressing modes and followed by the one non-obvious parameter behavior. No waste, though the terseness leaves useful information out.

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 explained. But with no annotations and an undocumented 'mode' parameter, the description leaves meaningful gaps for a tool whose behavior is entirely unstructured.

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 0%, so the description must explain all four parameters. It covers terminal_id/session_name usage and clarifies the semantics of max_chars (tail-only), but the 'mode' parameter is never mentioned despite defaulting to 'full', leaving a major gap in a zero-coverage 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+resource ('Read output') and clarifies the two addressing modes (terminal id or session name). However, it does not differentiate itself from the sibling get_terminal_output, which a reader could easily confuse with this tool.

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 an implicit conditional for choosing between terminal_id and session_name ('when the session has one terminal'), which is useful routing guidance. It stops short of saying when to prefer this tool over get_terminal_output or get_terminal_status, leaving the main alternative unaddressed.

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 disclose non-obvious side effects: leftovers are committed first, and the branch is retained if unmerged. That is real information an agent could not derive otherwise. It stops short of stating whether the removal is irreversible, what permissions are required, or how failures are surfaced.

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?

One sentence, front-loaded with the action and target, with the qualifiers confined to a parenthetical. No filler, no repetition of the tool 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 return values need not be described. Given the tool's low complexity, the description adequately covers purpose, preconditions, and side effects; the remaining gap is the undocumented terminal_id parameter and unstated irreversibility.

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 parameter 'terminal_id' has 0% schema description coverage, so nothing in the structured fields explains it, and the description never clarifies that the worktree is addressed by a terminal id or how to obtain that id beyond the vague 'listed by list_worktrees'. The description does not compensate for the coverage 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 ('Remove') and resource ('orphaned checkout'), and pins the resource to how it is discovered ('listed by list_worktrees'), which distinguishes it from every non-worktree sibling. An agent can tell exactly what this operates on 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?

Referring to 'an orphaned checkout listed by list_worktrees' implies the intended workflow (inspect via list_worktrees, then remove the orphan), but there is no explicit when-to-use/when-not statement or mention of prerequisites such as when a worktree is safe versus unsafe to remove. 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.

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

No annotations are provided, so the description carries full behavioral burden. It usefully discloses that the conversation is lost, that the operation blocks for up to ~90s, and which attributes are preserved, though it does not discuss permissions or error modes.

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, front-loaded with the action, then usage conditions, then effects and timing. No filler; every clause adds useful operational context.

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?

Output schema exists, so return values need not be explained. The description covers the failure conditions, destructive effect, and blocking behavior well, but omits parameter guidance for terminal_id.

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% for the sole terminal_id parameter. The description refers to 'a terminal's Claude' but never explains terminal_id's format, expected value, or that it identifies the target. Low coverage requires compensation, and none is given.

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 action: replace a terminal's Claude with a fresh instance while preserving id, profile, model, directory, and inbox. The use-case guidance distinguishes it from siblings like interrupt and launch_session.

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: when status is error (Claude exited) or when unresponsive after interrupt. This names the preceding alternative and the failure condition that selects restart.

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 a genuinely useful trait: async queueing with delivery when the terminal becomes idle. However, it omits what happens if the terminal never becomes idle, whether delivery is confirmed, or any auth/permission context.

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

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

A single tight sentence with the action front-loaded and the delivery-timing detail appended. Every clause earns its place; nothing is redundant or buried.

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. For a two-param mutation tool with no annotations, the description covers the core behavior but leaves parameter meaning and edge-case behavior (busy/never-idle terminals) unaddressed.

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 both required parameters (terminal_id, message) are undocumented in the schema. The description implies a message and a target terminal but adds no format, constraint, or identifier-syntax meaning to either parameter.

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

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

The description states a specific verb (queue) and resource (a message for a terminal) and explains the delivery mechanism. It is clearly distinguishable from read-oriented siblings, though it does not explicitly differentiate itself from the related broadcast_message tool.

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 explicit guidance on when to use this versus siblings such as broadcast_message or answer_prompt, nor any stated prerequisites or exclusions. Usage is only implied by the tool name and the mention of terminals.

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 does disclose the destructiveness scope — all terminals plus the session are closed — which is genuinely useful. However, it says nothing about irreversibility, what happens to running processes, whether the session must exist/be idle, or any permission requirements.

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?

One sentence, front-loaded with the verb and scope, with no filler. It is efficiently sized for a one-parameter tool, though for a destructive operation the extreme brevity borders on under-specification rather than pure concision.

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 explained. The remaining gaps are the ones that matter most for a destructive, annotation-free tool: usage context, irreversibility/side effects, and error behavior when the session name is unknown.

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% for the single required parameter, so the description must compensate. 'Of a session' only loosely ties session_name to the target; it adds no format, naming convention, or lookup hint (e.g., whether the name comes from list_sessions).

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 ('Close') and resource ('every terminal of a session and the session itself'), making the blast radius explicit. It is distinguishable from siblings like interrupt or restart_terminal, but it never names or contrasts with them, so sibling differentiation is left to 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?

No when-to-use guidance, no exclusions, and no mention of alternatives such as interrupt (stop work but keep session) or restart_terminal (recover instead of tear down). The agent must guess whether shutdown is the right escalation versus those siblings.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses the blocking nature, the max timeout of 900s, the default state set, the require_all semantics, the whole-fleet default for terminal_ids, and the subtle rule that a terminal with a queued message counts as busy rather than finished.

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 purpose and well organized, but the Claude Code / events aside and the closing anti-polling rationale add length beyond the minimum needed. Every sentence is still informative, so only mildly verbose.

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 coordination tool with four optional parameters and an output schema (which covers return values), the description supplies everything an agent needs: semantics, defaults, limits, and the intended usage loop.

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 must compensate, and it covers all four parameters: the default and available values for states, the max on timeout_seconds, the first-vs-all behavior of require_all, and the whole-fleet default of terminal_ids.

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 states a specific blocking verb and its trigger conditions ('block until a terminal finishes, asks something or dies'), which is exactly what distinguishes it from sibling get_terminal_status. An agent can identify the tool's job 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 explicitly routes between alternatives: prefer a background watch on GET /events from Claude Code, use this for scripts or short timeouts, and avoid polling get_terminal_status in a loop because it 'costs a call and a turn every few seconds.' It even frames the intended loop (wait, act, wait again).

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