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

With no annotations provided, the description carries the full burden and delivers exceptionally. It discloses the transport constraint and exact failure mode (ACP returns UNSUPPORTED_TRANSPORT, never pretends success), the select-side-effect of also attempting to persist a global default (with failure only natively logged, hence not session-only), the status fallback formula (current = projection.next ?? catalog.default), the validation-before-write sequence, and the read-back verified result. No behavioral trait is left hidden.

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?

Every sentence earns its place — there is no filler — and the core purpose plus transport caveat is front-loaded in the first clause. However, it is a single dense multi-clause paragraph in Chinese with nested parentheticals and no bullet or line-break structure, which makes it harder for an agent to parse than its information density justifies. Slightly restructured formatting would earn a 5.

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 real complexity (3 actions, 6 parameters, side effects, fallback logic, transport restrictions) and the absence of both annotations and an output schema, the description is remarkably complete. An agent receives everything needed to invoke correctly: action semantics, parameter constraints, failure modes, side-effect disclosure, and explicit non-behaviors. There is no material 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 operational meaning on top — it maps each action to its parameter set, explains that select validates every id against the live catalog (禁止猜测), and that status accepts either cwd or session_id with an explicit fallback computation. The reasoning_effort defaulting behavior ('不传则由原生选择决定') reinforces the schema. The per-parameter descriptions in the schema already carry the basic semantics, and the description complements rather than repeats them.

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

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

The description opens with a specific verb+resource statement ('原生模型目录与选择' — native model catalog and selection) and precisely defines each of the three actions (list/status/select) with distinct semantics. It also draws scope boundaries against siblings by stating what the tool does not do (does not create/resume/start sessions, does not modify settings.yaml), so an agent can distinguish it from dsh_start/dsh_session/dsh_workspace.

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 per-action routing is given: list for reading the public catalog, status for an existing session's current selection, select for choosing a model on an existing session, with the requirement that target sessions already exist. The description also gives explicit when-not conditions (no session creation/restoration, no settings.yaml changes, web transport only). It stops short of naming sibling tools as named alternatives — e.g., it never says 'use dsh_start to create a session' — so routing relies on exclusions rather than explicit alternatives.

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

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

With no annotations provided, the description carries the full burden and delivers extensively: it discloses auto-start behavior, default cwd session reuse, synchronous pending semantics, progress notification conditions and meaning, approval waiting behavior in web transport, and timeout handling without resubmission. This is exemplary transparency.

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

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

The description is front-loaded with its purpose and every sentence adds important behavioral context, from synchronous semantics to progress notifications and approval handling. It is somewhat long, but the density of critical guidance justifies the length; no sentence feels 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?

Despite having no output schema and no annotations, the description covers all operational aspects an agent needs: sync behavior, polling prohibition, progress notification semantics, approval flow, timeout consequences, and alternative routing. The only minor gap is the exact return payload shape, but '返回最终答复' is sufficient for a task-execution 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 the baseline is 3. The description adds only marginal parameter-related context, such as '默认复用当前 cwd 的会话', which largely restates the existing cwd schema description. It does not materially enhance understanding of parameters beyond what the schema already provides.

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

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

The description opens with a specific verb and resource: '把任务交给 DeepSeek Harness 执行并返回最终答复' – clearly stating it submits a task to DeepSeek Harness and returns the final answer. It also distinguishes itself from siblings by explicitly contrasting with dsh_submit + dsh_job for long-running tasks.

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 explicitly states when to use this tool ('这是一个同步的 tools/call'), what not to do ('不要轮询、不要并发重复提交'), and when to prefer an alternative ('较长或预计耗时不确定的任务优先用 dsh_submit + dsh_job'). This provides clear routing guidance with no ambiguity.

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 of behavioral disclosure and does so exceptionally well. It explicitly promises no directory creation, no implicit session start/resume, cached-view behavior before startup, empty array on no match, full view including native error rows, and the runtime requirement for resume/close. These are concrete behavioral guarantees beyond the basic action names.

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 dense yet efficient: two sentences with no filler. The main verb and resource are front-loaded, followed by edge-case guarantees that an agent needs. Every clause adds value, even though the sentence is information-dense rather than broken into separate sections.

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 annotations and no output schema, the description covers return behavior, side-effect guarantees, filter semantics, and prerequisites remarkably well. The main gap is not addressing the overlapping dsh_status sibling tool or providing more detail on new_session beyond the schema, which leaves slight ambiguity in a sibling-rich context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics by explaining how filter parameters affect results—only existing running/cached rows are filtered, no match yields an empty array, and omitting filters returns the full view. It also clarifies the runtime prerequisite for resume/close. These additions exceed the schema's brief descriptions, though the schema already covers the enum and mutual exclusion.

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

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

