dsh-baton

Overview Schema Source Related Servers Discussions Admin

dsh_answer

Submits answers to a waiting run's questions—choose options, add text, or skip—then resumes the wait. Use it to relay user decisions or decide as task owner when allowed.

Instructions

Answer the questions a waiting run asked (needs_input in dsh_wait or dsh_status). If the user told you to decide such questions yourself, decide as the task's owner: an option only if it fits as is, else your own words. On a single choice, text replaces the option. Call dsh_answer with a one-sentence reason, then tell the user what you answered and why. Otherwise relay the questions, starting with your advice on its own line: "My recommendation: <an option, or your own answer>, because ", from your own judgment, even outside the options (harness_suggested is only the asker's pick, never a reason). List the options (the user may also answer in words) and submit their decision with dsh_answer. Never answer on the user's behalf without that permission. Per question: choose (option numbers or labels), text (your own answer, complete on its own), or skip. It reaches Harness once every question has an answer (submitted: true; remaining lists the rest); then wait again. If the user already answered in Harness, it says there is no open question.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "answers": "<answers>"
    },
    "name": "dsh_answer"
  }
}

Input Schema

Name	Required	Description
`reason`	No	Required when the user let you decide: one sentence on why you chose this, from your own judgment of the question and the task; it is returned for you to tell the user and not sent to Harness
`run_id`	No	Run id that is waiting (needs_input: answer)
`answers`	Yes	One entry per question answered now
`session_id`	No	Instead of run_id: the session a follow wait (dsh_wait with session_id) reported the question for

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.11Nov 10, 2026
- changedInput schema / properties / answers / items / properties / text / description
```
Previous value: -"Free-text answer"New value: +"Your own answer in words"
```

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / session_id

Added value: +{
+  "description": "Instead of run_id: the session a follow wait (dsh_wait with session_id) reported the question for",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "run_id",
-  "answers"
-]New value: +[
+  "answers"
+]

Addedv0.6.4Oct 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses the commit semantics: it reaches Harness only once every question is answered, reports submitted: true with remaining listing the rest, and then the run waits again. It also discloses that reason is returned to the caller but not sent to Harness, and that harness_suggested is merely the asker's pick and never a justification — none of which is inferable from structured fields.

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

Conciseness3/5

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

The purpose is front-loaded and almost every sentence carries a rule, but the middle is a dense run-on chain of clauses and parentheticals ("...an option only if it fits as is, else your own words. On a single choice, text replaces the option.") that is hard to parse in one pass. It could be broken into a short numbered flow — decide or relay, then submit — without losing content.

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

Completeness5/5

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

For a stateful, multi-question submission tool with no output schema, the description covers what is needed to call it correctly: the trigger conditions, both operating modes, the per-question granularity, the completion signal, the follow-up wait, and the no-open-question edge case.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: reason must be one sentence and is not transmitted to Harness, text on a single-choice question replaces the option and must be complete on its own, and per-question choice is choose/text/skip. It does not restate the run_id vs session_id alternative that the schema already documents, which keeps this just below a 5.

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

Purpose5/5

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

The opening states a specific verb and resource: answer the questions a waiting run asked, and anchors it to the exact state (needs_input in dsh_wait or dsh_status). An agent can immediately tell this apart from dsh_wait, dsh_status, and dsh_send without opening any schema.

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

Usage Guidelines5/5

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

It gives an explicit decision tree: if the user delegated the decision, act as owner and call dsh_answer directly; otherwise relay the question with a recommendation line and submit the user's decision. It also states the prohibition clearly — never answer on the user's behalf without that permission — and notes the already-answered case.

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

Deploy Server