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

Beyond the annotations (all false), the description adds meaningful behavioral detail: validations are performed locally, the operation results in exactly 'one non-retried /api/respond write'. This discloses retry semantics and the mutation path, which is useful for an agent deciding whether to invoke or expect idempotency. It does not contradict any annotation; readOnlyHint false aligns with 'write'.

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 earns its two sentences. The first sentence front-loads the core action in clear terms, and the second adds dense behavioral context without fluff or redundant repetition of the schema. Every phrase contributes to helping an agent understand the tool.

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

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

For a 5-parameter write tool with no output schema, the description is largely complete: it explains the core action, known validation, and write behavior. Optional parameters like sinceCursor and expectedRevision lack any contextual hint in the description or schema property descriptions, which is the main gap preventing a perfect score.

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 schema description coverage at 0%, the description carries the naming burden. It partially succeeds by referencing 'requestId', 'task lineage', 'question ids/order', and 'selections', mapping loosely to requestId, taskId, answers[].id, and answers[].selected. However, optional parameters sinceCursor and expectedRevision are omitted, and there is no explicit mapping to the schema's custom field or the shape of the answers array.

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

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

The description clearly states the tool's action ('Answer') and resource ('one currently pending typed DSH question request'), making it immediately obvious what the tool does. It lacks an explicit distinction from sibling tools like dsh_continue or dsh_followup, but the phrase 'currently pending typed DSH question request' narrows the purpose enough for an agent to separate it from general session or status 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?

The phrase 'currently pending typed DSH question request' implies when to use the tool: when there is a pending question to be answered. However, the description does not explicitly say when not to use it or which sibling alternative to prefer (e.g., dsh_continue, dsh_followup). Usage guidance is implied rather than stated, leaving some room for an agent to misroute a call.

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 the tool as destructive, and the description adds genuinely useful behavior beyond that: the turn scope explicitly preserves queued work, and queue removal is described as non-atomic and based on the latest mux queue snapshot. This is meaningful transparency about what gets destroyed.

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 compact, front-loads the primary scope behavior, and either sentence earn its place. No redundant text, no restating of the tool title or generic cancellation wording.

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

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

For a destructive 4-parameter tool with no output schema, the description does not explain return behavior, partial failure states, or the semantics of sinceCursor/expectedRevision. The scope behavior and non-atomic queue removal are helpful, but important invocation context is still missing.

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

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

The schema has 0% description coverage and the description only explains the scope enum. taskId, sinceCursor, and expectedRevision are left completely unexplained, so the agent cannot infer the meaning of important parameters like optimistic concurrency guards or cursor-based synchronization.

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 concrete behavior for each scope: scope=turn cancels the active root turn and preserves queued work, while scope=queue removes queued items. It is clear about what the tool operates on, though it does not explicitly distinguish itself from sibling tools by name.

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 clear context for choosing a scope, including that it not’s queued work and that queue removal is non-atomic. It does not provide when-not-to-use guidance or name alternatives like dsh_continue or dsh_release_workspace, so it stops short of very explicit 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?

With all annotations false, the description carries the burden and adds useful context: it clarifies that the tool performs a write, is scoped to the same root DSH session, and explains the behavior of queue and steer modes. It also notes that writes are never automatically retried, a non-obvious 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 three short sentences that front-load the purpose and follow with mode semantics and retry behavior. There is zero filler, making it highly efficient.

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

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

No output schema and all false annotations require the description to cover behavior. It does cover core intent and mode semantics, but neglects parameter details, error conditions, and return values. As a compatibility alias, it is somewhat adequate but not 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?

Schema coverage is 0%, so the description must explain parameters. Only 'mode' gets semantics via queue/steer explanation; the other four parameters (prompt, taskId, sinceCursor, expectedRevision) are not addressed beyond vague 'same root' wording, leaving the agent under-informed about their 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 clearly states it is a compatibility alias for dsh_followup and continues the same root DSH session. It distinguishes between queue and steer modes with specific targets, making the tool's purpose unambiguous.

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

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

