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

With no annotations, the description carries the full behavioral burden. It discloses that this is a consequential privilege-escalation gate whose outcome is 'allow' or 'deny' and that neither default is applied automatically, which is useful context. However, it says nothing about what happens to the underlying request after the decision, whether a decision is final/idempotent, or what occurs if approval_id is stale or already resolved.

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: the operation and its trigger condition first, then the rationale. Nothing is padded and the actionable constraint 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?

The call shape is small and fully documented in the schema, and the description covers what the tool is for. For a decision tool with no output schema and no annotations, though, it leaves the agent without any expectation of the result or of failure modes when the approval is missing or already decided.

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 every parameter already carries a description, including the enum on decision and the provenance hints for approval_id (from dsh_get pending_approvals) and conversation_id (from dsh_start or dsh_list). The prose adds no additional parameter semantics, 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 and resource ('裁决一个待决审批' / adjudicate a pending approval) and adds the scoping condition that it only surfaces when the conversation's on_approval=ask. No sibling among dsh_start/dsh_send/dsh_interject handles approvals, so the operation is unambiguous, though the description never explicitly contrasts itself with those siblings.

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

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

Gives a clear triggering context — use it only when on_approval=ask produced a pending escalation — and frames the intent as routing the decision to the caller rather than auto-allowing or auto-denying. It stops short of stating exclusions (e.g. what to do if the approval is no longer pending) or naming any alternative 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?

There are no annotations, so the description carries the full burden, and it does substantial work: it discloses the return payload (title, workspace, permission tier, status, turn count, token usage, context pressure, pending approvals, full turn result). It omits explicit read-only confirmation and any error behavior for invalid ids.

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

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

Front-loaded with the core action; the run_id variant is emphasized before the return-value inventory. Dense but every clause carries information, 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?

No output schema exists, so the description appropriately enumerates the return fields, which is the main missing piece an agent would otherwise lack. Only error/edge-case behavior and an explicit read-only statement are 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 baseline is 3. The description reinforces run_id's meaning as the async verification handle and restates the default-to-latest-turn behavior, but adds little the schema does not already say.

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 ('查看' / retrieve) and resource ('单个会话的详情'), then splits the behavior into two modes (with vs. without run_id). This is clearly distinct from dsh_list (enumeration) and dsh_send (dispatch), though no sibling is named 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?

Gives explicit conditional guidance: with run_id it is the acceptance/verification entry for async dispatches; without run_id it returns the most recent turn. It does not name alternatives (e.g., dsh_list for discovery), but the selection conditions between the two modes are unambiguous.

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

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

With no annotations, the description carries the load well: it discloses that interject cancels the in-flight turn and starts a new one, that history is preserved, and that ACP's no-concurrent-prompt rule makes true mid-turn steering impossible. It omits what the caller actually receives back (the full turn result vs. a background acknowledgement) and any permission/auth expectations.

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

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

Front-loaded with the core definition, then modes, then the ACP caveat that justifies the design. Every clause carries information; the closing note on why true in-turn redirection is impossible preempts a likely agent misconception.

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 mutation tool with no annotations and no output schema, the description covers the semantics and the important side effect (current turn cancelled). The missing piece is return shape — whether interject is synchronous with the reply or returns after handoff, which matters given timeout_ms can push work to the background.

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 both enums are documented inline, so the description's restatement of mode semantics adds little beyond structured data. The one genuinely additive point is the idle-conversation equivalence for mode, but the timeout_ms background-expiry behavior is only 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 opens with a precise verb+resource: injecting a message into a conversation that is mid-turn, and immediately enumerates the two behavioral modes. It implicitly demarcates itself from dsh_send by stating the idle-conversation equivalence, so an agent can place it against siblings without opening the schema.

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

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

