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

Annotations already indicate destructive=true and idempotent=true, and the description adds valuable behavioral detail beyond those hints: it explicitly states that pending work is canceled, the process group is terminated, the screen is released, and that unknown or already-closed IDs return closed:false. This tells the agent exactly what will be destroyed and how idempotency manifests, which is strong disclosure.

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 with zero filler. The first sentence front-loads the primary action and its immediate consequences, and the second sentence precisely documents the return value and the failure/idempotent case. Every clause earns its place.

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

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

For a one-parameter tool with rich annotations already covering destructiveness and idempotency, the description is complete. It specifies the return shape ({sessionId, closed}), the behavior for invalid IDs, and the side effects on the terminal's process and screen. No output schema exists, so documenting the return contract here is essential and is handled well.

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 only provides sessionId as a string with minLength 1? sub>1, and schema description coverage is 0%. The description compensates by discussing the behavior of 'an unknown or already-closed ID', which clarifies the semantic meaning of sessionId as the terminal identifier and describes an edge case. It does not elaborate on format requirements, but for a single self-descriptive parameter this is adequate.

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 combination: 'Close a terminal', and it distinguishes this operation from the siblings by enumerating the concrete effects: 'cancel pending work, terminate its process group, and release its screen.' This clearly identifies what the tool does and why it is distinct from terminal_list, terminal_start, and the other siblings.

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 intended usage is clearly implied: use this tool when you need to shut down a terminal and clean up its associated process state. The description does not explicitly name alternatives or say 'when not to use', but the action word 'Close' plus the detailed effects provide enough context to select it over siblings. It lacks an explicit exclusion statement, so it falls just 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?

Annotations mark the tool as destructive and non-idempotent, but the description adds substantial behavioral detail: paste normalization, modifier support, mouse reporting requirements, no-op focus, per-action mode checks, and the fact that settling errors do not undo input. This is exactly the kind of context an agent needs before sending input.

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

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

The description is dense but perfectly structured: core contract first, then per-action semantics, an illustrative example, and failure/retry guidance. No sentence is filler, and the most important information is front-loaded.

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 complex input tool with no output schema, the description names the return fields, explains failure modes, gives a runnable example, and warns that a settling error does not undo input. Nothing essential for correct invocation appears to be missing.

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

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

Since schema description coverage is 0%, the description carries the full burden, and it delivers: it explains what each action type does, the meaning of modifiers, why mouse actions need coordinates, what wait options exist, and the raw byte behavior. The example also clarifies the expected action array shape.

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 ('Send') and clear resource ('ordered batch of actions'), and names exactly what is returned: styled screen, actionsCompleted, and inputSent. The per-action detail makes it unmistakably distinct from sibling tools like terminal_snapshot or terminal_resize.

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 operational context for each action type, including when mouse actions fail, when focus is a no-op, and how modes are checked per action. It stops short of explicitly naming alternatives such as terminal_snapshot for read-only inspection, so it lacks a formal when-to-use versus alternative statement.

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

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

Annotations already declare readOnlyHint=true, and the description consistently describes a read-only listing operation. It adds meaningful behavioral context beyond the annotations by noting that exited sessions still count toward the eight-session limit until closed, which is important for capacity planning and not inferable from the annotations alone.

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 sentence that front-loads the core action and output fields, then attaches a relevant capacity-limit note. Every clause earns its place with no 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?

Since there is no output schema, the description shoulders the burden of describing return values and does so by listing all key fields (IDs, commands, working directories, dimensions, and process status). It also covers the important boundary condition about exited sessions and the eight-session limit, making the tool fully usable without external 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 takes zero parameters, so the input schema carries no parameter documentation burden. The description appropriately focuses on what is listed rather than on inputs; with no params, a baseline of 4 is appropriate and the description does not need to add parameter meaning.

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 ('List') with a specific resource ('retained terminal sessions') and enumerates the exact data returned (IDs, commands, working directories, dimensions, process status). This clearly distinguishes it from the sibling tools, which start, snapshot, input, resize, or close 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 makes the tool's purpose obvious and implies use when an agent needs to inspect existing terminal sessions, but it does not explicitly state when to prefer this over alternatives or what conditions might exclude its use. There are no exclusions or alternative routing, so usage guidance is only implied rather than explicit.

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

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

