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

Annotations already declare non-read-only, non-idempotent, non-destructive behavior, so the bar is lower. The description still adds meaningful traits beyond them: model and permission-mode inheritance (overridable via modelSelection), the fact nothing is copied, and no worktree is created, which counters a plausible agent assumption for a 'thread' 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?

Four short sentences, each carrying distinct information: what is created, what it inherits, what it returns/follows up, and what it deliberately omits. Front-loaded with the creation semantics and no 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?

With no output schema, the description correctly discloses the return value (the thread ID) and covers inheritance, empty-history, and no-worktree behavior. It is nearly complete for a 3-param mutation tool; the only real gap is the unexplained commandId parameter.

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% across 3 params including a nested modelSelection object, so the description must carry the load. It does explain the effect of modelSelection (overriding inherited model/permission mode), but says nothing about title beyond the required flag or commandId at all, leaving two parameters unexplained.

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 ('Create an empty persistent peer thread'), scopes it ('in this project, at its workspace root'), and explicitly distinguishes it from adjacent operations ('Does not copy history or create a worktree'). An agent can place it among list_threads/read_thread/send_message_to_thread without inspecting the 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?

Names the downstream step explicitly ('use send_message_to_thread to start work'), which tells the agent this tool only allocates a thread and a follow-up call is needed. It stops short of stating when NOT to create a thread or what prerequisites/context the project must be in.

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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so safety is covered. The description adds genuinely new context: the word 'Request' signals the interrupt may be asynchronous rather than guaranteed, and 'History remains available for a follow-up' tells the agent the thread survives. It could say more about partial turn output, but this is solid added value.

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, zero waste, with the action and scope front-loaded ahead of the survival note.

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 destructive mutation with no output schema, the safety profile is covered by annotations and the history-persistence behavior is covered by the description. Gaps remain around commandId, error behavior when the thread is idle, and what happens to the interrupted turn's partial output.

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% on two parameters. The description explains nothing about either: threadId is only obliquely inferable from 'peer thread's', and commandId is completely unexplained (likely an idempotency/correlation key, but the agent must guess). With zero schema coverage the description should have compensated and 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?

States a specific verb+resource+scope: 'interrupt a peer thread's current turn in this project'. An agent can distinguish it from siblings like set_thread_settled or send_message_to_thread. It does not name those siblings explicitly, 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?

No when-to-use guidance and no alternatives named. The phrase 'current turn' implies the interrupt applies only to in-flight work, but nothing tells the agent when to prefer this over send_message_to_thread or set_thread_settled.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: sort order by ID, archived exclusion, settled inclusion, and cursor-based pagination. The only flaw is the cursor parameter being misnamed (nextBeforeThreadId).

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 tight sentences, front-loaded with the resource and scope before the pagination detail. Minimal waste, though the settled/archived clauses slightly overlap in conveying filter behavior.

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 read-only list tool with full annotation coverage and no output schema, this is adequate, but the 0% schema coverage leaves 'limit' undocumented and the cursor parameter is named inconsistently, so an agent lacks the precise syntax needed to page 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 description coverage is 0%, so the description must carry the parameters, and it only partially does. It explains the cursor's role but calls it 'nextBeforeThreadId' while the actual parameter is 'beforeThreadId', which could mislead an agent, and it says nothing about the limit parameter.

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 clear verb ('List') and resource ('persistent peer threads in this project'), plus scope qualifiers (settled included, archived excluded). It is distinguishable from read_thread (single) and create_thread at a glance, though it doesn't explicitly name a 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?

There is no explicit when-to-use guidance or routing to alternatives such as read_thread or wait_threads. The inclusion/exclusion notes describe scope, not usage conditions, so an agent must still infer when this tool is the right choice.

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 readOnly=true, idempotent=true, non-destructive, closed-world. The description adds valuable behavioral detail beyond that: tool output and attachments are omitted, and message text is capped at 8000 characters. These are non-obvious constraints that affect how an agent interprets results.

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 short sentences, front-loaded with the purpose, then constraints, then pagination instruction. No wasted words.

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 three parameters, one required, no output schema, and no annotations about return shape, the description covers the essential behavioral constraints and pagination pattern. It could mention what 'state' includes or whether turnLimit controls the page size, but it is largely complete for the tool's complexity.

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%, so the description must compensate; it does so by explaining the purpose of beforeCursor for pagination. However, it doesn't describe threadId or the turnLimit parameter (1-100), leaving those semantics implicit. Baseline with no schema descriptions would be low, so the partial compensation earns a 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?