Clear conditions are given: use it when a turn is running, pick interject to cancel-and-redirect, pick queue to append after the turn, and fall back to dsh_send when idle. The gap is that it never explicitly contrasts with dsh_interrupt or dsh_takeover, which are the closest competing behaviors for the 'cancel the current turn' case.

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 must carry the full burden, and it does disclose key behavior: it is a cancellation of the current turn, it maps to the native session/cancel path, and the session survives intact and is immediately reusable. It does not say what happens to partial output or whether anything is lost, which keeps it short of a 5.

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

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

Two sentences, front-loaded with the action, with the clarifying mechanism in parentheses and the non-destructive guarantee second. Nothing is wasted and nothing important is buried.

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

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

For a one-parameter mutation-style control tool with no annotations and no output schema, the description covers purpose, mechanism, and the critical after-state. The remaining gap is return behavior and what happens to in-flight partial results, which the agent might want to know.

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 single conversation_id parameter is fully documented in the schema, including where its value comes from (dsh_start or dsh_list). The description adds no further parameter semantics, so the baseline of 3 for high schema coverage 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?

It states a specific verb and resource: interrupting the currently running turn of a session. It also identifies the underlying mechanism (ACP native session/cancel, the same path as pressing stop), which makes the purpose unambiguous and distinguishable from siblings like dsh_interject or dsh_takeover.

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 context for when to use the tool — when the session has a turn in progress that should be stopped — and states the post-condition that new tasks can be dispatched immediately. It does not, however, explicitly contrast this with dsh_interject or dsh_takeover, so the choice among interruption-style siblings still requires inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the two-source data merge (in-memory sessions + not-yet-opened sessions on DSH disk), notes that DSH's session/list excludes already-open sessions, and gives concrete cost figures (~1s disk probe, 10s cache) with the only_running fast path. It omits ordering/pagination and any permission requirements.

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 purpose and state list are front-loaded, then filters, then the next-step pointer. Dense but every sentence carries operational information; the cached-duration detail is slightly more than needed for selection.

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 no annotations exist, yet the description tells the agent what running sessions return (elapsed time, currently executing tool, words produced this turn) and where data originates. Sufficient to call and interpret the result; minor gaps around ordering and result limits.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including their performance tradeoffs. The description adds the state enumeration and the data-merge context useful for interpreting include_closed, but repeats the only_running guidance rather than adding new parameter semantics. 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+resource: list sessions and their run state, with the stated purpose of managing multiple session instances. It defines the state vocabulary (running/idle/detached) so the agent knows exactly what 'run state' means, distinguishing it from siblings like dsh_status or dsh_read.

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

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

Explicitly routes the agent: use only_running=true to see only active sessions, and use dsh_read next to see a session's output. It does not address when to prefer dsh_get/dsh_status over this tool, so it falls short of full alternative coverage.

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

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

With no annotations, the description carries the full burden and does so: the buffer is in-memory, bounded, ring-shaped, drops the oldest entries when full, and disappears when the service/process exits. It also discloses that reasoning is excluded from the buffer unless include_reasoning=true, and that only the currently running turn's reasoning is attached.

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

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

Front-loaded with the core purpose and the cursor/polling model, with buffer caveats after. Dense but every clause carries information; the parenthetical bolding and workflow sentence are slightly heavy but not wasteful.

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

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

Covers the behaviors that determine correct invocation: polling with cursors, bounded retention, and the reasoning flag. With no output schema, it does not describe the shape of returned entries or the cursor field in the response, a minor remaining 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?

Schema coverage is 100%, so the baseline is 3; the description adds genuine meaning beyond it by explaining the cursor round-trip pattern (pass the previous cursor) and the exact semantics of include_reasoning (only the in-flight turn's live reasoning). Limit and conversation_id are left to the schema, which is acceptable at this 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 and resource (read a conversation's runtime output), plus the key qualifier that it is cursor-based incremental. Explicitly frames itself against the alternative workflow of waiting for a turn to finish, so an agent can tell why this tool exists versus dsh_get or a blocking call.

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

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

