dsh_delegate

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

It discloses several non-obvious behaviors: the call is detached by default, explicit model selection persists as the DSH default via session.selectModel, and workspaceMode is only a cooperative local claim, not a sandbox verifier. These go beyond the uninformative annotations. The description doesn't say what the call returns, but it still carries substantial transparency burden well.

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 the main purpose and then organized around actionable instructions. It is longer than minimal but each sentence earns its place; the only slight redundancy is repeating that explicit user choices take precedence before explaining session.selectModel persistence.

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 and several complex fields, the description completes most of the Agent's decision loop: what to prepare, how to route, and why workspaceMode is not a sandbox claim. It leaves a small gap by not stating what the call returns or how to coordinate with dsh_wait, dsh_find_sessions, and dsh_attach_session, but those appear as siblings and are inferable.

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 67%, and the description adds meaning beyond the schema for prompt construction, modelProfile routing and precedence, and the workspaceMode caveat. It doesn't elaborate on waitSeconds or the literal return identity, but the most decision-critical parameters are given practical semantic context.

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 clearly states the action: "Create a root session on the configured official DSH Web Host and queue the initial prompt." It identifies a specific verb and resource, and the "root session" phrasing distinguishes it from sibling attach/followup tools that work on existing sessions.

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 pre-call guidance: include a compact handoff with read-only evidence, identify focus paths, and tell DSH to read those first. It also explains when to choose pro versus modlens profiles and when to omit routing fields. It does not explicitly name "use dsh_attach_session instead for existing sessions," but the focus on initial root session makes the intended case clear.

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