Annotations already provide readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds useful behavioral context: the child receives its terminal-size notification, and a timeout retains the applied dimensions rather than rolling back. It does not contradict the annotations.

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

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

Two sentences, with the primary verb and object front-loaded and no filler. Every sentence adds behavioral or side-effect 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?

The core behavior and side effects are covered well, and no output schema exists, so return-value description is unnecessary. However, with five parameters and no parameter documentation, the description leaves the optional timing semantics underspecified for correct invocation.

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

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

Schema description coverage is 0% and the description does not explain the five parameters. cols, rows, and sessionId are inferable from names, but settleMs and settleTimeoutMs are ambiguous and never addressed, so the description does not compensate for the missing schema documentation.

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

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

The description names a concrete action ('Resize the child terminal and emulated screen') and the observable outcome ('observe the result'), which clearly separates it from sibling tools like terminal_input and terminal_snapshot.

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 statement about when to use terminal_resize versus terminal_start, terminal_input, or terminal_snapshot. The phrase 'then observe the result' implies a follow-up observation, but it does not name alternatives or give decision criteria.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful behavioral detail: 'settleMs:0 captures without a quiet wait' and 'An exited process keeps its final screen until the session is closed.' These reveal timing and lifecycle behavior an agent could not infer from annotations alone.

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 sentences with no filler: the main purpose is front-loaded, then scrollback scope, then the two behavioral exceptions. Every sentence adds information needed to call the tool correctly.

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 content (screen, styles, cursor, process status), optional scrollback, quiet-wait behavior, and exit-state behavior. Since there is no output schema, exact return formatting is left unspecified, but an agent has enough context to invoke the snapshot correctly and interpret its purpose.

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 does explain scrollbackLines ('up to 2,000 normal-buffer scrollback lines') and settleMs ('0 captures without a quiet wait'), but settleTimeoutMs is never mentioned and sessionId is only inferable from its name and required status. This is partial but not complete compensation for the absent 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 opens with a specific verb and resource: 'Observe the current terminal screen, styles, cursor, and process status without sending input.' This clearly distinguishes the tool from siblings like terminal_input (sends input) and terminal_list (lists sessions), and it names the core read-only operation precisely.

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 by emphasizing 'without sending input' and by explaining optional scrollback and settle behavior, but it never explicitly names alternatives, excludes them, or states conditions such as 'use this instead of terminal_input when you need to inspect state.' Usage context is present but left to inference.

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

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

The description goes far beyond the annotations (readOnlyHint=false, destructiveHint=true) by detailing shell invocation specifics (shell -l -c), non-interactive shell behavior, env variable semantics (null deletes), TERM fixed to xterm-256color, and the observation timeout retaining the session. It also clarifies that 'strict observation timeout' preserves the session for inspection, adding operational nuance. No contradictions with annotations.

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

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

The description is dense yet concise, with every sentence adding unique value. It is front-loaded with the primary action and example, followed by defaults and behavioral nuances. There is no redundancy or fluff; the structure is logical and easy to parse.

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 (9 parameters, nested env, no output schema), the description is thorough. It explains the core behavior, defaults, env handling, TERM, and timeout behavior. However, it does not describe the response format in detail beyond 'styled screen and sessionId', leaving some ambiguity about the exact structure of the returned data. Also, it does not mention error handling or exit codes. These gaps are minor given the absence of an output schema, but a fuller description would improve completeness.

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?

With 0% schema coverage, the description carries the full burden. It explains shell, cwd, login, env, and TERM behavior, and the example clarifies command, cols, rows. However, it does not directly describe settleMs and settleTimeoutMs, though 'strict observation timeout' hints at them. It also omits explicit explanation of cols/rows beyond the example. Overall, it covers most parameters meaningfully.

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 pair: 'Run command through shell -l -c in a new terminal' and explicitly mentions the return value (styled screen and sessionId). It clearly distinguishes itself from siblings like terminal_list (which lists sessions) and terminal_snapshot (which captures output) by focusing on starting a new session. The example adds concrete context.

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 explains how to invoke the tool (shell defaults, cwd, login, env) but provides no guidance on when to choose this tool over its siblings. It does not mention alternatives or when not to use it. For a tool that starts a session, an agent might benefit from knowing it should be used before terminal_input or terminal_resize, but this is absent.

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