Gives a concrete step-by-step scenario: run dsh_list(only_running) to find live conversations, then poll dsh_read repeatedly, passing back the previous cursor, to rotate across multiple sessions. That is explicit when-to-use guidance naming the sibling tool to start from.

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

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

With no annotations, the description carries the full burden and does well: it discloses the write-lock release, that the session persists on disk, that forget=true mutates the registry, and quantifies the memory footprint (~300-480MB per session) plus the 'never reclaim' default. It is silent on what happens to in-flight work in a running session at release time and on error behavior for an invalid id.

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?

Each clause earns its place — semantics, persistence, forget, then the all=true memory tip — and the core action is front-loaded before the flags. It is somewhat dense and the ★/quote styling is decorative rather than structural, but nothing is wasted.

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

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

For a 3-param mutation tool with no annotations and no output schema, the description covers the essential decision points: what is destroyed, what survives, and when to use each flag. Missing only edge-case behavior (invalid conversation_id, active-session handling) and return shape.

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

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

Schema coverage is already 100%, so the baseline is 3; the description adds real meaning beyond the schema by explaining the memory rationale for all=true, the 'ignores conversation_id' interaction, and the registry-mutation consequence of forget=true. The interaction semantics (all overrides conversation_id) are the valuable addition.

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 (release the DSH process / write lock held by a session) and immediately clarifies the scope: the session body stays on disk and remains resumable. The distinction between process release, registry removal (forget=true), and mass release (all=true) lets an agent separate this from siblings like dsh_interrupt or dsh_takeover.

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

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

Gives explicit when-to-use guidance for each option: forget=true only when you want the registry entry gone, all=true when you want to reclaim memory all at once, otherwise the session stays resumable. It does not explicitly contrast with dsh_interrupt/dsh_takeover, which would have made the routing unambiguous.

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

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

No annotations exist, so the description carries the full burden and does so: it discloses that a timeout does not error and does not cancel the turn but degrades to background, that results land atomically in a sentinel file, that reasoning is hidden by default with a context-cost warning for `full`, and that a busy conversation produces an error. These are non-obvious failure-mode behaviors an agent could not infer from the 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?

The default non-blocking behavior is correctly front-loaded, but the same point — that timeouts never destroy the task — is made three separate times with heavy bolding, and the result-retrieval mechanics appear twice. Substantial length is spent on emphasis rather than new 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 dispatch tool with no annotations and no output schema, the description covers everything needed: what is returned (run_id + sentinel_file), how to obtain the final result (sentinel file, dsh_get, dsh_read mid-run), default reasoning visibility, and the error path. An agent has no unanswered question before calling it.

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

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

Schema description coverage is 100% and the per-parameter descriptions already cover the wait default, timeout_ms degradation semantics, reasoning levels, and conversation_id provenance. The prose largely restates those same facts rather than adding new meaning, so the baseline 3 applies; the only marginal addition is the cross-parameter framing that timeout_ms matters solely when wait=true.

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 opening sentence names a specific verb and resource (dispatch a task to a conversation) and immediately distinguishes the tool's two modes. It also names the siblings it is not for the busy case (dsh_interject, dsh_interrupt) and the verification path (dsh_get, dsh_read), so an agent can place it in the family without opening other 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?

Explicit when-to-use: default wait=false for fire-and-forget, explicit wait=true to block in place, and a recommended Bash run_in_background + `until [ -f sentinel_file ]` pattern instead of polling. It also states the negative case — if the conversation is busy the tool errors and you should use dsh_interject or dsh_interrupt — which is exactly the alternative routing an agent needs.

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

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

