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

No annotations are provided, so the description carries the burden of disclosing behavior. It states the key side effect (removing from unread messages) and mentions that a result is returned indicating success. It does not cover idempotency or error cases, but the disclosed behavior is sufficiently clear for a simple mutation tool.

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 well-structured with a clear opening purpose, Args, Returns, and an Example. It is concise, front-loaded, and every section adds value. The example is illustrative 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?

Given the tool's simplicity, the description is complete: it explains purpose, when to use, parameter semantics, return type, and provides an example. The presence of an output schema means the return details need not be fully explained. It covers everything necessary for an agent to select and 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 0% description coverage, but the description compensates by providing an Args section with meaningful explanations: 'The ID of the message to acknowledge' and 'Your current task ID.' It also includes a usage example, giving the parameters practical context beyond their names and types.

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 'Mark a message as read/acknowledged,' which clearly states a specific action on a resource. It further explains the effect ('remove it from your unread messages') and distinguishes the tool from sibling tools like list_messages, send_message, and broadcast_message, which have different purposes.

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 says 'Use this after you've processed a message to remove it from your unread messages,' giving clear context for when the tool should be invoked. However, it does not mention when not to use it or explicitly name alternatives, though the sibling tools are implicitly different.

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 provided, so the description carries the disclosure burden. It explains that the message goes to all other active sessions and returns a result indicating success and delivery targets. It also describes the priority parameter. However, it does not cover potential edge cases like failure behavior or rate limits, which keeps it from a 5.

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 well-organized with clear sections for intro, usage, arguments, return value, and an example. It is front-loaded with the core purpose and adds no filler or redundant 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?

Given the tool's moderate complexity, the description provides sufficient context: when to use it, what it does, parameter details, and a concrete usage example. The return format is described and the presence of an output schema further completes the picture.

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 provides only type/title information with 0% description coverage, so the description fully compensates. It explains the meaning of each parameter: content, source_task_id, and priority, including the allowed priority values ('normal', 'high', 'urgent'). The example also demonstrates the parameter values in context.

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 'Broadcast a message to all other active Claude Code sessions' — a specific verb ('broadcast'), resource ('message'), and scope ('all other active sessions'). It distinguishes from the sibling tool 'send_message', which likely targets a specific 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 says 'Use this to notify all other sessions about important events, like when a PR is merged to main', providing a clear usage context. It does not directly mention when not to use it or alternatives, but the broadcast vs. direct messaging distinction is implied by the wording.

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 provided, so the description carries the full burden of behavioral disclosure. It explains the return type and the unread_only flag, implicitly indicating a read operation, but does not explicitly state whether listing messages has side effects (e.g., marking them as read) or any other behavioral nuances.

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 well-structured with distinct sections for summary, usage, arguments, return value, and an example. It is concise without unnecessary repetition, and every section serves a clear purpose.

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 gives all necessary context: purpose, usage, parameter meanings, return format, and a concrete example. With an output schema available, the description doesn't need to detail return structure further, so the coverage is fully adequate.

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%, but the description compensates fully by documenting each parameter in the Args section. current_task_id is explained as 'Your current task ID' and unread_only as 'Only show messages not yet acknowledged,' adding meaningful semantics beyond the schema's bare type definitions.

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 explicitly states 'List messages received by this session' with a specific verb and resource. It clearly differentiates from siblings like send_message and acknowledge_message, making the tool's unique purpose unambiguous.

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 sentence 'Use this to see what other sessions have communicated to you' provides direct guidance on when to use the tool. While it doesn't explicitly mention alternatives or exclusions, the use case is clear and logically distinct from sibling tools.

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 provided, the description carries the burden. It discloses the return format via an example, mentions that it lists only active sessions, and indicates a list with total_count. It does not explicitly state that the operation is read-only, but the tool's name and 'list' semantics imply it. The example gives useful transparency into the result structure.

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 appropriately sized: a single clear summary line, a short usage note, and a structured example. Every sentence earns its place without fluff. The front-loaded main purpose makes it easy to scan.

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 zero-parameter list tool with an output schema, the description is complete. It explains what is listed, why to use it, and what the return looks like. There is no missing critical information for an agent to invoke and interpret the result.

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 fully covers this aspect. The description does not need to add parameter details, and the baseline of 4 applies. The description's focus on the return value 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 clearly states the tool lists all registered active iTerm2 sessions, using the specific verb 'list' with a well-defined resource. It also explains the purpose ('discover which other Claude Code sessions you can communicate with'), which distinguishes it from sibling tools like register_session or send_message.

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 provides a clear context for when to use the tool ('Use this to discover which other Claude Code sessions you can communicate with'), implying it is the initial discovery step before communication. However, it does not explicitly mention alternatives or when not to use it, though the zero-parameter nature makes this less critical.

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 carries the full burden. It discloses the core behavior (registration, enabling communication, return result) but omits potential side effects such as overwrite behavior, idempotency, or failure modes. This is moderately transparent but not deeply detailed.

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 well-organized with purpose, args, returns, and an example. Every sentence adds value without redundancy. It is front-loaded with the main purpose and then provides structured details, making it 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?

For a single-parameter tool, the description covers the essential aspects: what it does, why it is used, the parameter specification, and an example result. An output schema exists, so return-value explanation is not strictly needed but is included. Minor gaps remain regarding edge cases, but overall it is complete.

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 0%, but the description fully compensates by specifying task_id's purpose, allowed characters, maximum length, and giving concrete examples. This is exactly the information an agent needs beyond the bare schema type.

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 ('Register') and clearly identifies the resource ('current iTerm2 session'). It distinguishes from sibling tools like list_sessions and send_message by explaining that registration enables other sessions to find and communicate with this 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 states that it registers the current session, implying it is a prerequisite for inter-session communication. It does not explicitly mention when not to use it or name alternatives, but the context is clear. It also provides format constraints for task_id, which aids correct usage.

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 carries the full burden. It states that the message will be injected into the target session and that a result is returned, which is useful. However, it omits potential side effects, failure modes (e.g., if the target session doesn't exist), or any delivery guarantees. This is adequate but not rich.

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 well-structured with a clear purpose sentence, a brief usage note, an Args section, a Returns note, and an example. Every section earns its place without excess verbosity. The front-loaded purpose sentence gives immediate clarity.

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 has four parameters and an output schema, and the description covers all parameters and the return type. It includes a realistic example. While it does not address edge cases like invalid session IDs or priority handling, the given information is sufficient for an agent to select and invoke the tool correctly in most scenarios.

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%, but the description compensates by documenting all four parameters: target_task_id, content, source_task_id, and priority. It adds meaning beyond the schema by providing an example task ID, explaining source_task_id as the sender, and specifying allowed priority values ('normal', 'high', 'urgent'). The example call also illustrates correct parameter order.

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: 'Send a message to a specific Claude Code session.' This clearly distinguishes it from siblings like broadcast_message by emphasizing targeted delivery. The additional context about communicating with another Claude instance reinforces the tool's unique role.

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 provides clear usage context: 'Use this to communicate with another Claude instance working on a related task.' It implies the targeted nature versus broadcast, and the sibling list includes broadcast_message, signaling alternatives. However, it does not explicitly state when not to use this tool or mention alternative tools by name, so it narrowly misses a 5.

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