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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the notion of inspecting 'mechanical metadata and capabilities' but does not disclose additional behavioral traits such as what fields are returned or how the snapshot observe parameter affects the operation. 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?

The description is a single, front-loaded sentence with no filler. It states the action and resource immediately, and every word contributes to understanding what the tool does.

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 simple two-parameter schema and strong annotations, the description is largely sufficient for an agent to understand the tool's purpose. The only notable gap is the lack of guidance on how this relates to siblings such as read_channel, but the description plus schema covers the core invocation context 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?

Schema description coverage is 100%, so the schema already documents both parameters. The channel_id description adds useful provenance ('returned by list_channels'), and observe gains meaning through 'bounded snapshot observation cursor.' However, the main tool description does not add parameter detail beyond the schema, matching the baseline for high schema coverage.

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

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

The description uses the specific verb 'Inspect' and clearly identifies the resource: 'mechanical metadata and capabilities for one terminal channel.' It differentiates from siblings by indicating this is a per-channel inspection tool, distinguishing it from list_channels and read_channel. The phrasing implies metadata/capabilities rather than content, which helps an agent select it correctly.

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 explicit guidance is given about when to use this tool versus alternatives like read_channel, list_channels, or wait_channel_event. The description implies a per-channel inspection use case but does not state exclusions or conditions, so the agent is left to infer the right 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scope context ('independently of Channel inventory or application state') but does not describe response format or potential error behavior, though for a zero-parameter health check this is a minor 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?

A single, front-loaded sentence that states exactly what the tool does and what it does not depend on. Every word contributes value; there is 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?

This is a simple zero-parameter health-check tool with read-only, idempotent, non-destructive annotations. The description is sufficient for an agent to select and invoke it correctly; no additional context is required.

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?

There are zero parameters, so the input schema fully documents all inputs. The description adds no parameter-level detail, which is unnecessary here. Baseline 4 applies due to the absence of 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 uses a specific verb ('Report') and resource ('mechanical backend/service health'), and explicitly distinguishes it from 'Channel inventory or application state'. This clearly separates it from the channel-focused sibling tools like list_channels and get_channel.

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

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

It clearly indicates this tool is for backend/service health checks and not for channel inventory or application state concerns, which implies when it should be used. It doesn't name alternative tools explicitly or state when-not-to-use scenarios, but the context 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral detail: the result is scoped to what is visible in the configured backend scope. However, it does not mention potential pagination, ordering, or how channels are defined, though the bar is lower given 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?

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the main action plus scope are stated immediately.

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 zero-parameter, read-only listing tool with strong annotations, this description is nearly complete. The only minor gap is that 'configured backend scope' is somewhat vague, and there is no explicit statement of the output shape, though 'List' strongly implies a collection result. Overall, an agent can safely invoke this tool without missing critical information.

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 the schema is an empty object, so schema description coverage is 100%. There are no parameters whose semantics need explanation; the baseline of 4 applies because the tool takes no inputs and the description's scope qualifier is sufficient.

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') and resource ('existing terminal channels') with an explicit scope qualifier ('visible in the configured backend scope'). It clearly conveys a plural listing operation, which distinguishes it from the singular sibling tools get_channel and read_channel, and from the write-oriented write_text and send_control.

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 guidance about when to use this tool versus alternatives. With siblings like get_channel and read_channel available, an agent is not told whether list_channels is the right choice for enumeration versus targeted retrieval, nor are any exclusions or conditions 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?

Annotations already mark this as read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds useful behavioral detail beyond the annotations by noting that output is bounded, recent, and not gated on semantic completion. This gives the agent a clearer picture of the read semantics.

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

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

A single, focused sentence that front-loads the action and resource while adding the most important behavioral qualifier. There is no filler or repetition of schema details.

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 and annotations cover the safety profile, but there is no output schema and the optional bounded-output parameters are not explained. The description gives enough to select the tool but not quite enough to invoke it optimally without further inference.

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

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

Schema description coverage is only 33% because only channel_id is documented. The description says output is 'bounded' but does not explain how the bytes and lines parameters control that bound or when to prefer one over the other. With low schema coverage, the description should compensate but does not.

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 ('read'), a specific resource ('recent terminal output from one channel'), and key constraints ('bounded', 'without waiting for semantic completion'). This distinguishes it from siblings like list_channels and get_channel, so an agent can understand what this tool does at a glance.

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 'without waiting for semantic completion' provides clear context for when to use this tool: when recent bounded output is needed immediately rather than waiting for a complete result. It does not explicitly name alternatives or exclusions, 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?