With no annotations provided, the description carries the full burden and discloses significant behavioral traits: the session lives on disk, the process is just cache, and auto-resurrection via ACP session/resume prevents conversation loss. It does not cover failure modes, resource cleanup needs, or auth requirements, but the core persistence behavior is well explained.

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 concise and front-loaded: it opens with the core purpose, then adds relevant behavioral details and next steps in a few short clauses. Every sentence earns its place and there is no wasted text.

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 absence of annotations and an output schema, the description provides a solid overview of what the tool does, its persistence behavior, return values, and next steps. However, it lacks guidance on when not to use it and omits mention of cleanup (e.g., dsh_release) or error handling, leaving minor gaps for full contextual completeness.

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

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

Schema description coverage is 100%, so the schema already fully documents all seven parameters. The description adds no parameter-specific meaning beyond what is in the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('新建') and resource ('DSH 会话'), and distinguishes it from the sibling tool dsh_send by explaining that after creation you use dsh_send to assign tasks. It also clarifies the return values (conversation_id and title), making the tool's purpose immediately 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 gives clear usage context: it is for creating a new session, and it explicitly points to dsh_send for the next step. However, it does not state when not to use it (e.g., for resuming an existing session instead of creating a new one) or mention alternatives like dsh_get or dsh_list, leaving some guidance 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?

No annotations are provided, so the description carries the full burden; it does signal a read-only query and tells what the payload contains, which is the most important behavioral fact here. However, it says nothing about latency, whether the status is cached, or how recently-it-is-fresh the 'recent turn result' is, which matters for an agent polling state.

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 waste — the qualifier '轻量' leads and the returned fields follow immediately. Nothing could be removed without losing 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 output schema, the description usefully enumerates the returned fields, which is exactly the gap it needs to fill for a one-parameter query tool. Only the freshness/latency dimension of the status snapshot is left unstated.

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 only one parameter and schema coverage is 100%; the schema already documents that conversation_id comes from dsh_start or dsh_list. The description adds no further syntax or format guidance, so 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 and resource ('轻量状态查询') and enumerates the exact fields returned (liveness, busy flag, pending approval count, last turn result), which is more precise than the name alone. It does not explicitly contrast with close siblings like dsh_get or dsh_read, so an agent still has to infer the difference.

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 '轻量' implies this is the cheap first-look call, but there is no explicit statement of when to prefer it over dsh_get or dsh_read, and no prerequisites or exclusions. Usage 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?

With no annotations, the description carries the full burden and does so: it discloses that the tool is destructive (kills a process), that killing a holder mid-turn interrupts that turn and marks the log as interrupted while leaving the conversation intact, and that unidentified/GUI holders are never killed. The safety boundary of force=true is also spelled out, which is exactly the kind of context annotations would otherwise supply.

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 numbered case structure (①②③④) is genuinely functional and every clause carries decision-relevant information. It is dense and the long parenthetical in the opening sentence delays the concrete action slightly, so it is not maximally front-loaded, but nothing is redundant.

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, no-annotation, no-output-schema tool, the description covers the mechanism (kernel semaphore, no revoke API), the failure modes (orphan vs. foreign instance vs. unknown holder), the side effects (interrupted turn, intact conversation), and the user-recovery path. An agent has everything needed to invoke it or correctly abstain.

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 both params are already documented, hitting the baseline 3, but the description adds real behavioral meaning for force: it applies only to case ③ (another live dsh-any-agent instance) and has no effect on GUI/unknown holders because those are never killed. conversation_id gains nothing beyond the schema, keeping this below a 5.

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 first sentence states a specific action on a specific resource: seize the conversation's write lock, explaining that the lock is a cross-process kernel semaphore and that the only takeover mechanism is killing the holder process. It explicitly contrasts itself with the ordinary 'resume' path (case ①), so an agent can tell it is an escalation tool rather than the normal way to attach to a session.

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 enumerates four exhaustive situations with explicit decisions: free lock → do nothing and resume; orphaned child of this service → kill and take over; another live dsh-any-agent instance → refuse unless force=true; unidentified holder (likely the user's own DSH GUI) → never kill, report and ask the user to close it. When-to-use, when-not-to-use, and the only override are all stated.

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