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 several behavioral traits beyond the schema: it queues ATTENTION_CLOSE_V1, parks the FO session row, defaults to safe close (idle tab / SKIP-LIVE if CLI still running), and clarifies that kill_live is 'argv-anchored terminate, not fuzzy.' It also includes write-tier approval notes. The only minor gap is not stating the exact return/response format, but for a mutation tool with this level of behavior disclosure, it's quite complete.

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

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

The description is dense but well-organized: a one-sentence core purpose, example triggers, then behavioral details, a sibling pointer, and an approval note. No fluff; every sentence adds operational value. The bracketed approval note is a useful addition without being 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 tool with 6 params, required session_id, no output schema, and no annotations, the description covers: what it does, when to use it, when not to use it (prefer sibling), behavioral nuances (safe vs. kill_live, argv-anchored, modal-free), and approval implications. It also references the correct source for session_id. This is complete for an agent to select and invoke 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 schema has 100% description coverage for all 6 parameters, each with a clear description. The description adds further semantics by defining the default behavior of 'park' (true by default), explaining what kill_live=true means ('terminate the session's own live CLI then close'), and clarifying that host has a default inference. It also explains the source of session_id ('from list_attention_sessions (tool-only)'), which adds context 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?

The description opens with a specific verb+resource: 'Close an EXISTING coding tab on the operator machine for THIS operator.' It clearly states the action and scope. It also distinguishes from sibling tools by explicitly mentioning 'Prefer park_attention_sessions when only the board is ghosty' and by using terms like 'kill_live' versus 'safe close' that are unique to this close operation.

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 explicit when-to-use guidance with example phrasings ('close that session', 'kill that Grok tab') and contrasts with the sibling alternative park_attention_sessions ('when only the board is ghosty and the Terminal tab is already gone'). Also gives conditional usage for kill_live=true ('only when they say force-kill / stop it now'), which is clear exclusionary guidance.

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