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

Annotations already disclose that the tool is read-only, idempotent, and non-destructive. The description adds limited context by naming the inspected entity, but it does not disclose behaviors like not-found handling or the form of the returned capabilities.

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

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

A single front-loaded sentence with no wasted words or repetition of schema/annotation data. It earns every word.

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 strong annotations, the description is nearly sufficient. However, without an output schema it could more clearly define what 'mechanical metadata and capabilities' includes and how this differs from read_channel.

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 is one parameter and the schema already documents it as an opaque channel identifier returned by list_channels, so schema coverage is 100%. The description adds no parameter detail, but none is needed beyond the schema.

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

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

States a clear verb ('inspect') and a specific resource ('mechanical metadata and capabilities') for a single terminal channel, which distinguishes it from list_channels. It does not explicitly contrast with read_channel, so it stops just short of full clarity.

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 on when to choose this tool over read_channel or list_channels, nor any explicit when-not-to-use conditions. The intended context must be inferred from the verb and resource.

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 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.