The description implies usage as a drop-in replacement for dsh_followup but does not explicitly contrast with alternatives. It provides guidance on when to use queue vs steer, but lacks exclusions or conditions for choosing this tool over other 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 description adds meaningful behavioral context beyond the annotations: it states the tool creates a session (mutation), uses DSH's configured model (so no model parameter), and is detached by default. The annotations only provide false hints, so this extra information is valuable, though it does not cover return behavior or session identification.

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

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

The description is three concise sentences with no filler or repetition. It front-loads the core purpose and adds only high-signal details about model usage and detachment.

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 six parameters and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., session ID), how to interact with the created session, or the meaning/effects of parameters like waitSeconds or workspaceMode. The lack of annotation guidance further burdens the description, which it does not fully carry.

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

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

Schema coverage is only 17%, with only 'cwd' described in the schema. The description does not explain any of the six parameters (prompt, title, agentPreset, waitSeconds, workspaceMode). The note about 'no model argument accepted' is a constraint, not a parameter explanation, and 'cwd' is already covered by 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 clearly states a specific action: 'Create a root session on the configured official DSH Web Host and queue the initial prompt.' It also differentiates from siblings by noting 'no model argument is accepted' and 'Detached by default,' which sets it apart from follow-up or observation 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?

The description clearly conveys when to use it: for creating a root session and queuing the initial prompt. It implicitly indicates it is the entry point for a session, distinguishing from siblings like dsh_followup or dsh_continue, but it does not explicitly state exclusions or when not to use it.

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 annotation already indicates it is not read-only (readOnlyHint=false), and the description adds meaningful behavioral details: the write is never automatically retried, and the queue/steer modes define how the followup is targeted. This goes beyond the annotation by clarifying retry behavior and mode semantics.

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 sentences with no filler. It front-loads the core purpose, then adds mode distinction and retry behavior. Every sentence contributes essential 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?

The description covers the main behavior, mode semantics, and retry policy, but with no output schema and multiple siblings, it doesn't explain the intended response, prerequisites (e.g., session must exist), or interactions with dsh_status/wait. It is adequate but leaves 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 clarifies the 'mode' parameter (queue vs steer) and indirectly the 'prompt' (as the written content). It leaves 'taskId', 'sinceCursor', and 'expectedRevision' completely unexplained, which is insufficient given five parameters and no schema 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 clearly identifies the tool's function ('Continue the same root DSH session') and distinguishes its two operational modes (queue vs steer). However, it doesn't explicitly differentiate this tool from the sibling 'dsh_continue', which may cause 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?

The description implies usage context ('continue the same root DSH session') and provides within-tool guidance on when to use queue vs steer, but it lacks explicit guidance on when to use this tool instead of siblings like dsh_continue or dsh_delegate.

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 disclose that this is read-only and idempotent, and the description reinforces that by saying 'report.' It adds some context about what is reported but does not disclose return format or potential operational behavior such as network dependency or staleness. 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?

The description is a single, information-dense sentence with no filler. Every phrase contributes meaning, and the main subject is 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 zero-parameter, read-only status tool with strong annotations, this description is adequate. It could be slightly more complete by saying what shape the report takes or what counts as a 'capability,' but the operational risk and ambiguity are low.

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

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

The tool takes zero parameters, so there is no parameter semantic burden on the description. The schema is empty and correctly set to disallow additional properties.

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 verb ('Report') and names the two things being reported: the connect-only bridge state and DSH Web Host capabilities. It is reasonably specific, though it does not explicitly differentiate itself from the sibling dsh_status tool.

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 this tool versus alternatives like dsh_status or dsh_observe. It implies a general status-checking use case but does not state exclusions or conditions for selecting another sibling.

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 tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying that the list is enriched with DSH status only when the Host is reachable, implying conditional output. However, it doesn't explain fallback behavior when the host is unreachable or the output format.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds value: action, resource, enrichment, condition.

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 parameters and no output schema, the description gives the essential information: what is listed and the condition for enrichment. It could clarify behavior when Host is unreachable, but the overall context is sufficient for a simple list operation.

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 schema coverage is 100%. The description accordingly has no need to explain parameters; the baseline of 4 applies due to zero-parameter 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 tool's action ('List') and resource ('bridge task mappings'), with a specific qualifier about enrichment. This differentiates it from sibling tools like dsh_status which likely focus on status of a single task rather than listing mappings.

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 when the user needs a list of bridge task mappings, but it does not provide explicit when/when-not guidance or mention alternatives among sibling tools. It lacks context on when to prefer this over dsh_status or dsh_host_status.

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 read-only, idempotent, and non-destructive behavior, so the description's burden is lower. The description adds deprecation/compatibility context and indicates that the intended operation is covered by dsh_wait plus dsh_tail, which is behavior that annotations cannot express.

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?

