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 session refusal for busy sessions, TUI behavior for idle ones, fork as a workaround for both, the return format, and a cost-bounding recommendation. Minor gap: no mention of filesystem access or arbitrary command execution, which may be relevant for safety.

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 a one-sentence summary, then uses short, purposeful paragraphs for usage guidance, session semantics, and return output. No redundant filler; every sentence adds value.

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 tool with 13 parameters, no output schema, and no schema descriptions, this description covers the primary one-shot use case and session interactions well, but is insufficient for full autonomous use because many parameters (permission_mode, allowed_tools, model, effort, etc.) are not explained. It is adequate for basic usage but not complete.

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 session_name, fork, and max_turns, but leaves cwd, model, effort, add_dir, timeout, allowed_tools, permission_mode, disallowed_tools, and append_system_prompt entirely undocumented, leaving most of the parameter space ambiguous.

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 line 'Run a one-shot `claude -p` task and return structured JSON' gives a specific verb and resource, clearly distinguishing it from the session_* siblings. The note about being cheaper and faster than a tmux session further clarifies its unique purpose.

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

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

Explicitly states when to use it: 'Best for work that needs no conversation' with concrete examples. Also provides guidance on session_name and fork behaviors, alternatives, and edge cases like busy vs idle sessions.

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 transparency burden. It explicitly details return values (tmux_available, claude_available, session_count, sessions) and implies a non-destructive read-only health check. It does not explicitly state side effects or prerequisites, but the listed behavior is informative 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 only two sentences and gets straight to the point: 'System health check' followed by the return payload. Every word earns its place, and there is no redundancy or fluff.

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 tool's simplicity (no parameters, no output schema), the description covers what the tool does and what it returns. It is sufficient for an agent to understand the tool's purpose and output without needing additional context.

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 and 100% schema coverage (empty schema), so the description has no parameter details to add. The baseline for 0 params is 4, and the description appropriately focuses on outputs rather than parameters.

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

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

The description clearly states the tool's purpose: 'System health check' combining binary availability and session summary. It distinguishes from sibling session-specific tools by including binary path checks and a high-level overview.

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 the tool (for a system health check) and provides context that it returns both binary availability and session info. It does not explicitly mention alternatives, but the context is clear enough to infer appropriate use.

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

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

The description discloses the compaction mechanism, optional focus to bias retention, and a quality degradation threshold. However, it does not explicitly state that compaction is lossy or irreversible, nor what happens to existing messages. With no annotations, this leaves meaningful gaps.

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 brief and front-loaded with the core action. Each sentence adds value: the mechanism, the optional parameter, and the usage threshold. No wasted words.

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?

Covers the primary purpose and includes a practical threshold, but omits the `name` parameter, return value (no output schema), and side effects of compaction. For a session-management tool with no annotations or schema descriptions, this is only partially complete.

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 description explains the `focus` parameter with an example but completely omits the required `name` parameter. Given 0% schema description coverage, this is a significant deficiency because the agent has no clue what `name` refers to.

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 action (compress session context) via a specific mechanism (`/compact`) and purpose (recover headroom). This distinguishes it from sibling session-management tools that focus on lifecycle or messaging.

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 concrete threshold for when to use (above ~70% context usage) and explains why (output quality degrades). It does not explicitly name alternatives, but the threshold gives clear usage context.

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 discloses important behavior: `context_pct` may be null if parsing fails and should be treated as unknown, not zero. This is valuable beyond a generic 'get context usage' statement.

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 concise sentences, front-loaded with the command and output. The null-handling note is essential and earns its place. No wasted words.

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 simple tool with one parameter and no output schema, the description covers the return format and the null case. However, the meaning of the 'name' parameter is not explained, which is a notable 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 input schema has one required parameter 'name' with no description, and schema description coverage is 0%. The description does not explain what 'name' refers to (presumably a session name), leaving the agent without needed semantic information.

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 the tool's function: running `/context` and reporting context usage as a percentage. This is a specific verb+resource pair that distinguishes it from sibling session management 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?

No guidance is provided on when to use this tool versus alternatives like session_status or health. There is no mention of prerequisites, exclusions, or preference over other 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?

No annotations are present, so the description carries the behavioral disclosure burden. It clearly states the destructive action (kill) and side effect (remove metadata), plus relevant context about tmux session longevity. However, it omits details like reversibility or confirmation 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?

