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

Annotations already indicate readOnlyHint=false (a write operation) and destructiveHint=false (not destructive), but the description adds no detail about side effects, irreversibility, or what 'cancel' actually does to the session. Since annotations are minimal, the description should disclose more behavioral context.

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

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

The description is a single, front-loaded sentence with no fluff. It is economical, but the extreme brevity contributes to under-specification elsewhere. Still, for what it contains, it is well-structured.

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 cancellation tool with no output schema and sparse annotations, the description is too thin. It leaves an agent guessing about consequences, required parameter formats, and how this relates to other session-management tools. The context is not complete enough for safe 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 description coverage is 0%, so the description must compensate for the two parameters (provider, nativeId). It fails to explain what 'nativeId' means or what valid provider values are beyond the enum values in the schema. The phrase 'provider native session' hints at provider but adds no concrete parameter semantics.

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 identifies the action verb 'Cancel' and the resource 'work in a provider native session'. It is specific enough to distinguish from major siblings like stop_thread (which targets a thread) and session_create, though 'provider native session' is somewhat jargon-heavy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like stop_thread or resume_thread. The description does not mention exclusions, prerequisites, or scenarios where cancellation is appropriate.

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 only flag non-read-only and non-destructive. The description adds a meaningful behavioral caveat that OpenCode 'accepted' only means transport queued, not completion. It also clarifies model/agent/reasoning are separate controls, useful for side-effect expectations. No contradiction with annotations.

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

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

Three sentences, front-loaded with the core action; no fluff. The second sentence is somewhat terse but still meaningful, and the OpenCode caveat 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 mutation tool with no output schema and no annotation safety context, the description omits return behavior, error/timeout semantics, and the meaning of mode/native session prerequisites. The OpenCode caveat helps but leaves other providers' acceptance semantics uncovered.

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?

With 0% schema description coverage, the description carries the burden. It names model, agent, and reasoning and groups them as separate controls, but leaves mode (send/steer), provider, nativeId, and text semantics unexplained. This is not enough for a 7-parameter tool.

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

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

States a clear verb and resource: 'Send a message to a provider native session.' The note that model, agent, and reasoning are separate controls helps distinguish it from set_model/set_reasoning siblings. However, it doesn't explicitly separate it from send_message or conversation_send, so not 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?

The description implies its context ('provider native session') and gives provider-specific semantics for OpenCode. It does not state when to prefer agent_send over send_message/conversation_send or when not to use it, so an agent must infer routing from sibling names.

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 declared (readOnlyHint: false, destructiveHint: false), the description adds little beyond stating a creation action. It doesn't disclose any side effects, such as whether this overwrites an existing record, requires local storage, or triggers any notifications. The phrase 'local shared' is contradictory without further explanation, adding confusion rather than transparency.

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 single sentence is concise, but it lacks front-loaded key information. It uses vague wording ('coordinator record') that requires elaboration. A more effective structure would lead with the purpose and any critical constraints.

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 apparent complexity (a coordinator record suggests internal state management) and 0% schema description coverage, the description is inadequate. There is no explanation of the record's role, how it relates to threads or sessions, or what the return value is (no output schema). Sibling tools like conversation_join hint that this is part of a larger workflow, but the description doesn't clarify where it fits.

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%, and the only parameter 'title' has no description in the schema. The tool description mentions 'create a record' but says nothing about what the title represents, its format, or its meaning in the context of a conversation. The agent must guess whether the title is a human-readable label or an identifier, and whether it must be unique.

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 ('Create') and resource ('local shared conversation coordinator record'). However, the phrase 'coordinator record' is ambiguous and doesn't clarify what this record actually does, making it harder to distinguish from sibling tools like conversation_join or conversation_reconcile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like conversation_join or conversation_reconcile. The description doesn't mention any prerequisites, such as whether a conversation must already exist or if this is only for local setup. The user must infer usage from the name alone.

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=false and destructiveHint=false, so the description carries a lighter burden. However, it adds little beyond the verb 'attach'—no mention of side effects, permission requirements, idempotency, or what happens to an existing attached session. The term 'exact' implies precision but is not elaborated.

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 sentence with no filler or repetition. The core action is front-loaded, and every word contributes to the meaning. It is appropriately concise for a tool with a simple 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?

For a tool with 5 parameters, 3 required, enums on role and provider, and no output schema, the description is severely incomplete. It doesn't clarify the semantics of 'attach' (e.g., is it additive? does it replace? is it reversible?), what role controls, or why workspaceId is needed. An agent cannot confidently call this tool correctly without external knowledge.

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 compensate for the undocumented parameters. It only indirectly references provider and nativeId via 'native provider session' and conversationId via 'shared conversation', but role and workspaceId are entirely unexplained. This is minimal value over the schema.

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

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

The description uses a specific verb ('attach') and resource ('native provider session') to state what the tool does. The phrase 'exact native provider session' hints at the provider and nativeId parameters, and 'shared conversation' maps to conversationId. It doesn't explicitly distinguish from sibling tools like conversation_reconcile or session_resume, but the core action is clear enough.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or scenarios where another tool (e.g., conversation_create, session_resume) would be more appropriate. An agent is left to infer usage from the terse description alone.

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 establishes a safe read operation, and the description adds useful behavior beyond it: conversations are 'shared' and results are metadata-only by default, with the detail flag enabling richer output. This is meaningful context not captured in annotations.

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

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

The entire description is one tight sentence that front-loads the action, states the resource scope, and declares the parameter-dependent behavior. There is no filler or repeated schema 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?

For a simple, optional-parameter list tool with readOnlyHint and openWorldHint annotations, the description covers what the tool does, what it operates on, and how the detail parameter changes behavior. Nothing essential is missing for an agent to invoke 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?

Schema description coverage is 0%, so the description must explain the parameter, and it does: 'detail:true' changes the result from metadata-only to more detailed. While it does not enumerate every possible value, for a single boolean parameter this is sufficient semantic guidance.

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 and resource, 'List shared conversations', and immediately adds the conditional behavior 'metadata only unless detail:true'. This clearly identifies the operation and distinguishes it from siblings like conversation_read and conversation_create at the collection level.

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 implies this is the tool for listing conversations rather than reading a single one, and the 'unless detail:true' clause hints at when the detail parameter matters. However, it does not explicitly state when to prefer this over conversation_read or any other alternative, leaving usage guidance mostly implicit.

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?

Beyond the readOnlyHint annotation, it discloses important behavioral details: results are cursor-paged and passing 'next' back enables exactly-once reads. This adds real semantic value about pagination and consistency.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning: what is read, how it is paged, and how to continue reading.

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?

It is adequate for a read-only pagination tool, but it leaves a gap between the described 'next' cursor and the schema's after parameter. It also does not mention how to request the first page or what the response contains.

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 compensate, but it only refers to a 'next' cursor without mapping it to the actual after parameter. It does not explain what after, limit, or conversationId mean in practice.

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

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

