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

With no annotations, the description carries the behavioral burden. It discloses the key side effect: subsequent get_voice_input calls return '__END_SESSION__'. It doesn't mention idempotency or error conditions, but for a zero-parameter tool this is sufficient 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?

Two sentences, front-loaded with the main action, then the effect and trigger. No wasted words, 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 zero-parameter, no-output-schema tool, the description covers purpose, usage, and behavioral consequence. An agent has everything needed to decide when to call and what to expect.

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 baseline is 4. The description correctly adds no parameter info, and none is needed.

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: 'Cleanly end the current voice session.' It uses a specific verb (end) and resource (voice session), and the mention of the sentinel return on get_voice_input distinguishes it from siblings like take_over_voice_session or reset_voice_session.

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 explicit usage guidance: 'Use this when the user invokes /endlivechat or otherwise asks to stop voice mode.' This clearly tells the agent when to invoke this tool versus the alternatives.

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 fully carries the behavioral disclosure burden. It reveals long-poll timeout behavior, queue joining with ' / ', sentinel values, the session lock with PID, and the exact follow-up action for each sentinel. This is exceptionally 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?

The description is longer than most, but every sentence earns its place: purpose, loop context, queue joining, and each sentinel case. It is well-structured, front-loaded with the core purpose, and groups related behavioral details logically.

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?

There is no output schema, but the description documents every possible return value and the appropriate agent reaction, including edge cases like concurrent process lock and takeover. It also names the relevant sibling tool. No meaningful gaps remain for an agent to call it 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 tool has zero parameters)Skip, so the schema is trivially complete (100% coverage). The description adds no parameter details, but none are needed; the baseline for a zero-parameter tool is 4.

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 and resource: 'Returns the next voice utterance from the user as text.' It clearly frames the tool as a polling operation used in a loop during voice review sessionsasha. The sentinel behaviors and the mention of take_over_voice_session distinguish it from 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 description explicitly explains when to call the tool (in a loop during voice review) and how to react to each possible return value: retry on __NO_INPUT__, stop on __END_SESSION__, and ask the user then call take_over_voice_session on __ALREADY_RUNNING__. This is clear, actionable usage guidance with no ambiguity.

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 full burden. It discloses that it clears stale state, is a no-op on a healthy session, and explicitly guarantees 'no in-flight utterances are dropped'. These behavioral details are specific and 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?

Three sentences, each earning its place: purpose and state, exact placement in the session flow, and safety guarantee. No redundancy, front-loaded with the primary action.

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 utility tool with no output schema, the description covers purpose, timing, safety, and idempotency. It provides all necessary context for an agent to decide when and how to call it, and it clearly differentiates from sibling tools.

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, so the schema is empty and description coverage is trivially 100%. The baseline for zero-parameter tools is 4; the description appropriately says nothing about parameters since none exist.

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 ('Clear'), a resource ('stale shutdown state'), and the purpose ('so a new voice session can start cleanly'). It clearly differentiates from siblings by placing the call before get_voice_input, making its role 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?

Explicitly instructs when to call: 'at the very beginning of a /livechat session, after the announcement and before the first get_voice_input'. It also notes it is safe mid-session and is a no-op if the session is healthy, giving clear usage conditions without ambiguity.

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 present, the description carries the full behavioral disclosure burden. It fully discloses the mechanism: the tool signals the current holder to release, waits briefly, starts a new session, and returns 'OK' or an error string. This gives the agent enough detail to anticipate side effects and outcomes.

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 tight sentences with no filler. The first sentence names the action and target, the second explains the process, and the third adds the safety condition and expected return value. Every sentence 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 zero-parameter tool with no output schema, the description is complete: it explains what happens, when to call it, and what the response will be. Nothing essential is missing for an agent to invoke this tool 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 input schema has zero parameters, so the baseline is 4. The description correctly adds no parameter details because none exist, and it still clarifies the operational scope and return behavior.

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 ('take') and resource ('cross-process session lock from another livechat MCP instance'), making the action unmistakable. It also differentiates this tool from siblings like get_voice_input or end_voice_session by focusing on the takeover of a lock rather than reading or ending a session.

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 the tool is appropriate: 'Only call this after the user explicitly confirms taking over from the other window.' This is a clear, actionable condition that prevents premature or accidental invocation, and it implies the alternative context (continue using the current instance) without needing to name a sibling.

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