The description is two sentences, front-loaded with the primary action. The second sentence adds critical usage differentiation without any fluff, making it perfectly concise.

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 single-parameter destructive tool with no output schema, this is largely complete: it covers the action, when to use, when not to use, and an alternative. Its only gap is not addressing expected return values or permanent termination confirmation, but the core context is well covered.

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 schema defines a single required string parameter 'name' with no description coverage. The tool description implies that 'name' refers to the tmux session, but it never explicitly states this mapping or provides formatting details, leaving some ambiguity for a 0% schema coverage case.

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 an active verb ('Kill') with a specific resource ('tmux session') and a secondary action ('remove its stored metadata'). It explicitly contrasts with session_interrupt, making the unique purpose 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?

The description explicitly states when to use the tool ('when a task is finished') and when not to ('Do not use it to stop a slow run'), naming the alternative tool (session_interrupt). This is exemplary usage 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 provided, the description carries the full burden and does excellently. It discloses the internal mechanism: sends Escape, verifies the session leaves busy state, falls back to Ctrl-C, and suggests subsequent redirection. This is rich behavioral context beyond what structured fields would provide.

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 concise, front-loaded sentences. Every sentence adds value: purpose, method, and follow-up. No fluff.

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 simple one-parameter tool with no output schema or annotations, the description covers the main behavior, fallback logic, and next steps. However, the missing parameter semantics reduce completeness, so it earns a 4 rather than a 5.

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

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

Schema description coverage is 0% and the only parameter 'name' lacks any explanation. The description never states that 'name' is the session identifier. It mentions 'session_send' but does not clarify the required parameter, leaving a significant gap for correct invocation.

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 and resource: 'Stop the current turn without killing the session.' This clearly differentiates from session_stop, which likely ends the session, by explicitly contrasting with 'not killing the session.' The verb 'stop' and the scope 'current turn' give precise purpose.

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

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

The description gives practical usage context: it interrupts the current turn, verifies the session leaves the busy state, and falls back to Ctrl-C if needed. It also advises a follow-up action ('Follow up with session_send to redirect'). However, it does not explicitly state when not to use it or compare to alternative siblings, but the intent is clear enough.

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 must carry the transparency burden. It discloses that the tool returns both managed session metadata and live tmux sessions, which is meaningful behavioral context. The verb 'List' implies a read-only operation, but the description does not explicitly state safety, side effects, or error behavior. For a zero-parameter list tool, this is adequate.

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 containing exactly the necessary information. It has no filler or redundancy, earning a perfect score for conciseness.

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 tool's low complexity (no parameters, no output schema), the description adequately covers what the tool does. It states the contents of the list (metadata and live tmux sessions), though it does not detail the output format. This is sufficient for an agent to invoke the tool correctly in most contexts.

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 no parameters (0 params, 0 required), so there is nothing for the description to clarify. A baseline score of 4 is appropriate, as the description correctly adds no parameter-specific noise.

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 the specific verb 'List' and clearly names the resource: 'managed sessions (metadata)' plus 'live tmux sessions'. This distinguishes it from sibling tools like session_status or session_context, which operate on individual sessions rather than enumerate all sessions.

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 usage (enumerate all sessions) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The phrase 'plus any live tmux sessions' hints at scope, but there is no direct guidance like 'for status of a specific session, use session_status instead.'

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. It explains the trigger condition and valid input format for `choice`, but does not disclose error behavior, side effects, or what happens if called outside the allowed state. The exclusion of launch dialogs is useful context, but more is needed for full transparency.

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 succinct and well-structured: purpose, input format, and exclusion are each covered in distinct, focused sentences. No redundant or extraneous 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?

For a simple two-parameter tool, the description covers the core usage and preconditions. However, with no output schema, it fails to mention return values or post-response behavior, and the `name` parameter is undefined. These gaps make it adequate but not complete.

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 description thoroughly explains the `choice` parameter (option number or navigation key), but leaves the required `name` parameter completely unexplained. Since schema description coverage is 0%, the description must compensate for all parameters, and the omission of `name` is a significant 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 first sentence clearly states the tool's function: answering an on-screen prompt, with a specific condition (`state` is `awaiting_input`). This distinguishes it from sibling tools like `session_send` or `session_wait`.

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 clear when-to-use guidance (`state` is `awaiting_input`), a when-not exclusion (launch dialogs are handled automatically), and a prerequisite (read the question via `session_status`). It does not explicitly name an alternative tool for sending input, so not 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 provided, the description fully carries the burden and does so admirably. It discloses non-blocking behavior, automatic session creation, queuing of input while Claude is working, the meaning of the `steered` field, and the return structure. This gives the agent a solid mental model beyond the tool's basic function.

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 well-structured: a clear lead sentence, followed by a short creation note, retrieval pointers, and a concise behavioral caveat. It uses emphasis and formatting effectively without wasting words.

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 description covers core usage, non-blocking semantics, session creation, and return value shape, making it complete for typical use cases. However, it omits details about optional parameters (beyond a generic 'launch options' grouping), so advanced or configuration-heavy invocations may require external knowledge.

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 only clarifies `working_dir` ('Set *working_dir* on the first send') and vaguely groups other inputs as 'launch options.' The remaining 10 parameters (e.g., `effort`, `add_dir`, `permission_mode`) are left unexplained, which is a significant gap for a tool with 12 parameters.

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

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