The description states a specific action and resource: reading a cursor-paged transcript page. It clearly distinguishes the tool from conversation_list and conversation_send by naming the paged transcript-read behavior.

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 gives clear usage context by explaining the cursor-paging pattern and instructing the caller to pass 'next' back for exactly-once reads. It does not explicitly contrast this with sibling tools, so it falls just short of a 5.

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

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

Annotations only indicate readOnlyHint=false (mutation) and destructiveHint=false, so the description carries the burden of explaining the tool's side effects. It adds valuable behavior: it reclassifies state, closes records, never auto-resends, and relies on caller-verified receipts. This goes beyond the annotations, though it does not disclose edge-case behavior (e.g., what happens if a receipt does not match a record).

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

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

The description is a single, front-loaded sentence. It leads with the tool's primary purpose ('Recover interrupted outbound sends after a crash'), then efficiently details the action and the key safety constraint. There is no filler or repetition; every phrase 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?

The tool has two optional parameters (required: 0), no output schema, and no parameter descriptions. The description explains the general flow but leaves gaps: it does not clarify why both parameters are optional, what happens if receipts do not match records, or whether the operation is idempotent. An agent may still be unsure about how to correctly invoke it with the right combinations of arguments.

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 compensate. It does so by linking 'caller-verified provider receipts' to the observedReceipts parameter and the notion of a conversation to conversationId. This provides semantic context for both parameters, even though it does not spell out their exact meaning or constraints. The description adds value beyond the bare JSON schema.

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

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

The description opens with a specific verb and resource: 'Recover interrupted outbound sends after a crash'. It then details the action ('reclassify stuck queued/unknown records and close them') and a critical constraint ('never auto-resends'). This clearly distinguishes it from siblings like conversation_send or work_verify by focusing on post-crash reconciliation rather than normal sending or verification.

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 contextual usage: it is for interrupted sends after a crash, targeting stuck queued/unknown records, and requires caller-verified provider receipts. It implies this is a recovery path, not a normal send, but it does not explicitly name alternative tools or state when not to use it. The 'never auto-resends' clause adds an exclusion for auto-send expectations, giving the agent a clear conditional context.

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 description goes well beyond the minimal annotations by disclosing persistence-before-delivery, the receipt statuses (queued/rejected/delivery_unknown), idempotency semantics for retries, and the fact that replies require a separate send. This is exactly the kind of behavioral context an agent needs and is not present in the annotations or 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?

Three dense sentences deliver high-value behavioral guidance without wasted words. The most important operational facts (persistence, receipt statuses, idempotency, reply behavior) are front-loaded and each 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 tool with 8 parameters, no output schema, and 0% schema description coverage, this description covers the core delivery semantics and retry safety well. However, it omits context around what the other parameters control (model, reasoning, replyTo) and never explicitly states that the tool sends a message. It is adequate but leaves meaningful 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 0%, so the description carries the burden of explaining parameters. It only meaningfully explains idempotencyKey, giving its purpose and examples like workId/handoffId. The other seven parameters—including required ones like conversationId, sender, recipient, and text—receive no semantic clarification beyond their names in the schema.

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

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

The description strongly implies a send operation: "delivery," "receipt," "queued/rejected/delivery_unknown," and "Replies need another explicit send" all point to sending a message in a conversation. It is clear enough to infer the core action, but it never states the verb+resource directly (e.g., "Sends a message in a conversation") and does not differentiate itself from siblings like send_message or agent_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?

The description offers practical guidance: persist before delivery, use idempotencyKey for safe retries, and send again for replies. However, it does not explicitly say when to prefer this tool over alternatives such as send_message or agent_send, nor does it state exclusions or prerequisites. Usage context is implied rather than explicitly contrasted.

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 and openWorldHint=false, and the description is consistent with them. It adds genuine behavioral context beyond the annotations: the stream is 'shared per-session', reads are 'count- and deadline-bounded', and afterSequence enables 'exactly-once continuation'. These are meaningful guarantees an agent needs before calling.

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 tightly written sentences with zero filler. The first sentence front-loads the core purpose and scope; the second delivers the critical usage pattern (afterSequence continuation). Every clause 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?

The description captures the core protocol — bounded reads, per-session stream, exactly-once continuation — but leaves notable gaps: the meaning of 'native events', what provider and nativeId identify, the exact behavior of limit and timeoutMs, and the return format (there is no output schema). It is conceptually rich but not fully self-sufficient for a 5-parameter tool with 0% schema coverage.

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 compensate. It meaningfully explains afterSequence ('pass the last event sequence back... for exactly-once continuation') and indirectly maps limit and timeoutMs via 'count- and deadline-bounded'. However, the two required parameters, provider and nativeId, are never described at all, which is a significant gap for a tool whose schema offers no prose help.

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 and resource — 'Read bounded native events from one shared per-session stream' — and conveys clear scope and semantics. It distinguishes itself from siblings like watch_thread or get_thread_messages through the 'native events' / 'per-session stream' resource, though it never explicitly names an 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?

The description implies when to use the tool: for bounded, reliable event-stream reads with 'exactly-once continuation' via afterSequence. However, it never explicitly states when to prefer this tool over siblings such as watch_thread, get_thread_messages, or conversation_read, nor does it provide exclusions or alternative routing.

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

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

Annotations already mark readOnlyHint=true, and the description adds value by stating 'Metadata only' and 'addressable by evidence ID', which clarifies the return nature and how to access content later. No contradiction exists.

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, with the core purpose front-loaded and no extraneous words. Each sentence earns its place, providing essential information efficiently.

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 covers the tool's primary function and metadata nature, but leaves the workId parameter unexplained and omits any details about the output format. Given the tool's simplicity, it is partially complete 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?

The optional 'workId' parameter is not explained anywhere in the description. With 0% schema coverage, the agent has no indication of its purpose or effect, making it a significant gap.

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 ('List') and resource ('evidence captured by the runtime'), and clarifies the metadata-only scope. This distinguishes it from other listing tools by focusing on evidence, so an agent can easily identify its purpose.

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 metadata-only note implies that actual content requires another tool, but no explicit alternative or condition is mentioned. Usage is inferred rather than prescribed, with no guidance on when to prefer this over siblings.

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

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

The annotations already declare readOnlyHint=true, and the description's 'Detect' is consistent with that, so there is no contradiction. However, the description adds no behavioral context beyond the annotation, such as what a successful or failed detection looks like or what the returned status actually contains.

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

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

The description is a single front-loaded sentence with no filler, repetition, or unnecessary detail. For a zero-parameter capability check, this is an appropriately sized and well-structured description.

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 no-parameter, read-only status tool the description is nearly sufficient, but there is no output schema and no explanation of how the returned capabilities are represented or what 'Freebuff' and 'bridge' actually refer to. It tells an agent what the tool is for, but not enough about the result to be fully self-contained.

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?

