agentsocks

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

With no annotations, the description carries the burden and discloses important behavior: the asker receives the answer along with other answers, you should answer once, and the asker stops waiting after its timeout. It does not cover invalid/expired ask-id behavior or delivery timing, which keeps it below 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 short and front-loaded: purpose and parameter source first, then delivery behavior, then the timeout alternative. Every sentence adds useful information without repetition.

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 two-parameter tool with no annotations or output schema, the description covers what it does, when to use it, when not to use it, and the key timeout behavior. The schema handles parameter details, so the remaining context 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 description coverage is 100%, so the schema already documents ask_id and answer, including format and length. The description adds only the source of ask_id (the ask message), so the 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 states a specific verb and resource: answer a question another session sent via ask, with the ask id provided in that message. It also distinguishes this tool from send_message for the timeout case, so an agent can tell when this tool applies.

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 explicitly says to use this when another session sent a question with ask and the message names an ask id. It also gives the when-not case: after the asker's timeout, use send_message instead.

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 and does substantial work: it discloses blocking/wait semantics, the timeout cap, partial-result behavior ('says who did not answer'), and a privacy-relevant side effect ('the question and replies are sent to that model'). It does not cover permissions, rate limits, or whether the reply is delivered as a message.

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?

Front-loads the action and stays dense with facts per sentence, but the pick='best' explanation is restated from the schema and the Claude-session caveat arrives as a trailing aside, adding length without new routing value.

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?

No output schema exists, so the description must explain returns, and it does: answers returned together, non-responders identified, and the optional best-reply opinion with probabilities plus the caveat that every reply is still shown. An agent has enough to invoke and interpret results 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: that '#channel' targets a channel's subscribers and that refs come from list_peers, plus the consequence of pick='best'. The rest largely restates schema text.

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 specific verb+resource with scope: 'Send one question to several sessions at once, wait for their answers, and get them back together.' It also distinguishes itself from siblings by naming the one case it does not cover (Claude-to-Claude) and routing that case to SendMessage.

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?

Gives clear conditions for use (one question fanned out to multiple sessions, max 16, blocking with a timeout) and an explicit when-not with an alternative ('A Claude session cannot ask Claude sessions this way... use SendMessage'). It stops short of contrasting against broadcast, which an agent might otherwise consider for a similar fan-out.

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 and does well: it discloses per-session routing by state and budget, that fyi is batched until each session is idle, that normal lands at the next tool call, and the 'interrupted a lot lately' exception. It omits any delivery/error behavior, rate limits, or what happens to sessions that never go idle, keeping it short of 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?

Three tightly packed sentences, front-loaded with the core action and scope, then the delivery model, then the routing alternative. No filler and nothing repeated.

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 two-parameter fan-out tool with no output schema and no annotations, the description covers routing, urgency semantics, and alternatives well. It stops short of describing the result shape or any scale/rate constraints on broadcasting to every live session.

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 message and urgency, including the fyi/normal batching semantics. The description largely restates the urgency behavior already in the enum description and adds no new format or constraint details, so the baseline 3 applies.

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 and resource ('Send one plain-text message to every live Claude Code and Codex session except yourself') and explicitly distinguishes itself from siblings send_message and channel. The self-exclusion is a precise scope detail that separates it from a generic send.

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 states the use case ('It is for announcements, so it is never urgent') and names the alternatives with the condition that selects them: 'To reach one session or a group, use send_message or a channel instead.' When-to-use and when-not-to-use are both explicit.

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?

readOnlyHint=true already establishes this is a safe read, so the description's value-add is the disclosure of what comes back: subscriber identity, non-running channels, and which channel is the caller. It does not explain pagination, ordering, or what a 'channel' or 'not running' means, which matters since there is no output schema.

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 filler, opening on the verb. The trailing list of return fields makes it slightly run-on and reads more like a result spec than an action statement.

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-param read tool with no output schema, the description covers the main return elements but leaves key ambiguities: whether the list is exhaustive or subscriber-filtered, what 'not running' denotes, and the return structure. Adequate but not fully self-sufficient.

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?

Zero parameters, so there is no parameter semantics to convey; baseline 4 applies. The description's return-field clause is not a substitute for parameter documentation.

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?