States a specific verb (read) and resource (a peer thread's state plus a page of conversation messages), scoped to 'this project'. It is clearly distinguishable from siblings like create_thread, list_threads, and send_message_to_thread.

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 explains pagination usage ('Use the returned page.beforeCursor for older turns'), which gives a clear operational context. It doesn't describe when to prefer this over alternative reading tools, but the sibling set doesn't include an obvious competing read tool.

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 annotations declaring readOnlyHint=false and idempotentHint=false, the description adds meaningful behavioral detail beyond them: the message is visible to the recipient, the sender's thread ID is embedded so the recipient can reply, modelSelection alters the model, and a validation rule exists ('T3 can reject changing the provider of an already-bound thread'). Only the non-idempotent/retry implications are left unstated.

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

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

Three compact sentences, front-loaded with the core action and its state effects, then parameters, then the rejection rule. No filler, though the phrasing is dense enough that a sentence on commandId would have been a better use of space than some of the modelSelection detail.

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 5-parameter mutating tool with a nested object and no output schema, the description covers the main action and one failure mode, but leaves commandId unexplained and says nothing about what happens to a queued vs. started thread or how errors surface. Adequate but with clear gaps.

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 20%, so the description must compensate; it does explain modelSelection's effect and one provider constraint, but threadId, message, and commandId receive no semantic elaboration at all. Partial compensation only.

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 ('Send a visible follow-up to a peer thread in this project') and clarifies the effect on thread state (starting, queuing, reviving settled threads). It is clearly distinguishable from create_thread or read_thread, though it never names a sibling explicitly.

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 implies usage context by describing the scenarios that motivate a send (starting/queuing work, reviving settled threads), but it gives no explicit when-to-use vs. when-not guidance and no alternatives among the sibling tools (e.g., create_thread vs. send_message_to_thread).

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description goes beyond these by disclosing the precise rejection preconditions for settling, which is valuable operational context. It stops short of what 'settled' actually changes or how reactivation behaves, leaving some behavioral gaps.

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, each earning its place: what it does, the rejection conditions, and the alternative. The core action is front-loaded with zero 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 mutation tool with annotations covering the safety profile, the description supplies the preconditions and the fallback sibling, which is the main missing piece. Remaining gaps are the semantics of `commandId` and any return/state-change detail, which are secondary here.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It implies the `settled` boolean via 'settle or reactivate' and `threadId` via 'peer thread', but `commandId` is completely undocumented in either the schema or the description. Partial compensation only.

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 set (settle/reactivate) and resource (peer thread in this project), which is clear and distinguishable from siblings like create_thread or read_thread. It does not explicitly contrast with other thread-mutation siblings, but the pairing of both directions through the `settled` flag is well conveyed.

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 states the blocking conditions for settling (work running/queued, or pending blocking approvals) and names the alternative (interrupt_thread) with the condition that selects it. This is exactly the when/when-not/alternative guidance an agent needs.

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 readOnly/idempotent/non-destructive/non-open-world, and the description adds real behavioral detail beyond them: timeout returns current state, commentary does not wake the tool, and wait is capped at 60 seconds. These are exactly the traits an agent needs to avoid misuse.

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 compact sentences, front-loaded with the core action and followed by the operational hints. Little wasted text, though the phrasing is slightly terse and telegraphic.

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 should describe return values; it only covers the timeout return ('returns current state on timeout') and leaves the normal wake return shape unspecified. Adequate but incomplete for a blocking-wait 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 description coverage is 0%, so the description must carry parameter meaning. It clarifies the cursor semantics ('each last returned cursor to avoid repeated notifications') and implies per-target thread ids, but never explains threadId itself or that targets is an array of up to 8 entries.

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 (wait) and resource (peer threads) plus the wake conditions (finish or need attention). It is clearly distinct from read_thread/list_threads, though it never explicitly names a sibling alternative.

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 implied usage via the cursor hint ('pass each last returned cursor to avoid repeated notifications'), which tells the agent how to call it repeatedly. It does not say when to prefer this over list_threads or read_thread, leaving the selection to inference.

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