This tool has zero parameters and the schema fully documents that, so no parameter explanation is needed. The description does not need to compensate for any schema gap.

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 ('Detect') and names a clear resource ('Freebuff and bridge capabilities'), which distinguishes it from sibling tools that operate on projects, threads, and messages. However, 'Freebuff' and 'bridge capabilities' are undefined domain terms, so the purpose is clear in outline but not fully precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to call this tool, when not to call it, or how it relates to alternatives. The only implied context is 'when you need capability status,' but that is not stated explicitly.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'Read' matches that. The description adds a vague scope qualifier ('visible', 'active') but does not clarify what 'visible' or 'active' mean operationally, nor does it disclose filtering, permissions, or output behavior beyond the annotations.

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

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

The description is very short and front-loaded, with no filler words. However, the brevity crosses into under-specification because key concepts like 'active work' and 'visible' are not explained, making the definition terse rather than sufficiently informative.

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 read-only tool with one optional parameter and no output schema, some ambiguity might be tolerable, but the description does not explain what 'active work' is, what the response contains, or how this relates to threadId. An agent lacks enough context to confidently invoke the tool or interpret its 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 schema has one parameter, threadId, with no description and 0% schema description coverage. The description does not mention threadId or explain its effect, so the parameter's meaning is left to its name and type alone. The description fails to compensate for the absent schema 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?

The description uses a specific verb ('Read') and names a resource ('visible active work'), so it is not a tautology. However, 'active work' is ambiguous and the description does not differentiate this tool from sibling read tools such as get_thread or list_threads. An agent would still have to infer what 'active work' means.

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 or alternatives are provided. The description does not explain when to choose get_active_work over sibling tools like get_thread, get_thread_messages, or list_projects. This leaves the agent to guess the tool's specific role.

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 and openWorldHint=false, covering the safety profile. The description adds the notion of 'preserving provider identity', which is a behavioral trait not fully captured by annotations, so it provides some additional value without contradicting them.

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, efficient sentence that front-loads the core action with zero waste. Every word serves a purpose, making it highly concise and well-structured.

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 two required parameters and no output schema, yet the description does not explain what 'native diff evidence' is, how to obtain valid nativeId, or what the return format might look like. It is incomplete for an agent to invoke correctly without further inference.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It gives a vague hint about provider identity but does not explain nativeId or how the two parameters relate. The description fails to document the parameters adequately.

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 a specific verb ('Read') and resource ('native diff evidence'), and adds the qualifier 'preserving provider identity' which gives scope. It does not explicitly differentiate from sibling tools like evidence_list, but the core purpose is 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, exclusions, or alternative tools, leaving the agent to infer suitability on its own.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safe, read-only nature is covered. The description adds a mild scoping detail by saying 'metadata' rather than full thread messages, but it does not disclose response shape, possible errors, or any other behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the core operation efficiently, though it is so terse that it carries little beyond the tool name itself.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a low-complexity, read-only, single-parameter tool, so the minimal description is partially adequate. However, with no output schema and no mention of what metadata is returned, the agent still lacks some context needed to 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?

Schema description coverage is 0%, and the description adds no meaning to the threadId parameter beyond what the property name/type already imply. While a single string threadId is fairly self-explanatory, the description fails to compensate for the complete lack of 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?

The description states a specific verb ('Read') and a specific resource ('thread metadata'), and it is clearly distinguishable from sibling tools: get_thread_messages would read messages, and list_threads would list threads. Even without an explicit comparison, an agent can infer the tool's narrow scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance about when to use this tool versus alternatives such as get_thread_messages or list_threads. No contexts, exclusions, or prerequisite conditions are mentioned, so the agent must rely on naming conventions alone.

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 and openWorldHint=false, so the read-only nature is expected. The description adds the qualifier 'visible', suggesting some filtering of messages, but it does not clarify what visible means or whether responses include message content, ordering, or metadata. With annotations covering the safety profile, the added behavioral context is modest.

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

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

The description is a single front-loaded sentence with no filler or redundancy. Every word contributes to identifying the operation and its object, and the core action is clear at the start.

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 tool with one parameter and no output schema, the description covers the basic operation but leaves ambiguous what 'visible' means and what the response contains (text, metadata, ordering). Since no output schema exists, the description would need additional context about the return shape to be fully 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?

The input schema has 0% description coverage and only declares threadId as a string with no explanation. The phrase 'for a thread' weakly maps the parameter to a thread identifier, but it does not specify the expected format or how to obtain valid IDs. For a single, obvious identifier parameter this is adequate, though not rich.

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 clear verb (Read) and a specific resource (visible messages for a thread), which separates it from the sibling get_thread that would target thread metadata. It could be stronger by explicitly naming the sibling it is not, but the resource identification is sufficiently clear.

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 implies the tool is used when a thread ID is available and visible messages are needed, but it provides no explicit guidance for when to choose this over get_thread or list_threads. No prerequisites, exclusions, or alternatives are mentioned, leaving the usage context implicit.

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 and openWorldHint=false, so 'read-only' and 'bounded' in the description largely restate structured data rather than adding value. The description does add 'live' and 'Desktop' context, which narrows the domain, but otherwise contributes little beyond the annotations. No contradiction exists between description and annotations.

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

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

Two short sentences with the core purpose front-loaded. The phrase 'and read-only' is redundant given the readOnlyHint annotation, which is a minor waste of words, but overall the description is tight and scannable.

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 moderate complexity (three parameters including a non-obvious pagination cursor afterSequence) and no output schema. The description does not explain the pagination mechanism, the return format, or how this tool relates to its siblings watch_thread and get_thread_progress_summary. For a tool with 0% schema coverage and no output schema, this is an incomplete definition.

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 carries the full burden of explaining parameters. It explains none of them: threadId is self-evident from the name, limit is only vaguely implied by 'bounded', and afterSequence (a pagination cursor) is completely unexplained. At 0% coverage, the description must compensate 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?

The description states a specific verb ('Read'), a resource ('live Desktop progress events for a thread'), and scope ('bounded'). It is distinguishable from siblings like watch_thread (continuous vs one-shot) and get_thread_progress_summary (events vs summary), but it does not explicitly name or differentiate those alternatives, so it falls 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 guidance is given on when to use this tool versus watch_thread (for streaming), get_thread_progress_summary (for aggregated results), or get_thread. The word 'bounded' implies a one-shot limited read, but there is no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no mention of 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?

Annotations already establish readOnlyHint=true, so safety is covered. The description adds behavioral context by clarifying that the output is a simplified summary and deliberately excludes raw event details, which is useful. It does not disclose return format, freshness guarantees, or any other runtime 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?

The description is a single, front-loaded sentence with no filler words. It states the core behavior and a key exclusion without wasting space, making it appropriately sized for the tool's simplicity.

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, one-parameter tool, the description covers the essential purpose and output character well. It could be more complete by hinting at return shape or naming sibling alternatives, but an agent has enough context to invoke it correctly with a threadId.

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

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