Both sentences are short and front-loaded, and there is no wasted wording. It loses a point because the description is under-specified rather than merely concise, especially around what the compatibility alias does and how its parameters behave.

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 compatibility-only alias, the description provides adequate routing and safety context. However, because there is no output schema and the description never states what the call returns or how cursor/wait semantics behave, the overall picture is incomplete for an agent that actually needs to invoke this tool.

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

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

Schema description coverage is 0%, and the description does not compensate at all, saying nothing about taskId, afterCursor, or waitSeconds. An agent must infer the meaning of all three parameters from bare names, patterns, defaults, and constraints, which is insufficient for 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 dsh_observe as a 'compatibility observation alias' and points to dsh_wait/dsh_tail, so an agent knows roughly where it belongs. However, it never states what the observation actually does, what resource it targets, or what kind of result the agent should expect, leaving the purpose somewhat vague.

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?

"Prefer dsh_wait plus dsh_tail task cursors" is an explicit routing instruction with named alternatives, which is genuinely useful. What is missing is the corresponding 'when not to use' and 'when it is acceptable to use this compatibility alias' guidance, though 'compatibility' provides part of that 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?

Annotations already indicate destructive=true, and the description adds valuable context by clarifying that releasing the claim does not close the DSH session or stop Web/Codex from editing. This helps prevent misuse. It could add more about consequence (e.g., whether the claim can be reacquired), but the added exclusions are meaningful beyond the structured hints.

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 sentences and immediately front-loads the primary action and resource. Each sentence adds value: the first states the purpose, the second clarifies non-effects. No filler or repetition.

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

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

For a low-complexity tool with one obvious parameter and no output schema, the description covers the core purpose and key exclusions. It does not describe return values or post-conditions, but given the simplicity and the sibling context, it is sufficiently complete. Slightly more detail about what happens after release would push it higher.

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

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