The annotations already declare destructiveHint=true and idempotentHint=false, so the agent knows this is a non-idempotent, potentially destructive action. The description adds the useful scoping that the control must be 'explicit reviewed,' but it does not explain side effects of ENTER, INTERRUPT, or ESCAPE, or what happens after the control is sent.

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 focused sentence of about ten words with no filler. It places the core action and object first, and every word contributes either to scope ('one explicit reviewed') or to target ('existing channel').

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 only two parameters and an output schema absent, the description plus schema is sufficient to understand the basic call shape. However, it does not describe the expected return value, failure modes, or behavioral consequences of each control, which an agent would need for confident invocation in a terminal-control 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 schema documents channel_id as coming from list_channels, and control has a clear enum. The description adds the semantic framing 'terminal control' and the 'reviewed' constraint, but it does not clarify what each enum value does or the practical difference between INTERRUPT and ESCAPE, leaving part of the burden on the agent.

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 ('Send'), a concrete resource ('terminal control'), and a target ('existing channel'). It is clearly distinct from the sibling write_text, which sends textual content rather than control signals, though it does not explicitly name 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?

The phrase 'to an existing channel' implies a precondition and suggests this tool is for control actions rather than text or read operations. However, there is no explicit guidance about when to choose send_control over write_text or read_channel, and no mention that channels should be obtained via list_channels first.

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 list, so the agent knows it is a safe read operation. The description adds the key behavioral trait of waiting for observed activity followed by quiet, but it does not elaborate on edge cases (e.g., what happens if no activity occurs, how 'quiet' is determined, or if there are side effects). With no output schema and limited details, the description leaves important behavioral nuances unstated.

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 with no wasted words, and it front-loads the core purpose and key condition ('never infers completion'). It is exceptionally concise while conveying the primary logic.

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 4 parameters, 0% schema coverage, and no output schema, the description is insufficient. It does not explain the meaning of each parameter, the behavior in failure or timeout cases, or what the return value represents. An agent would need to guess how to set idle_ms and timeout_ms or interpret the outcome, making the tool under-specified for reliable 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%, so the description must compensate for the 4 parameters. It mentions none of the parameter names (channel_id, after_cursor, idle_ms, timeout_ms) or their purpose beyond the general 'wait' concept. An agent cannot infer what each parameter controls (e.g., idle_ms for quiet period, timeout_ms for max wait) solely from the description, making it inadequate for parameter understanding.

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 ('wait for') and a resource ('Channel snapshot activity') with a clear qualifier ('never infers completion'). It distinguishes from siblings like get_channel or read_channel, which are likely immediate reads, by implying a time-based waiting behavior. However, it does not explicitly name a sibling it is not, so it loses a point for not explicitly differentiating.

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 in scenarios where the agent needs to observe activity in a channel and wait for a quiet period, contrasting with direct reads from siblings. However, it does not explicitly state when to prefer this over alternatives or when not to use it, leaving the agent to infer the context from the vague phrase 'never infers completion'.

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 establish destructiveHint=true and non-idempotency, so the safety profile is covered. The description adds valuable context beyond annotations: the text is bounded, LF/TAB are the only allowed control characters, and the target must be an existing channel. This helps the agent predict behavior and constraints without contradicting any annotation.

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, two-clause sentence front-loads the core purpose and constraint, then immediately resolves the main ambiguity with send_control. Every word earns its place; 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?

For a three-parameter write tool with a destructive annotation, the description supplies the essential selection and invocation context: what can be sent, where it goes, and when to use the sibling tool. It doesn't explain return values or error behavior, but no output schema exists and the schema's parameter descriptions cover the required details.

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

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

Schema coverage is 100%, and the schema already documents each parameter thoroughly (1 MiB limit, control-character exclusion, submit semantics, channel_id provenance). The description reinforces some of this ('bounded', 'LF/TAB allowed') but adds no new parameter-level meaning beyond what the schema provides, so a baseline 3 is appropriate.

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

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

The description names a specific verb ('Deliver'), a precise resource ('one existing channel'), and key constraints ('bounded ordinary Unicode terminal text'). It also explicitly distinguishes itself from the sibling send_control by reserving control sequences for that tool, so an agent can immediately tell them apart.

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 provides an explicit usage boundary: ordinary text with LF/TAB is for this tool, while explicit controls should go to send_control. It also notes the channel must already exist, which implies first using list_channels. It does not exhaustively state when not to use it versus read-oriented siblings, but the distinction is clear.

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