The schema has one required parameter, threadId, with 0% description coverage, and the tool description does not explicitly explain it. However, the parameter is unambiguous from its name and the tool's purpose, so an agent can infer its meaning without additional semantic help.

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 identifies a specific verb ('Return') and resource ('simple user-facing live progress summary'), and adds the key differentiator 'without raw event details,' which distinguishes it from sibling tools that expose raw events or detailed progress. It does not name an alternative sibling, so it stops just 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?

The description implies when to use this tool: when a user-facing, non-raw progress summary is needed. However, it gives no explicit when-not-to-use guidance or named alternatives such as get_thread_progress or events_read, so usage context is only implied.

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 indicates this is a safe read operation, and the description's 'Return' wording is consistent with that. The added mention of a durable state recovery warning provides useful behavioral context beyond the annotation, but other aspects such as output shape or failure behavior are not disclosed.

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

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

The description is a single concise sentence that directly states the resource and the notable warning included in the result. There is 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?

With no parameters, no output schema, and readOnlyHint true, the description covers the essential call semantics adequately. The extra mention of the durable state recovery warning adds useful context, though a bit more detail about what 'provider independent' means or what the graph contains could further help.

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 there is no parameter documentation burden on the description. The baseline of 4 applies because no parameter semantics are 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 states a specific verb ('Return') and a specific resource: the provider independent session and evidence graph, plus any durable state recovery warning. It is clear about what the tool does, though it does not explicitly differentiate itself from sibling tools like get_thread_progress_summary or evidence_list.

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 guidance on when to use this tool versus alternatives. The description only states what it returns, with no mention of scenarios, exclusions, or comparisons to related graph/session 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?

Annotations only say the operation is not read-only, not open-world, and not destructive. The description adds that the record is durable and keeps every field, and that the response reports packet size against the token budget and explicit omissions. It does not contradict the annotations.

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

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

Two focused sentences; the primary action is front-loaded and the second sentence adds behavioral detail without redundancy. 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?

Given the tool's complexity (10 parameters, 9 required, no output schema, no parameter descriptions), the description is too thin. It does not define what counts as an 'exact native session,' how destinationSession interacts with sourceSession, how token budget is determined, or what counts as an explicit omission.

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?

With 0% schema description coverage and 10 parameters, the description needed to explain at least the key fields, but it only mentions 'exact native sessions' and 'every field.' It lets agents infer meanings from names like workId and acceptanceCriteria, but does not add parameter-level meaning.

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 and object: 'Create a structured work handoff between exact native sessions.' This clearly identifies the tool's action and resource and makes it distinct from generic work_create, though it does not explicitly differentiate from the sibling handoff_packet.

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 when-to-use or when-not-to-use guidance, and no alternatives such as handoff_packet are mentioned. The phrase 'between exact native sessions' implies a target context, but the description never tells an agent when to choose this tool over its siblings or what prerequisites must be met.

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

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

Annotations already mark it read-only and closed-world. The description adds behavioral context beyond that: the packet is bounded by a token budget, tracks explicit omissions, and tells how to request omitted fields. No annotation contradiction.

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 dense sentence with no filler. The core object, scope, and noteworthy constraints are packed into a readable structure.

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?

Simple tool with one required parameter, yet no output schema and no return format details in the description. It explains the packet's contents but not how handoffId should be supplied or what failure cases look like; adequate but with 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 0% and the description never mentions the handoffId parameter, its type, or its role beyond the implied 'for a handoff'. With a low-coverage schema, the description should compensate but doesn't.

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?

Description names a specific verb ('Read'), a specific resource ('bounded delivery packet for a handoff'), and the packet's content ('fields kept within the token budget plus explicit omissions and how to request them'). This clearly distinguishes it from creation and thread-list sibling 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?

No guidance on when to use this tool rather than siblings such as get_thread_progress_summary or handoff_create. There are no prerequisites, exclusions, or alternative routing conditions; the description only states what the tool reads.

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

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

The annotations already indicate readOnlyHint=true, so the description only needs to add context beyond that. It does so by disclosing that the listing includes 'real capability grades,' which is meaningful behavioral information about the returned data. No contradiction with annotations.

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

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

The description is one short sentence with no filler. The key action and resource are front-loaded, and every word contributes to understanding what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only listing tool, the description is nearly complete: it names the resource and the nature of the output. Minor ambiguity remains about what exactly a 'provider adapter' is and what 'real capability grades' means in practice, but the low complexity reduces the need for more detail.

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 there are no parameter semantics to clarify. The schema coverage is trivially 100%, and the description does not misrepresent any input requirements.

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

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

The description uses a specific verb ('List') and names a concrete resource ('provider adapters') plus the expected output ('real capability grades'). It is reasonably distinct from siblings like list_models or list_agent_sessions, though it does not explicitly draw that distinction.

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 guidance on when to use this tool versus siblings such as list_models or list_agent_sessions, and no mention of prerequisites or exclusions. The intended use is implied by the name and description, but not explicitly framed.

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, and the description adds a meaningful behavioral nuance: provider failures are returned separately from an empty session list rather than failing the whole operation. This helps an agent interpret partial results, though it does not describe pagination or session fields.

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 two short sentences, front-loaded with the action and scope, followed by a useful failure-mode detail. There is no filler or redundant restating of the tool name.

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 low-complexity read-only listing tool with one optional enum parameter and no output schema, the description covers the most important behavior: sessions are discovered across providers, and provider failures are handled separately. It leaves out exact return fields and provider configuration details, but provides enough for 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 description coverage is 0%, yet the description never explains the optional provider parameter or whether it filters to one provider. The phrase 'across configured providers' weakly implies the default scope, but the agent is left to infer how the enum values behave.

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 ('Discover') and a specific resource ('native sessions across configured providers'), which makes the tool's function clear. It is distinguishable from sibling list tools like list_agents and list_threads, though it does not explicitly contrast itself with them.

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 implies usage: use this when you need to discover native sessions across providers. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives such as session_create or session_resume for working with sessions.

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, and the description does not contradict it. It adds the scoping detail that models come from the installed bridge, but it does not disclose return format or any other behavioral traits.

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 sentence that front-loads the action and stays free of redundancy. Every word 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?

The tool is a simple read-only list operation with no parameters and no output schema, so the description is nearly sufficient. It could be slightly stronger by noting that the listed model identifiers are what set_model consumes, but this is a minor gap.

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 and 100% schema coverage, so there is nothing for the description to clarify. Per the 0-parameter baseline, this is adequate.

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 and resource ('List models') and scopes the source ('exposed by the installed bridge'), clearly distinguishing it from sibling tools like set_model, list_projects, and list_threads.

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 intended use—discover available models before selecting one with set_model—is implied by the tool's name and sibling set, but not explicitly stated. No when-to-use conditions or exclusions are given.

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, which is consistent with the description. However, the description adds only the vague qualifier 'safe' without explaining what makes a file safe (e.g., filters, size limits, binary exclusion), nor does it disclose return format or edge-case 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?

