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

With no annotations, the description carries the full burden. It usefully discloses a non-obvious side effect — queued messages stay queued rather than being dropped — but says nothing about whether partial output is preserved, error behavior when no turn is running, or permissions required for a state-mutating 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?

Two short sentences, zero filler, with the primary action front-loaded before the queue-behavior caveat. 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?

For a one-parameter tool with no output schema or annotations, the description covers the core action and one important behavioral trait. It stops short of covering failure modes (no running turn) or reversibility, which an agent canceling work would benefit from knowing.

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

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

Schema coverage is 100% and the single sessionId parameter already documents its provenance ('Session id from dsh_open_session or dsh_list_sessions'). The description adds no format or sourcing detail beyond that, so the baseline of 3 applies.

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

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

The description gives a specific verb ('Interrupt') and a precise scope ('the running turn of a Session'), which is unambiguous about what state is affected. It does not, however, name or contrast itself against any sibling like dsh_wait or dsh_read, so sibling differentiation is left to the agent.

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

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

Use case is implied by the verb — interrupt the currently running turn — but there is no explicit guidance on when to cancel versus waiting (dsh_wait) or reading (dsh_read), and no stated preconditions such as whether a turn must actually be running.

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

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

With no annotations, the description carries the full behavioral burden. 'List' strongly implies a safe read, and it discloses that a 'whether a turn runs' state flag is returned, but it says nothing about ordering, pagination, permissions, or scope of the listing beyond 'the running app'. Adequate but thin for a zero-annotation tool.

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

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

A single sentence, properly front-loaded with the action and resource, with the returned fields attached as a compact list. There is no filler, hedging, or redundancy.

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

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

No output schema exists, so the description must describe returns and it does via the field enumeration. Given zero parameters and low complexity this is close to complete; it only lacks details like result ordering or which sessions are in scope when multiple apps run.

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 no parameters, so the baseline is 4. The description adds value by naming the fields in each returned entry (id, title, agent preset, working directory, turn state) rather than leaving the result shape opaque.

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

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

States a specific verb and resource ('List Sessions of the running DeepSeek Harness app') and enumerates the returned fields, which distinguishes it from siblings like dsh_open_session and dsh_read. It does not explicitly name how it differs from the other read-like siblings, which keeps it below 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?

Usage is only implied: listing sessions is naturally the discovery step before dsh_open_session, dsh_send, or dsh_read, but the description never says when to call this versus those tools. No prerequisites, exclusions, or ordering guidance 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the reuse-matching semantics and the override, but says nothing about side effects (does it spawn a process?), failure modes when cwd is invalid, permissions/auth, or whether reopening affects existing sessions.

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

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

Three short sentences, zero waste, with the primary action and default behavior front-loaded before the override instruction.

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

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

No output schema exists, and the description never indicates what opening a Session returns (presumably an identifier an agent needs for dsh_send / dsh_read). For a tool at the entry point of a session workflow, that return-value gap plus missing failure semantics leaves it only partially complete.

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

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

Schema coverage is 100%, so all three parameters are documented. The description adds context only for 'reuse' (matching rule, override), while cwd and preset are essentially restatements of the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Open a Session in the running app'), and the resource is distinct from every sibling (list/send/wait/read/cancel), so an agent can route confidently.

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?

Clearly explains the default behavior (reuse newest idle Session with same preset and cwd) and the condition for opting out ('Set reuse to false for a new Session'). Lacks guidance on when to prefer checking dsh_list_sessions first or what to do when no idle session matches.

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

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

With no annotations, the description carries the full burden. It does usefully disclose content filtering (injected app messages, tool calls, thinking are excluded), which is real behavior beyond the schema, but omits ordering, truncation direction when maxMessages is hit, and whether reads have side effects.

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

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

Two tight sentences, with the primary scope stated first and the exclusions immediately after. No filler or restatement 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 read tool with no output schema or annotations, the description covers content scope and seq-based paging adequately. It leaves result ordering and the semantics of truncation against maxMessages unstated, which is a modest gap for a paginated read.

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

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

Schema description coverage is 100%, including the '-1 for the start' convention and the maxMessages default, so the schema does the heavy lifting. The description adds no parameter-level detail beyond what the schema already states, matching the baseline for full coverage.

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

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

States a specific verb (Read) and precisely scoped resource (caller prompts and assistant text messages of a Session), then narrows it further with explicit content exclusions. An agent can distinguish this from dsh_send/dsh_wait purely from the description.

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 afterSeq-based framing implies a polling/continuation pattern, but the description never says when to prefer this over dsh_wait for new messages, nor does it state prerequisites beyond the schema's sessionId hint. Usage is inferable, not 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?

With no annotations, the description carries the full disclosure burden. It usefully reveals the return payload (afterSeq) and implies a non-blocking enqueue-then-poll model, but says nothing about permissions, failure modes, what happens if the session is mid-turn, or whether queued messages can be retracted.

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

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

Two tight sentences: the action first, then the return value and its downstream use. Every clause carries information an agent needs, with no filler.

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

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

There is no output schema, and the description compensates by naming the key return field and how to consume it, which is exactly the gap that would otherwise exist. Remaining omissions (auth, error behavior, queue-vs-steer selection) are modest for a three-parameter messaging 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 100%, so sessionId, text, and the queue/steer mode semantics are already fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

The description names a specific verb and resource — sending a user message to a Session — which is clearly distinct from the read/wait/cancel siblings. It stops short of explicitly contrasting itself with alternatives (e.g., when to prefer this over dsh_open_session), so it is clear but not fully differentiating.

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 forward context: the returned afterSeq should be handed to dsh_wait and dsh_read 'to see only the new work,' which tells the agent how this tool fits into the workflow. It does not state when-not to use it or how dsh_send relates to dsh_cancel, but the sequencing guidance is concrete.

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

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

With no annotations, the description carries the full burden, and it does disclose the essential blocking behavior and that timeouts terminate the wait. However, it omits what happens on timeout (return current state vs error), whether concurrent waits are allowed, and any rate/long-poll constraints, which are important for a blocking call.

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 short sentence that front-loads the blocking condition and back-loads the timeout fallback. It earns its place, though the phrasing 'ends a turn after afterSeq' is slightly awkward and could be tighter.

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 blocking wait tool with no annotations and no output schema, the description should resolve the biggest ambiguity: what the call returns/does when the timeout fires versus when the turn ends. That distinction, central to correct invocation, is absent.

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

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

Schema coverage is 100%, so all three parameters are already documented in the schema, including that afterSeq comes from dsh_send. The description only echoes afterSeq and adds no syntax or edge-case meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (wait) plus the exact terminating condition (session ends a turn after afterSeq, or timeout). It is distinguishable from siblings like dsh_read/dsh_send, though it never names them or clarifies the read-vs-block distinction explicitly.

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

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

No when-to-use guidance is given: nothing says to prefer this over polling with dsh_read, nor when a caller should skip waiting. The only implicit cue is the term 'wait' itself, which the agent must interpret unaided.

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