The description opens with a specific verb set and resource: 查看/恢复/关闭 DSH 会话 (view/resume/close DSH sessions), and distinguishes list/status from resume/close actions. It is clear what the tool operates on, but it does not explicitly differentiate itself from the sibling dsh_status tool, which could overlap with the status action.

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

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

The description gives concrete usage context: list/status are always answerable and safe, while resume/close require dsh to be running. It also warns that filtering never implicitly starts or resumes sessions and returns empty arrays on no match he. This is clear context, though it does not name sibling alternatives such as dsh_start or dsh_status, so explicit when-not-to-use routing is missing.

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 an excellent job: it discloses idempotency, subprocess management for web mode, token-to-cookie handling, browser opening, URL safety warnings, and failure/retry behavior. This goes well beyond what the schema or annotations provide.

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

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

The description is dense but every clause adds value; it is front-loaded with the core action and idempotency. It would benefit from structured separation of the transport modes and return-value notes, but it is not padded or 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?

Despite lacking an output schema and annotations, the description covers the important runtime context: return fields, absence of token in web_url, port ambiguity, browser behavior, and retry safety. This is sufficient for an agent to invoke the tool and interpret the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that open_browser only applies in web mode, defaults to true, and opens at most once per start. This gives the parameter operational 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 the action ('显式启动/连接本机 DSH 并完成握手') and the resource (DSH), and adds the idempotency property. It does not explicitly differentiate itself from sibling tools like dsh_run or dsh_status, so it stops short of the 5-level sibling distinction.

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

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

The description gives clear context for two operational modes (transport=acp and transport=web) and explains the open_browser behavior in web mode. It does not explicitly say when to avoid this tool or when a sibling tool would be more appropriate, so it lacks explicit exclusion 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by explicitly stating the tool is read-only, will not implicitly start dsh, and explaining the state semantics (running/state distinguishes stopped/starting/running/error; ok=true means healthy, false when not started). It also discloses what additional information is preserved (binary, version, active session count, session capabilities, config source). This is strong behavioral transparency for a status 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?

The description is a single sentence that packs in the key behavioral facts: read-only, no implicit start, state values, ok semantics, and preserved fields. It's front-loaded with the most important information (read-only, no start). It's slightly dense with the list of preserved fields, but each element earns its place by helping the agent understand what the status output contains.

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 status tool with no output schema, the description is quite complete. It explains the state machine (stopped/starting/running/error), the health flag semantics, and what data is preserved. The only minor gap is that it doesn't describe the exact output format or structure, but for a status tool this is acceptable given the description already covers the key semantics.

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

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

The tool has zero parameters, so the schema provides no parameter information. The description doesn't need to explain parameters, but it does explain what the tool reports (state, ok flag, binary, version, session count, capabilities, config source), which gives the agent a sense of what the output will contain. With 0 params, the baseline is 4, and the description adds value by describing the output semantics.

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

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

The description clearly identifies this as a read-only status tool for the DeepSeek Harness bridge, and explicitly states it will not implicitly start dsh. It distinguishes itself from sibling tools like dsh_start and dsh_run by emphasizing the read-only nature and the no-start guarantee. However, it doesn't explicitly name a sibling alternative, so it gets a 4 rather than a 5.

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

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

The description provides clear context for when to use this tool: when you need status information without side effects. The explicit statement '不会隐式启动 dsh' (will not implicitly start dsh) serves as a usage guideline, telling the agent this is safe to call for status checks. It doesn't explicitly say 'use dsh_start instead when you need to start it,' but the contrast with siblings is implied through the read-only framing.

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 full burden. It discloses key behaviors: never overwrites existing files, safe reuse, auto-start/connect, and web-transport-specific workspace creation. It also details return fields, providing transparent 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?

The description is a single well-organized paragraph that front-loads the core purpose and then details behaviors and returns. Every sentence adds value, 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?

The description covers the main return values and behavioral nuances, including web transport specifics. It doesn't mention error conditions or prerequisites, but given the tool's complexity and lack of output schema, it provides sufficient context for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reiterates the absolute path requirement and open_browser's web-mode control but doesn't add substantive new meaning beyond 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 the tool's function: create or reuse a DSH session for a given directory, with explicit behaviors like directory creation, safe reuse, and no overwriting. It distinguishes itself from siblings like dsh_start (service startup) and dsh_session (session management) by focusing on workspace establishment.

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 for establishing/reusing a workspace, but it doesn't explicitly compare with sibling tools or state when NOT to use it. It mentions auto-starting DSH when necessary, but gives no guidance on choosing this over dsh_start or dsh_session.

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