The description is extremely short and front-loaded, but it is under-specified rather than concisely complete. The single sentence omits essential context that the tool requires, so brevity is achieved at the expense of usefulness.

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 tool with 0% schema coverage, no output schema, and a meaningful qualifier like 'safe', the description is incomplete. It does not explain the filtering semantics, the purpose of the 'relative' parameter, or how the result list behaves, leaving critical gaps for the agent.

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%, and the description does not mention either parameter. The 'relative' parameter is especially opaque, and with no schema descriptions or parameter explanations, the agent cannot determine what values are valid or what behavior they control.

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 the verb 'List' and the resource 'project files' clearly, so an agent can tell this is a listing operation. The qualifier 'safe' is ambiguous, but the core purpose is understandable and distinct from sibling tools like read_project_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention read_project_file, list_projects, or any condition for choosing this tool, so the agent is left to infer usage from the name and sibling list.

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 description doesn't need to restate its read-only nature. It adds the 'discovered' scope, indicating only discovered projects are returned, but it does not disclose pagination, ordering, or return structure. This is acceptable given the simple listing operation.

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

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

The description is a single, front-loaded sentence with no filler. It states exactly what the tool does in minimal words, which is ideal for a trivial no-argument listing operation.

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, the description is nearly sufficient. The only minor gap is the unexplained meaning of 'discovered' and the lack of an output schema, but the operation is simple enough that an agent can infer the expected behavior from the tool name and siblings.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. Per the baseline for zero-parameter tools, a score of 4 is appropriate; no parameter documentation 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 states a specific verb ('List') and a specific resource ('discovered Freebuff projects'), making its function immediately clear. The qualifier 'discovered' adds scope beyond the tool name, and the resource is distinct from siblings like list_threads and list_project_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives such as list_threads or list_project_files. The description does not mention conditions, exclusions, or contexts that would help an agent choose between 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?

The annotations already declare readOnlyHint=true, so the read-only nature is transparent. However, the description itself adds no behavioral details (e.g., no mention of sorting, pagination, or what a 'thread' entails). Since the annotation covers the key safety aspect, a baseline score of 3 is appropriate.

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

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

The description is a single, concise sentence with no wasted words or extraneous information. It follows a clear 'verb + resource' structure, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description omits critical context: parameter semantics, usage scenarios, output format (since there is no output schema), and any edge cases. This leaves significant gaps for an agent to call the 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 only parameter, projectId, has no description in the schema, and the tool description does not explain its meaning or optionality. With 0% schema description coverage and no textual clarification, the agent has no semantic understanding of this 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 clearly states the action ('List') and the resource ('Freebuff Desktop threads'), making the primary purpose unambiguous. However, it lacks any context about what 'Freebuff Desktop' refers to or whether threads are scoped to a project, which prevents a perfect score.

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 no guidance on when to use this tool versus alternatives like get_thread or get_thread_messages. No prerequisites, expected input conditions, or typical scenarios are mentioned, leaving the agent without direction for tool selection.

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

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

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond that: these requests are never auto-approved and are deliberately waiting for an explicit human decision, which explains the semantic state of the listed items. No contradiction with annotations.

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

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

The description is two short sentences with no filler. The first sentence front-loads the action and object, and the second adds a critical operational qualifier without 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 zero-parameter, read-only list tool with annotations covering safety, the description is complete enough for an agent to select and invoke it correctly. It clearly names what is listed, the state of the items, and the key behavioral constraint. No output schema exists, but the return is implied as a list of requests.

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

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

The tool has zero parameters and an empty input schema, so parameter semantics are vacuously satisfied and no description-level compensation is needed. The description's focus on the resource type is sufficient for invocation.

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 and resource: 'List provider permission requests awaiting an explicit human decision.' The qualifier 'Never auto-approved' sharpens the state of the listed items and helps distinguish this read-only listing tool from sibling tools like permission_respond, which handles the actual response action.

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 implies when to use the tool: when an agent needs to see permission requests that still require human action. However, it does not explicitly state when not to use it or name the alternative tool (permission_respond), so the routing guidance is left to inference rather than being stated.

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 indicate readOnlyHint=false and destructiveHint=false, implying the tool has side effects but is not necessarily destructive. The description says 'respond' but doesn't disclose consequences, reversibility, or error behavior. It also doesn't explain what happens when a request is 'not supported,' leaving the agent with no expectations about 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 extremely concise, but it achieves this by omitting critical information. For a tool with four required parameters and no schema descriptions, this brevity is under-specification rather than clarity. It doesn't earn its place because it fails to convey necessary usage details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four required parameters, no schema descriptions, and no output schema, making it moderately complex. The description is entirely inadequate: it doesn't explain the decision parameter's allowed values, how to obtain nativeId and requestId, which provider to use, or the meaning of 'when supported.' An agent cannot safely invoke this tool based on the provided text.

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 compensate by explaining each parameter. It does not. It doesn't mention how to fill provider, nativeId, requestId, or decision, nor does it define valid decision values. The single sentence adds no semantic value beyond the raw schema.

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

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

The description clearly states the action: 'Respond to a provider permission request.' The verb 'respond' and resource 'permission request' are specific, and it implicitly distinguishes from sibling tools like permission_pending (which likely lists requests). However, it doesn't explicitly mention the sibling or the exact context, so it lacks 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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like calling permission_pending to obtain the request ID. The phrase 'when supported' is vague and doesn't clarify under what circumstances the tool is available. There is no instruction on how to construct the required parameters.

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 read-only nature is covered by structured data. The description adds no concrete behavioral details such as what 'safe' means, whether path traversal is blocked, what the return payload is, or how errors are reported.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise, though the ambiguous 'safe' term could be replaced with more informative content without making the description longer.

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 tool with no output schema and no parameter descriptions, the description is too thin. It does not explain what 'safe project file' means, how the path should be specified, or how this tool complements list_project_files, leaving too much for the agent to infer.

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% and the description does not explain the parameters. While 'projectId' and 'path' are self-descriptive names, the description does not clarify path semantics, format, or constraints, so it fails to compensate for the missing schema descriptions.

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 clear action verb, 'Read,' and identifies the resource, 'project file.' The qualifier 'one' helps distinguish it from list_project_files (list vs read a single file). However, 'safe' is ambiguous and not elaborated, slightly weakening clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool over list_project_files, get_thread, or other siblings, and no mention of prerequisites like a valid projectId or path format. Use cases must be inferred from the tool name rather than stated.

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 indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds nothing beyond the verb 'resume' – it does not disclose side effects, required permissions, or what happens to the thread's state. With annotations present, the bar is lower, but the description still fails to add meaningful behavioral context.

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 sentence with no redundancy. It is appropriately concise for the tool's simplicity, and the verb is front-loaded. No waste.

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 mutation with one parameter, the description is minimal but incomplete. It lacks information about expected outcomes, error conditions, or any prerequisites. Given no output schema and no usage guidance, an agent cannot fully understand what will happen when the tool is called.

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

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