The description opens with a specific verb and resource: 'Send *prompt* to a session and return immediately (non-blocking).' It clearly distinguishes itself from sibling tools by noting that no `session_start` is needed and by pointing to `session_wait` and `session_tail` for result collection.

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 states when to use this tool (to send a prompt without blocking) and provides explicit alternatives: 'Call `session_wait` to collect the answer, or `session_tail` to watch progress.' It also explains the mid-flight steering use case and notes that launch options only apply when the session is created, offering clear decision 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?

No annotations are provided, so the description carries the full burden. It does explain the binding action and the adoption context, but it doesn't disclose whether the operation overwrites an existing binding, validates the session ID, or what happens on conflict. For a mutation-like operation, this leaves some ambiguity.

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 crisp sentences deliver the purpose, usage condition, and exclusion. Every word earns its place, with no redundancy or fluff.

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 simple tool with two string parameters and no output schema, the description covers the core functionality and required conditions. It misses potential details like error behavior or whether the ID must already exist, but given the simplicity, the description is reasonably complete.

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% and the description provides the only semantic clue. It does indicate that `name` is the target name and `claude_session_id` is the existing ID to bind, which gives basic meaning. However, it doesn't mention constraints like uniqueness or format of the name/ID, so it only partially compensates for the lack of schema 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?

The description uses a specific verb 'Bind' and clearly identifies the resource ('an existing Claude conversation ID') and the target ('to *name* for future `--resume`'). It distinguishes this from sibling session tools by explaining it's only for adopting sessions not created by the server, which is a unique purpose.

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

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

Explicitly states when to use ('Only needed to adopt a session this server did not create') and when not to use ('new sessions are assigned an ID automatically'). This gives clear guidance on the preconditions and distinguishes it from the normal session creation flow.

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 full responsibility for behavioral disclosure. It thoroughly explains side effects: existing tmux sessions are returned as-is, fresh sessions are minted a UUID, claude_session_id triggers resume, default permission mode is bypassPermissions for unattended runs, worktree creates an isolated git worktree, and launch options are stored and reused. This is excellent transparency about behavior and defaults.

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 well-structured with a front-loaded purpose and bullet-pointed details. It avoids fluff, and each bullet adds distinct value. However, it is somewhat longer than necessary, and some details (like effort values) could be implied from schema defaults, though schema has no descriptions. Still, it earns a solid 4 for organization and efficiency.

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 tool's complexity (11 parameters, no annotations, no output schema), the description covers many important behavioral aspects: session behavior, UUID minting, resume, permission mode, worktree, and launch option reuse. It does not explicitly describe return values or error conditions, and it omits explanations for several parameters. However, the coverage is substantial and would likely enable an agent to use the tool correctly in most cases.

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 adds meaningful semantics for several parameters: permission_mode with enumerated values and default, worktree with path pattern, effort values, claude_session_id resume behavior, and allowed_tools as a restriction. However, it leaves 5 of 11 parameters unexplained (model, add_dir, working_dir, disallowed_tools, append_system_prompt), some of which are not self-evident. It covers the key parameters but the gaps prevent a higher score.

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 explicitly states 'Pre-create a Claude Code session' with a clear verb and resource, and immediately distinguishes from the sibling tool session_send ('creates one on demand'). This goes beyond a simple definition by explaining the specific use case of fixing launch options up front.

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 directly addresses when to use this tool: 'Usually unnecessary' for most cases, but 'useful to fix launch options up front.' It explicitly names session_send as the alternative that creates sessions on demand. This provides clear usage guidance and a when-not-to-use caveat.

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. It transparently explains the state enum, the meaning of 'pending', and conditional fields like 'question' and 'context_pct', providing useful context beyond a simple status message.

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 tight and well-structured, using code-formatted state values and brief clauses. Every sentence adds useful detail without filler or redundancy.

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 description covers key state semantics and edge cases, such as conditional fields and pending behavior. It could be slightly improved by referencing the name parameter or usage context, but for a narrow single-parameter tool it is largely complete.

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% and the description never mentions the required 'name' parameter. The phrase 'one session' implies the name identifies the session, but the description adds no explicit semantic beyond what the schema already shows.

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 ('Return') and resource ('state info for one session'), clearly distinguishing it from session_list. It also enumerates possible state values, reinforcing the tool's purpose.

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

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