Specific verb (List) plus resource (channels) with an explicit scope qualifier ('that have subscribers'), which separates it from siblings like list_peers and list_tasks. It never names an alternative sibling, so it stops short of a 5.

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?

There is no statement of when to use this versus list_peers, peer_status, or subscribe/unsubscribe, and no prerequisites or exclusions. The only guidance is the implicit scope 'channels that have subscribers', which the agent must infer from a return-value clause.

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?

readOnlyHint=true already establishes the safe-read profile. Beyond that the description adds a real behavioral filter (only messageable sessions, not every process on the machine) and discloses the returned fields (names, refs, working directories, status), which is valuable given there is no output schema. It omits ordering, staleness, and whether the caller's own session appears.

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?

One sentence, front-loaded with the verb and resource, then scope, then return fields. No filler and nothing buried.

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 list tool with no output schema, the description covers purpose, scope, and returned fields, and annotations cover safety. Minor gaps remain around result ordering and whether the listing can be incomplete or stale, but nothing essential to calling it is missing.

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 takes zero parameters and the schema is empty, so per the baseline a 4 applies. The description correctly says nothing about parameters, avoiding noise.

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 concrete verb (list) and resource (Claude Code / Codex sessions on this machine), plus the scoping condition 'that you can message'. This is far clearer than the bare name 'list_peers', though it never names or contrasts with the nearest sibling (list_channels, list_tasks), so it stops short of full differentiation.

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?

Usage is only implied: 'that you can message' hints these are the peers you may target with send_message/ask, but there is no explicit when-to-use, when-not, or named alternative. An agent can infer the workflow but must do the inferring itself.

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 readOnlyHint annotation already declares this is a safe read operation. The description adds useful context that the default is active tasks only and that results are scoped to the user's assignments or creations, but it does not describe pagination, maximum results, or return format.

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 short sentences with no wasted words. The scope and default filtering behavior are front-loaded and immediately actionable.

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 two-parameter read-only list tool with full schema coverage and a readOnlyHint, the description provides enough context to call it correctly. It could be slightly richer about result ordering or limits, but nothing essential is missing.

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 both parameters are fully documented in the schema. The description lightly mirrors the show parameter's ownership scope and the include_finished default behavior, but adds no syntax or edge-case details beyond the structured fields.

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: list tasks, scoped to tasks assigned to or created by the user. This distinguishes it from mutating siblings like update_task and send_task, but it does not explicitly contrast with any sibling list tools.

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 the default context (active tasks) and the two ownership scopes. It does not name alternatives or explicitly state when not to use this tool, but the usage context is well implied for a list operation.

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, so the safety profile is covered. The description adds real behavioral value by enumerating the routing outcomes (now, after the current step, batched, merged) and the delivery states (sent, shown, answered) that the tool reports — important given there is no output schema. It does not cover what happens for an unknown message_id or any error behavior.

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 the verb first and no wasted preamble. The parenthetical enumerations are dense but earn their space by defining the possible states, though the stacked list makes it slightly harder 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 one-parameter read-only status tool with no output schema, the description supplies the conceptual return values an agent needs to interpret results. Missing only error/edge-case behavior and explicit usage triggers, which are minor for this complexity level.

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?

Only one parameter and schema coverage is 100%, so the schema already documents message_id fully, including its provenance from send_message. The description adds no format, constraint, or edge-case guidance beyond that, making 3 the correct baseline.

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 specific verb ('show') and a specific resource (how a sent message was routed plus its delivery/read state), which clearly separates it from siblings like send_message, list_channels, or peer_status. It stops short of explicitly naming which sibling tool produces the message_id, relying on the schema for that linkage.

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?