The schema has zero description coverage for the single parameter threadId. The description does not explain what threadId refers to (e.g., a valid thread ID, format, or how to obtain it). Since the description is the only source of parameter meaning, this is a significant gap.

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 clear verb ('Resume') and resource ('a paused Freebuff thread'), which identifies the operation unambiguously. It is distinct from siblings like stop_thread or get_thread, though it doesn't explicitly name the alternative. The phrasing is specific enough to convey the action.

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 guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., thread must be paused), and no exclusions or context about typical use cases. The description implies use when a thread is paused, but it is left to the agent to infer.

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 indicate readOnlyHint=false, so the agent knows this is a write operation. The description adds meaningful context that the review is an 'agent_claim' and 'never provider observations', clarifying the intended data source. This goes beyond the structured annotations and helps prevent misuse. No contradiction with annotations is present.

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

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

The description is a single, efficiently written sentence that fronts the primary purpose. No wasted words, and the additional behavioral note is succinct yet informative. It perfectly balances brevity with the necessary core message.

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 six required parameters, including nested objects, and no output schema, this tool demands more explanation. The description lacks details on how to construct 'independence', 'findings', or what the response will look like. An agent would struggle to correctly populate all fields. The description is far from sufficient for 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 description coverage is 0%, and the description adds no explanation for any of the six required parameters. While some names like 'verdict' and 'findings' are self-explanatory, complex objects like 'independence' and arrays like 'subjectEvidenceIds' lack context. The description's mention of 'agent_claim' partially relates to data nature but does not clarify individual parameters. The burden is on the description to compensate, and it fails to do so.

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 the verb 'Record' with resource 'a review', which clearly states the tool's purpose. It adds a distinguishing note about the nature of the content (agent claim vs. provider observations) that helps set expectations beyond a generic 'create review'. However, it does not explicitly name or contrast with sibling tools like review_request, so it falls short of the highest score.

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 no guidance on when to use this tool versus alternatives. It does not state prerequisites, conditions, or exclusions. The only hint is the behavioral note, but that is about data semantics, not usage context. An agent cannot determine when to invoke this tool over a sibling like review_request or work_verify.

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 are sparse (readOnlyHint false, openWorldHint false, destructiveHint false), and the description adds one meaningful behavioral fact: the repository-diff fallback requires the subject session workspace and never guesses process.cwd(). That is helpful, though it does not clarify side effects, whether a request can be duplicated, or what happens on failure.

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

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