There is one required parameter, taskId, with 0% schema description coverage. The description never mentions taskId nor explains that it identifies the bridge task whose workspace claim is released. While the name and pattern are somewhat self-evident, the description fails to compensate for the lack of schema descriptions, leaving the agent to infer the parameter's role.

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 ('Explicitly release') on a specific resource ('this bridge task's persistent workspace claim'). It also clearly distinguishes itself from related actions by noting it does not close the session or stop editing, which separates it from siblings like dsh_cancel and dsh_continue.

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 you need to release a workspace claim. It also clarifies what it does not do, providing useful boundaries. However, it does not explicitly reference alternative tools or state 'use this instead of X', so it lacks the explicit when-not/alternatives guidance of a perfect score.

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 annotations (destructiveHint=true), the description adds significant behavioral detail: 'Never auto-allows' and the need for approval_mode=prompt configuration. This clarifies safety-critical behavior not captured by 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 sentences, front-loaded with the core purpose. The second sentence is a necessary safety warning. No filler words 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?

For a destructive tool with 5 parameters and no output schema, the description covers the basic purpose and safety constraint but omits details about side effects, consequences of each outcome, and prerequisites beyond 'pending.' It is minimally adequate but leaves 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?

With 0% schema description coverage, the description must explain parameters. It only mentions 'allow_once' and 'reject' which map to the outcome enum, but leaves taskId, requestId, sinceCursor, and expectedRevision unexplained. This is insufficient compensation for the lack of 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 clearly states the action: 'Resolve one pending DSH sandbox-escalation approval as allow_once or reject.' This specifies the verb (resolve), the resource (approval), and the possible outcomes, distinguishing it from 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?

It provides a critical usage prerequisite: 'configure this Codex MCP tool with approval_mode=prompt before permitting allow_once.' It also implies the tool is for pending approvals, giving clear context. However, it does not explicitly name alternative tools or exclusion conditions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to re-state safety. It adds value by enumerating the detailed return contents, but it discloses no additional behavioral traits like permission requirements, performance implications, or error handling. This is acceptable given the strong annotation coverage.

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 sentence that front-loads the verb and lists key status aspects. While it is a long list, it is still concise and efficiently communicates the tool's output breadth 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?

The tool returns many distinct elements, and without an output schema the description carries the burden of explaining return values. It lists them explicitly but lacks details on their structure, meaning, or edge cases. It also provides no usage context, making the description adequate but not fully complete for a complex status tool.

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

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

The schema has one required parameter taskId with zero description coverage, and the tool description does not mention it or explain its format or purpose. The description fails to compensate for the schema's lack of parameter documentation, leaving the agent to infer taskId solely from the name and pattern.

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

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

The description clearly states the tool returns a comprehensive status object, listing specific components like availability/execution state, sessions, queue depths, and bridge cursor/watermarks. This distinguishes it from siblings like dsh_host_status, though it does not explicitly mention the task context, which is implied by the taskId parameter.

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 dsh_tail or dsh_host_status. The description only lists output fields without indicating preferred scenarios or exclusions, so an agent must infer usage from the tool name and 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful beyond-annotation context: content is fetched from DSH history when reachable and is never copied into bridge persistence. This helps the agent understand external reachability and data-hygiene semantics, though failure behavior when history is unreachable is 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?

Two sentences from the core behavior without fluff. The action, the resource, the mechanism, and the key data-handling constraint are all stated efficiently and front-loaded into the first sentence.

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

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

There is no output schema, so the description is responsible for shaping an adequate mental model. It does not explain the meaning of the four parameters, how a cursor should be obtained or advanced, or what a digest structurally contains. The description is useful but not complete enough for a correct invocation beyond trial and error.

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 description coverage is 0%, so the description must compensate for the undocumented parameters. It hints at the 'bounded' nature of maxBytes/maxEvents and at 'cursors' for sinceCursor, but it never maps these concepts to any named parameter or explains their roles. taskId remains completely unaddressed.

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 resource ('bounded event digests'), so an agent knows what the tool does. It also adds the mechanism ('bridge coordination cursors'), though it does not explicitly differentiate it from sibling tools like dsh_observe or dsh_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 explicit guidance on when to use this tool versus alternatives. The phrase 'bounded event digests' implies a history/tail-style use case, but the description never states conditions, exclusions, or which sibling tool might be more appropriate. This is essentially absent guidance.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description's task is lighter here. It adds useful behavior not present in the annotations: the operation is time-bounded to 30 seconds and will not keep waiting until a task completes. It also describes the event categories that trigger a return, which a caller otherwise could not infer from the schema or 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 efficient: one sentence states the core behavior and timeframe, and the second sentence narrows expectations with an explicit negative. The wording is front-loaded so the agent sees the crucial limitations immediately. There is no filler or repetition of available structured metadata.

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, idempotent wait tool with three flat parameters and no output schema, the description covers the main gaps: bounding timeout, trigger conditions, and non-completion behavior. The only shortfall is that it does not say what the tool returns when a timeout or event occurs, but this is largely inferable from a wait tool with a cursor parameter.

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

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

Schema description coverage is 0%, so the description must compensate, but it only partially does. 'At most 30 seconds' maps clearly to timeoutSec, and 'new task cursor' hints at sinceCursor, but taskId is not explicitly described and the cursor mechanics remain vague. The parameter names and schemas are fairly self-explanatory, but the description does not fully replace the missing per-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 clearly states the specific operation: wait at most 30 seconds for a new cursor, status/availability change, terminal state, or pending interaction. It does not just repeat the tool name and it explicitly bounds what it is not doing by saying it never waits for whole-task completion. It avoids naming a sibling tool, but the event categories are precise enough to separate it from status, tail, and observe 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?

The description gives a clear when-to-use context: when the agent needs to wait for cursors, state changes, terminal states, or pending interactions. The phrase 'It never waits for whole-task completion' is an explicit exclusion that prevents misuse. It does not point to a specific alternative tool, but the intended use is reasonably delineated.

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