Use context is implied by 'a message you sent' and the schema note that message_id comes from send_message, so an agent can infer this is a post-send verification call. However there is no explicit when-to-use statement, no mention of alternatives, and no conditions or exclusions.

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 declare readOnlyHint=true, so the safety profile is already covered. The description adds real value beyond that by disclosing the shape of the read: unread messages, held digests, open tasks, last shown/answered timestamps, and a drift comparison. It does not mention permissions, visibility scope (same workspace vs. cross-workspace), or staleness/refresh behavior, which keeps it out of the top band.

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 opens with the action and then enumerates the payload categories; there is no filler or redundancy. The parenthetical list is dense but each item carries information, so it stays readable rather than sprawling.

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 one fully documented parameter, a readOnly annotation, and no output schema, the description must describe what comes back and largely does so via the enumerated categories. What remains thin is operational context: scope/permissions for viewing another session and whether the status is live or cached.

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 a single parameter with 100% schema description coverage, so the schema already defines it as 'Session name or ref from list_peers'. The description adds no additional semantics for the peer argument (e.g., whether an unknown peer errors or returns empty). Baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb (show) plus resource (another session's current state) with a clear enumeration of what is reported: work in progress, pending items, last activity, and drift. It reads as distinct from list_peers, which enumerates sessions rather than reporting one session's state. It stops short of explicitly contrasting with the overlapping sibling message_status, which also concerns message activity.

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?

Usage is only implied: the agent infers 'call this when you need to know about another session'. There is no explicit when-to-use, no when-not-to-use, and no named alternative such as list_peers (for enumeration) or message_status (for message-level detail). The peer parameter's reference to list_peers hints at ordering but is not stated as guidance.

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 and does substantial work: it discloses that ratings stay local to the machine, that they change how the sender's messages are routed (pausing ordinary messages from noisy senders), and that they score the router. It omits any mention of what the call returns or whether ratings can be changed/undone, which is a gap for a mutation-style 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?

One long but well-ordered passage: purpose first, then rating semantics, then side effects, then the default fallback. The clause about scoring the router is mildly tangential but earns its place by explaining why ratings matter. No redundant 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?

For a 3-parameter tool with no annotations and no output schema, the description covers purpose, semantics of each enum value, privacy, and side effects. The main omission is return-value behavior, which the absence of an output schema pushes back onto the description.

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%, so the baseline is 3, but the description adds meaning the schema does not: it states that omitting both message_id and from rates the latest message received, which is the default-resolution behavior an agent needs to know. The three enum values are also restated with their interpretation.

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?

Names a specific verb (rate) and resource (a message another session sent you), then defines all three rating values inline so the agent knows exactly what each option means. It is clearly distinguishable from siblings like message_status (inspect) and send_message (produce).

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 clearly frames the context of use — judging a message you already received — and explains the downstream purpose of rating (tuning routing and scoring the router). It does not explicitly contrast with siblings such as message_status, but the usage condition is unambiguous.

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 behavioral burden. It discloses meaningful traits: plain-text-only payloads, delivery semantics per urgency tier ('reaches the receiver at its next tool call unless it was interrupted a lot lately'), and the important caveat 'It never counts as its user's approval.' It does not cover failure modes or rate limiting (a sibling rate_message exists), leaving a modest 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?

Four sentences, front-loaded with the core action and the Claude Code exclusion before the parameter guidance. Efficient overall, though the urgency explanation partially duplicates the schema's enum descriptions.

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 no annotations and no output schema, the description covers the essentials an agent needs: recipient forms, message content expectations, urgency selection, the non-approval caveat, and the scope exclusion. Missing only return/confirmation behavior and any throttling context for a 3-parameter tool.

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%, so the baseline is 3. The description nonetheless adds value beyond the schema by naming concrete recipient forms ('a session name, a ref from list_peers, or a reply-to address (uds:...)') and a usage heuristic for urgency tiers ('what changes or blocks its work right now'), which the schema states more mechanically.

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 specific verb and resource ('Send a plain-text message to a Codex session') and immediately bounds the scope ('on this machine'). It also distinguishes itself from the built-in SendMessage used for Claude Code sessions, so an agent can tell which channel to use without opening a schema.

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 names the alternative path ('For Claude Code sessions use your built-in SendMessage... this tool does not send to them') with a stated condition. It also gives concrete selection guidance for the urgency enum ('urgent is for what changes or blocks its work right now... fyi is for status or thanks that can be batched').

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 and does much of it: it discloses the notification lifecycle (accepts/progresses/finishes/fails), the default 24-hour expiry, and the delivery path for a Claude session. It omits permission/auth requirements and what happens if the assignee never responds, but the lifecycle transparency is well beyond a typical 'create task' blurb.

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?

It is front-loaded with the core action and packs substantial information into three sentences with no filler. The middle sentence is long and carries three clauses (lifecycle, expiry, Claude-session delivery), which makes it denser than ideal but not wasteful.

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 mutation-style tool with eight parameters, no annotations and no output schema, the description covers return behavior (what you are notified about), expiry defaults, and per-parameter intent well enough to call it confidently. Remaining gaps are edge cases (unaccepted tasks, permission requirements) rather than anything needed for a correct 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 coverage is already 100%, so the 3 baseline applies, but the description adds real guidance on two parameters: 'Say what done looks like in acceptance_criteria' clarifies the expected content, and 'Use risk high only for work that must not wait' gives a use policy for the enum that the schema's 'delivered as urgent' 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 pairs a specific verb+resource ('Give another agent session a task') with the defining trait that separates it from send_message/ask: the task is 'tracked' and 'you are told when it accepts, progresses, finishes or fails.' An agent can distinguish this from the fire-and-forget messaging siblings without opening any schema.

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 explains the delivery mechanics ('For a Claude session the task is created and tracked, and you are given the message to send with your built-in SendMessage') and gives one conditional rule ('Use risk high only for work that must not wait'). However, it never explicitly states when to choose send_task over ask or send_message, leaving the sibling selection to inference.

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 and delivers meaningful lifecycle semantics: a channel exists only while it has a subscriber, the subscription persists until unsubscribe, and each subscriber is routed separately. It omits behavior for repeat subscribes (idempotency), validation failures, or max channel limits.

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 tight sentences with the core action front-loaded and the send_message routing hint appended for practical use. The final sentence about per-subscriber routing is slightly tangential but earns its place by clarifying delivery semantics.

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 one-parameter tool with no annotations and no output schema, the description covers lifecycle, interaction with send_message, and termination via unsubscribe. It leaves the return value and duplicate-subscribe behavior unspecified, but nothing critical to invocation is missing.

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% and the single `channel` param is fully documented with format constraints in the schema itself. The description only repeats the "#deploys" example, adding no syntax or constraint detail beyond the schema, so the baseline 3 applies.

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?

Specific verb-plus-resource ("Join a channel such as "#deploys"") with an inline example, and it clearly frames the tool as the inverse of unsubscribe by stating the subscription "lasts until you unsubscribe." An agent can distinguish this from send_message, broadcast, or unsubscribe without opening a schema.

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 explains the mechanism for using the subscription (post with send_message by setting `to` to "#deploys") and when the relationship ends (on unsubscribe), which routes the agent to the right siblings. It stops short of explicit when-not-to-use or failure/duplicate-subscribe conditions.

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 behavioral burden. It usefully discloses idempotency ('does nothing if you were not subscribed'), but says nothing about permissions, whether the action is reversible via `subscribe`, or what the call returns.

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 short sentences, front-loaded with the action and followed by the one non-obvious behavioral caveat. No padding 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 one-parameter tool with no output schema, the definition covers the operation and its no-op condition. It leaves minor gaps around re-subscription and side effects on channel membership, but nothing essential to calling it correctly is missing.

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% and the single `channel` parameter is fully documented in the schema, including format constraints. The description adds no additional meaning about the parameter, so the baseline 3 applies.

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 gives a specific verb+resource pair — stop receiving messages posted to a channel — that an agent can distinguish from the sibling `subscribe` without opening any schema. The title 'Leave a channel' reinforces the same 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?

Usage is implied (call this when you want to stop receiving a channel's messages), but there is no explicit when-to-use framing, no naming of the counterpart `subscribe`, and no guidance on prerequisites such as whether you must have joined first. Adequate but with clear gaps.

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 and does well: it discloses the permission model (creator-only cancellation) and a side effect (the creator is notified of every change). It omits transition validation rules and error/idempotency behavior, which is why it is not 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?

Three dense sentences, front-loaded with the core action, then the enum/role rules, then the notification side effect. No sentence is 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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers purpose, permissions, expected payload content, and side effects. Only failure/transition behavior is left unspecified.

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 all four parameters, including the status enum and its role split. The description's guidance on what belongs in result and evidence largely restates the schema, so the baseline of 3 applies.

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 specific verb and resource ('Report progress on a task'), which is far more concrete than the bare name update_task. It does not, however, explicitly distinguish itself from plausible siblings such as send_task or answer, so an agent must infer the boundary.

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?

Gives clear role-based conditions: the assignee sets accepted/in_progress/done/failed, and only the creator may set cancelled. This tells the agent who can do what, but it names no alternative tool or when-not-to-use condition.

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