The description gives no explicit guidance on when to use this tool versus siblings like session_wait or session_list. The intended use is inferable from the purpose, but no exclusions or alternatives are mentioned.

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 burden of behavioral disclosure. It clearly states that the tool kills the tmux session but preserves the conversation, and that resuming is possible later with session_start. This is good behavioral transparency, though it could be more explicit about whether the session is terminated abruptly or any side effects, but it is effective.

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 concise and front-loaded: the first sentence states the core action, and the following sentences provide usage guidance and alternatives. Every sentence earns its place with no redundancy or 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?

The description covers the tool's purpose, use case, and relationship to sibling tools. For a simple tool with one parameter and no output schema, it is adequately complete. It lacks mention of error handling or prerequisites, but these are not critical for the tool's simple function.

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 does not explicitly describe the 'name' parameter. However, the tool name and description make it clear that 'name' refers to the tmux session to stop, and the context adds meaning beyond the generic schema field. Given the single simple parameter, this is adequate but could be improved by explicitly stating the parameter's role.

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 the tool's action: 'Kill the tmux session but keep the conversation.' It distinguishes itself from sibling tools by explicitly mentioning session_destroy for forgetting entirely and session_start for resuming, making its unique purpose obvious.

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

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

The description provides explicit usage context: use this to free a session's transcript so claude_run can address it without contention, and use session_destroy to forget it entirely. It also names session_start for resuming, giving clear when-to-use and alternative 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 transparency burden. It discloses the key non-blocking behavior, the read-only nature implied by 'peek', and the return shape {name, state, output}. It does not detail error handling or edge cases, but for a simple read operation it is adequately 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?

Two sentences, only 26 words, and the primary purpose is front-loaded. Every word earns its place with no fluff or redundancy.

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 simple read tool with no output schema, the description covers the essential context: when to use, the non-blocking nature, and the return structure. It does not elaborate on parameter details or edge cases, but given the simplicity and sibling context, it is sufficiently complete.

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 for parameter explanations. It implicitly references the 'lines' parameter via '*lines*' but does not explicitly explain its meaning or the 'name' parameter beyond hinting it identifies a pane. The schema already provides types and defaults, but additional explicit parameter context would be better.

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 the tool's function with a specific verb ('peek'), a specific resource ('pane output'), and a precise scope ('last *lines*'). It also explicitly contrasts with blocking operations, making it distinct from sibling tools like session_wait.

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

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

The description provides clear usage context: 'use this to check on a long-running task instead of assuming it is stuck.' It does not name alternative tools explicitly, but the advice to avoid blocking implies a clear scenario and distinguishes it from blocking wait/status operations.

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 fully carries the load. It discloses blocking behavior, resumability, timeout semantics, auto_compact behavior, return fields, and even edge cases like baseline lost and question field. This is exemplary transparency.

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 well-structured with a clear opening purpose, bolded 'Resumable' for key behavior, and concise paragraphs for parameters and return values. Every sentence adds value, and the formatting enhances scannability without unnecessary fluff.

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?

Despite no output schema, the description explains all return fields and edge cases. It covers the tool's complexity (timeout, resumability, auto-compact) and is complete for a blocking wait operation. Given the sibling context, it is fully sufficient.

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 schema has 0% description coverage, so the description must compensate. It explains 'timeout' with max 3600 and its timeout behavior, and 'auto_compact_at' with an example and effect. 'name' is not explicitly described, but its purpose is clear from context (session name). Overall, the description adds meaningful semantics beyond the raw 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 clearly states 'Block until the session finishes its pending work, then return the answer' and explicitly calls it 'the completion trigger,' which distinguishes it from sibling tools like session_send or session_tail. The verb 'block' and resource 'session' are specific and unambiguous.

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 clearly indicates this tool is the completion trigger—implying use after dispatching work—and provides guidance on resumability ('just call it again') and timeout behavior. However, it does not explicitly name alternatives or list scenarios where another tool should be used, so it lacks full exclusionary guidance.

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