The description is a single, front-loaded sentence that states the main purpose first and puts the important fallback caveat second. There is no padding or repetition, and the caveat earns its place by warning about a likely error.

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 7 required parameters, no output schema, 0% schema description coverage, and no usage guidance, the description is not complete enough for an agent to safely select and invoke the tool. It explains one edge behavior but leaves the overall request semantics, expected effect, and parameter relationships mostly implicit.

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 carries the burden of explaining parameters, but it does not. The only parameter insight is implied: the subject session workspace relates to subjectProvider/subjectNativeId. The meanings of workId, objective, acceptanceCriteria, and reviewer fields are left entirely to the schema's bare names.

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 ('Send') and resource ('evidence-backed review request'), so an agent can tell this is about submitting a review request rather than reading or modifying state. It even adds a distinctive detail, the repository-diff fallback, but it never explicitly distinguishes this from the sibling review_create, leaving some ambiguity.

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 guidance on when to choose this tool over review_create, work_verify, or other related sibling tools. The caveat about the repository-diff fallback requiring the subject session workspace is more of a precondition than a usage rule, and no alternatives or exclusions are mentioned.

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 the safety profile (readOnlyHint=false, destructiveHint=false), so the bar for additional disclosure is lower. The description adds the 'existing thread' precondition, implying failure for unknown thread IDs, but it does not disclose side effects such as appending to conversation history or 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 10-word sentence with zero filler, front-loaded with the action verb. Nothing is redundant or extraneous.

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 output schema, the description is close to adequate and implicitly identifies both inputs. However, it never states what the tool returns (e.g., the model's reply) or error conditions, which matters more given that no output schema exists to carry that burden.

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 compensate, but it only loosely maps 'text prompt' to text and 'existing' to threadId. The schema property names are already self-explanatory, and the description adds no format, length, or usage details beyond them.

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 ('send') with a specific resource and scope ('text prompt to an existing Freebuff thread'), making the operation unmistakable. It is clearly distinct from the sibling read-only tools (freebuff_status, list_projects, list_threads).

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 explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The intended context is implied by contrast with the list/status siblings, but the description never states prerequisites like 'obtain threadId via list_threads first' or excludes other send/update 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?

Annotations already communicate that this operation is not read-only and not destructive, so the description does not need to restate that. The phrase 'when supported' adds a useful behavioral caveat that some providers may not allow native session creation. However, the description does not disclose failure behavior, side effects, or whether an existing session may be replaced.

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

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

The description is a single, front-loaded sentence with no filler words. It is appropriately brief for the core action, though it sacrifices beneficial detail for brevity. It earns its place but does not go beyond the minimum.

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 three parameters, no output schema, and no parameter descriptions, the tool needs more context to be safely invoked. The description does not explain what a 'native provider session' is, how unsupported providers are handled, or how cwd and title influence the session. The annotations provide only basic mutation hints, leaving the agent under-informed.

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

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

The schema has 0% description coverage, so the description carries the full burden of explaining parameters, but it mentions none of provider, cwd, or title. The enum in the schema lists provider values, yet the description does not clarify how provider affects support or what cwd and title mean. This is a significant gap for an agent trying to construct a correct invocation.

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 identifies the action (create) and the resource (native provider session), which is sufficiently specific to distinguish it from session_resume and session_set_model among siblings. The qualifier 'when supported' adds a condition but does not undercut the core purpose. It is not a tautology and conveys the basic operation clearly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use session_create versus session_resume, session_set_model, or other session-related tools. It does not state prerequisites, typical invocation context, or when the 'supported' condition is likely to be true. Usage context is only weakly implied by the verb 'create'.

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 indicate this is a state-changing but non-destructive operation, and the description adds the detail of 'reattach' and 'exact' without explaining side effects. It does not disclose what happens to the existing session, whether resuming is idempotent, what state the session will be in after the call, or what occurs if the native session is not found.

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

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

The description is a single short sentence with no redundant fluff, earning it a point for brevity. However, it is under-specified rather than concisely complete; important behavioral and parameter details are absent, so the one sentence does not fully earn 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 tool with two required parameters, no output schema, and a mutating operation, the description lacks critical context: return behavior, error cases, prerequisites (e.g., must a session already exist?), and relationship to sibling tools. The agent is left with a name and schema that do not fully explain how to invoke the tool correctly in context.

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

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

Schema description coverage is 0%, so the description bears the burden of explaining the two required parameters. It only implies the importance of 'exact' identity through 'exact native session,' but never clarifies how provider relates to nativeId, how to obtain nativeId, or what formats are expected. The enum values for provider are listed in the schema but their meaning in this context is left 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?

The description names a specific action ('Resume or reattach') and a clear resource ('an exact native session'), which distinguishes it from generic session management. The phrase 'exact native session' also hints at a distinct scope compared to sibling tools like resume_thread, though it does not explicitly name any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus resume_thread, session_create, or other session-related tools. There are no conditions, exclusions, or alternative tool references, leaving the agent to infer the appropriate context from the name and schema alone.

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 only say non-read-only and non-destructive, so the description must carry behavior details. It adds that support is conditional ('when supported') and that OpenCode accepts providerID/modelID, but it doesn't disclose failure modes, side effects, or permission requirements. That's minimal but non-contradictory.

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 filler and the primary action front-loaded. The second sentence is somewhat cryptic ('OpenCode accepts providerID and modelID') but still 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?

Three required parameters and no output schema, yet the description gives only a two-sentence overview. It doesn't specify which provider values are valid (schema does), what the model object shape is beyond a hint, or what a successful change returns. For a non-read-only tool, this is thin.

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?

With 0% schema description coverage, the description needed to explain provider, nativeId, and model. It hints that nativeId identifies the exact native session and that opencode uses providerID/modelID, but it never explains the string vs object forms of model or the provider enum. Partial compensation at best.

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 action ('Change the model') and a specific target ('an exact native session'), which separates it from generic model-setting tools. The 'when supported' caveat and the OpenCode note add useful context. It doesn't explicitly name sibling tool set_model, but the 'native session' qualifier makes the scope clear.

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 explicit guidance on when to use this tool over siblings like set_model, session_resume, or session_create. The only condition is 'when supported', which is too vague to route an agent. There are no exclusions or alternative tool names.

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 indicate a mutating but non-destructive operation, and the description adds a useful caveat: support is conditional. However, it does not disclose what happens when a provider is unsupported, whether existing reasoning settings are overwritten, or any side effects on the session.

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 sentence that is fully front-loaded with the essential action, target, and limitation. There is no redundant wording or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a required-parameter mutation tool with no output schema, the description leaves key operational questions unanswered: which providers support reasoning changes, what input values effort accepts, and how unsupported cases behave. The presence of sibling tools like set_reasoning makes this incompleteness more costly.

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?

With 0% schema description coverage, the description must compensate, but it only partially maps to parameters: 'reasoning effort' hints at effort and 'exact native session' hints at nativeId. The required provider parameter is entirely unaddressed, and valid effort values are not explained.

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 ('Change') with a clear resource ('reasoning effort') and a distinct scope ('an exact native session'). It also signals a capability boundary with 'when supported,' which helps distinguish it from broader tools like set_reasoning or session_set_model.

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 no guidance on when to prefer this tool over siblings such as set_reasoning, session_set_model, or other session-related tools. 'When supported' hints at conditional applicability but gives no criteria, alternatives, 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?

The annotations already indicate this is a mutating operation (readOnlyHint=false) but not destructive (destructiveHint=false), and the description adds little beyond that. It does mention 'existing thread' and 'when supported,' but it does not disclose what happens to the thread's conversation, whether the change persists, or whether unsupported models cause errors. No contradiction with annotations exists, but the behavioral context is thin.

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

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

The description is a single, direct sentence with no filler or redundant information. It front-loads the core action and resource. It is concise, though the vague 'when supported' could be replaced with more concrete conditions without hurting readability.

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 tool with three parameters and no output schema, the description is too thin to fully support correct invocation. It does not explain how to identify a supported thread, what model naming convention to use, or what harnessId means, and it offers no guidance relative to sibling tools. The flat schema and simple operation lower the bar, but 'when supported' still leaves critical context 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 0%, and none of the three parameters (threadId, model, harnessId) are described in the schema. The description only mentions 'model' and 'existing thread' generically, giving no semantics for valid model values, the role of threadId, or the optional harnessId. With zero schema coverage, the description needed to compensate 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?

The description uses a specific verb ('Set') and a clear resource ('the model for an existing thread'), so an agent can understand the core action. It does not explicitly differentiate from siblings, but none of the siblings perform the same model-setting operation, so the ambiguity is mild. The phrase 'when supported' introduces some uncertainty but does not obscure the main purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives only a vague condition ('when supported') and no concrete guidance about when to call this tool versus alternatives, what makes a thread 'support' model changes, or what prerequisites must hold. It also does not explain when this tool should not be used or how it relates to siblings like list_models or send_message. This leaves usage decisions largely 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?

Annotations already indicate a mutating operation (readOnlyHint: false) with no destructive flag. The description adds only the vague qualifier 'when supported,' which doesn't disclose concrete behavior such as whether the change takes effect immediately, whether it requires specific permissions, or whether it can be reversed. With annotations present, some credit is given, but the description adds minimal behavioral context.

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

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

The description is a single, efficient sentence that front-loads the primary action. It avoids fluff and is appropriately sized for a simple operation. The brevity is a positive trait, though it sacrifices necessary 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 tool with two required parameters and no output schema, the description is woefully incomplete. It omits what reasoning effort means, how to select appropriate values, when the operation succeeds or fails, and how it relates to sibling tools like set_model. An agent would have to infer most of the necessary context from parameter names alone.

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 compensate for the lack of parameter meaning. It does not explain what 'effort' values are valid, what 'threadId' refers to beyond being a thread identifier, or the relationship between the two. The schema only provides types (string|null for effort), leaving the agent to guess allowed values or formats. The description fails to add any semantic value.

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 clear action: 'Set the reasoning effort' on a thread. It identifies the resource (thread) and the specific attribute (reasoning effort), which distinguishes it from sibling tools like set_model or send_message. However, it doesn't explicitly differentiate from alternatives, so it's clear but not fully distinguishing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The phrase 'when supported' hints at conditional applicability, but it doesn't explain which threads or models support it, nor does it mention when to prefer set_reasoning over set_model or other thread-management tools. An agent has to infer context.

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

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

The annotations indicate this is neither read-only nor destructive, but the description adds no detail about what stopping a turn actually does, such as whether work is lost or whether the turn can be resumed. No contradiction with annotations is present, but the description alone does not disclose behavioral consequences.

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

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

The description is a single short sentence with no filler, and the action is front-loaded. It loses a point for using the unexplained term 'Freebuff turn,' but overall it is efficiently sized.

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 tool with one required parameter, the description provides a minimally viable statement of the operation, but it leaves out behavioral effects, when to use it, and how the threadId relates to the action. With no output schema and sparse annotations, slightly more context would make it 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 0%, and the description does not mention threadId or explain that it identifies the thread whose turn should be stopped. The parameter name is fairly self-explanatory, but the description does nothing to compensate for the missing schema 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?

The description states a specific action, 'Stop', and the resource, 'a running Freebuff turn', so the core operation is clear. It does not explicitly name sibling tools, so differentiation from resume_thread is only implicit.

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 word 'running' implies the tool is for stopping an in-progress turn, but the description gives no explicit guidance about when not to use it or that resume_thread is the counterpart for resuming afterward. Usage context is inferred rather than directly stated.

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 covers the safety profile, and the description does add 'live'/'latest' freshness semantics beyond the annotation. However, it does not disclose what counts as an 'active' thread, whether the call blocks or polls, or what the result looks like when no threads are active. No contradiction with annotations.

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

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

A single, tightly written sentence with no filler or redundancy. The verb and object are front-loaded, and every word contributes meaning ('latest', 'live', 'active', 'Desktop').

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 tool with no output schema, the description is nearly complete. The only gaps are the unstated content/shape of the returned summary and the definition of 'active', but these are minor for such a simple tool and the annotation covers the safety dimension.

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 baseline of 4 applies. There is nothing for the description to explain about parameters, and the empty schema is already unambiguous on its own.

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 ('Return'), a specific resource ('live progress summary'), and a clear scope ('each active Desktop thread'). The plural, thread-wide scoping makes it distinguishable from closely named siblings like watch_thread and get_thread_progress_summary without needing to open any schemas.

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 explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The description implies a monitoring use case ('latest live progress'), but it never clarifies how this differs from watch_thread (singular) or get_thread_progress_summary, leaving the agent to infer the right selection among overlapping siblings.

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?

Beyond the readOnlyHint annotation, the description discloses the blocking wait, the 30-second upper bound, and the bounded snapshot nature. It doesn't state what happens on timeout or when no events arrive, but the annotation already covers the read-only safety profile.

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 one focused, front-loaded sentence with no filler. Every phrase contributes meaning: the wait, the duration, the event type, and the result shape.

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 core contract is clear, but the tool has four parameters, no parameter descriptions, and no output schema. The description leaves afterSequence, limit, timeoutMs, and the snapshot contents mostly to inference, which is insufficient for reliable 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 description coverage is 0%, and the description names none of the parameters. 'Up to 30 seconds' hints at timeoutMs and 'bounded' hints at limit, but threadId and afterSequence remain unexplained, so the description does not compensate for the missing schema 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?

The description states a specific behavior: wait up to 30 seconds for live progress events, then return a bounded read-only snapshot. This distinguishes it from simple thread readers and progress summaries, though it doesn't explicitly contrast it with watch_active_threads or get_thread_progress.

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 use when live progress events are needed, but it gives no explicit when-to-use guidance and doesn't mention alternatives or conditions for choosing watch_active_threads or get_thread_progress 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?

Annotations already indicate this is not read-only and not destructive; the description adds 'durable', implying persistence. However, it does not disclose side effects, response behavior, or any post-creation consequences, leaving meaningful 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?

The description is a single, front-loaded sentence with no filler. It conveys the core action and key constraint efficiently.

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 create operation, 5 parameters, no output schema, and minimal annotations, the description is too sparse. It lacks return-value expectations, usage context relative to siblings, and parameter semantics, so an agent would need significant inference to invoke 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?

Schema description coverage is 0%, so the description must compensate, but it only mentions 'acceptance criteria'. Required field 'objective' and optional fields like 'risks', 'sourceSession', and 'unresolvedQuestions' are left unexplained beyond their property names.

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

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

The description states a specific action ('Create') on a specific resource ('durable work item') and adds a distinguishing qualifier ('with acceptance criteria'). This clearly separates it from read-only siblings like work_get and work_list, and from other create tools like handoff_create and review_create.

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 guidance on when to use this tool versus alternatives such as work_verify, handoff_create, or review_create. The description implies creation, but does not state conditions, prerequisites, or explicitly distinguish from sibling creation 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?

Annotations declare readOnlyHint=true and openWorldHint=false, and the description's 'Read' is consistent with these—no contradiction. The phrase 'and its evidence' adds modest context about what is returned, though return format and any access requirements are undisclosed. With annotations carrying the safety profile, the description adds limited value beyond them.

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 efficient sentence that front-loads the core purpose with no filler. It is appropriately brief for a simple one-parameter read tool, though it leans toward under-specification rather than true conciseness.

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 low-complexity tool (one parameter, no output schema, read-only annotations covering safety), the description conveys the essential purpose. The main gap is the unexplained workId parameter and what 'evidence' encompasses, but the tool's simplicity keeps the missing context minor.

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 carries the full burden of explaining workId, but it says nothing about what the parameter means, its format, or how to obtain a valid value. The description does not compensate for the schema's silence on the single required 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 states a specific verb ('Read') and a resource ('durable work record and its evidence'), which distinguishes it from siblings like work_list and work_create. 'Durable' and 'and its evidence' add useful specificity, though the relationship to evidence_list is not elaborated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as work_list, work_verify, or evidence_list. There is no mention of prerequisites, exclusions, or the situations where a sibling would be preferable.

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 indicate readOnlyHint=true, so the description is consistent. It adds some behavioral context by noting output includes 'objective previews and criteria counts,' but it does not disclose pagination, ordering, scope limits, or the exact shape of the returned records.

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. Every word adds meaning: the verb, the resource type, and the key output components are all included.

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, parameterless read-only list tool, the description covers the essential purpose and output highlights. It lacks an explicit return schema or details about filtering, but the low complexity and zero parameters keep the requirement modest.

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 baseline is 4. The description appropriately focuses on the tool's behavior rather than parameters, and no parameter documentation 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?

States a specific verb ('List'), a resource ('durable work records'), and distinctive output aspects ('objective previews and criteria counts'). This differentiates it from sibling tools like work_get (single record), get_active_work (active vs. durable), and get_work_graph (graph structure).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'durable work records' provides clear context that this lists persisted work items rather than active/transient work, which distinguishes it from siblings like get_active_work. However, it does not explicitly name alternatives or state when not to use this 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?

The annotations already communicate that this is not read-only and not destructive. The description adds useful behavioral context by stating an allowlist-style constraint ('accepted'), a hard limit of 8 commands, and an explicit environment-gate requirement. This goes beyond what the annotations and schema alone provide.

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 deliver the core action, command format constraint, max count, and required environment variable with no filler. The most important operational facts are front-loaded.

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 command-execution tool with no output schema, the description omits important details: what workId refers to, what the return value looks like, how success or failure is signaled, and what 'accepted' means in practice. The env-var requirement and max-8 limit are useful, but an agent is left with material 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 0%, and the description only restates that commands are strings or objects with executable/args/cwd, which the schema already exposes structurally. It does not explain the purpose of the required workId, the top-level cwd, or how each command variant behaves, so it does not compensate for the missing schema descriptions.

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 concrete action—'Run all accepted verification commands'—and gives a limiting constraint, 'max 8', plus the entry format. This clearly identifies the tool's resource without needing to open the schema. It does not explicitly name a sibling alternative, so it falls just 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?

The description focuses on what the tool does rather than when to use it or which alternative to choose. It mentions a required environment variable, INTEROP_ALLOW_VERIFICATION=1, which is a prerequisite, but gives no guidance on when this tool is preferable to sibling tools or when it should not be used.

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