Skip to main content
Glama
Sign In
dsh-baton

dsh-baton

by JialaoLiu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

dsh_send

Send a self-contained task to DeepSeek Harness or continue an existing session, returning a run_id immediately with instructions for waiting for the reply.

Instructions

Hand a task to DeepSeek Harness, or continue a session: returns at once with a run_id and a hint saying how to wait for the reply; follow it. Call it directly, no need to list anything first. A new session starts in the folder this conversation works in, or in cwd or workspace_id (a new cwd is registered first); session_id continues that session. message arrives verbatim as a user message, and Harness does not see this conversation: make it self-contained, in the user's language, the full, explicit spec, asking for tests that cover each requirement. Keep a leading /goal (it sets a Harness goal) and the user's goal text as written. For a large task, write a concrete spec (goal, modules and the files each owns, level of detail, acceptance criteria) rather than passing the user's words on, and send independent parts to separate sessions in parallel, each owning its own files; wait for them together (dsh_wait run_ids), review each as it returns and send its fixes at once. With checks, a short request for a sub-agent review table is appended. To a busy session, mode followup queues the message and steer adds it to the running turn; left out, the Harness setting decides.

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": {
      "message": "<message>"
    },
    "name": "dsh_send"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNoWorkspace folder for a new session; leave out to use the folder this conversation works in
modeNofollowup queues after the current turn; steer injects into a running turn. Omit to follow Harness's busy-send setting
modelNoOnly when the user names a model for this run (e.g. "DeepSeek-V4 Pro", "v4-pro"); leave out otherwise and the session uses its own model, or Harness's default model for a new session. Matched against Harness's model list ignoring case, spaces, hyphens and a leading DeepSeek; a name that matches no model or several fails the send with the list (provider/model picks one). Sets this session only; Harness's default model is left as it was
checksNoThe project's own test commands, e.g. npm test, or python -m pytest (a bare pytest is often not on PATH, on Windows especially); never check scripts you write yourself. dsh-baton runs them in the folder when the run ends and returns exit codes and the last output lines as evidence.
messageYesThe task or reply to send
session_idNoExisting session to continue
workspace_idNoHarness workspace for a new session (from dsh_list_workspaces)
reasoning_effortNoOnly when the user names a reasoning effort, e.g. high; one of the efforts dsh_list_models shows for the model

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / checks / description
      Previous value: -"The project's own test commands, e.g. npm test; never check scripts you write yourself. dsh-baton runs them in the folder when the run ends and returns exit codes and the last output lines as evidence."New value: +"The project's own test commands, e.g. npm test, or python -m pytest (a bare pytest is often not on PATH, on Windows especially); never check scripts you write yourself. dsh-baton runs them in the folder when the run ends and returns exit codes and the last output lines as evidence."
  2. Changed6 schema fields changedv0.6.4
    • addedInput schema / properties / checks
      Added value: +{
+  "description": "The project's own test commands, e.g. npm test; never check scripts you write yourself. dsh-baton runs them in the folder when the run ends and returns exit codes and the last output lines as evidence.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / cwd / description
      Previous value: -"Workspace folder for a new session"New value: +"Workspace folder for a new session; leave out to use the folder this conversation works in"
    • removedInput schema / properties / mode / default
      Removed value: -"followup"
    • changedInput schema / properties / mode / description
      Previous value: -"followup queues after the current turn (default); steer injects into a running turn"New value: +"followup queues after the current turn; steer injects into a running turn. Omit to follow Harness's busy-send setting"
    • addedInput schema / properties / model
      Added value: +{
+  "description": "Only when the user names a model for this run (e.g. \"DeepSeek-V4 Pro\", \"v4-pro\"); leave out otherwise and the session uses its own model, or Harness's default model for a new session. Matched against Harness's model list ignoring case, spaces, hyphens and a leading DeepSeek; a name that matches no model or several fails the send with the list (provider/model picks one). Sets this session only; Harness's default model is left as it was",
+  "type": "string"
+}
    • addedInput schema / properties / reasoning_effort
      Added value: +{
+  "description": "Only when the user names a reasoning effort, e.g. high; one of the efforts dsh_list_models shows for the model",
+  "type": "string"
+}
  3. First observedv0.5.4

TDQS

A4/5.0
Behavior3/5

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

The annotations already declare the operation is a non-read-only, non-idempotent write, so the safety profile is covered. The description still adds substantial behavioral context: the immediate run_id return, the fact that Harness does not see this conversation, verbatim message delivery, cwd registration for new folders, and that checks cause a sub-agent review table to be appended. However, it does not say what happens on failure beyond a model-match error (e.g., how a send fails against a dead session), which is the main gap for a non-idempotent send.

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?

Purpose and return behavior are correctly front-loaded, so the opening is well structured. But the single dense paragraph keeps going into procedural advice about writing specs, parallelism, and review loops, and it restates the mode parameter semantics the schema already documents ("mode followup queues the message and steer adds it to the running turn"). It is informative but overloaded, with duplicated structured data that earns no credit.

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

Completeness4/5

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

With eight parameters, no output schema, and a non-idempotent send, the description carries the right load: it explains the return value (run_id plus a hint and how to follow it), session creation vs. continuation, and the checks/review side effect. What is thin is failure behavior and what a run_id actually yields across dsh_wait, though the description points the agent at the hint for that.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all eight parameters, including mode's enum and the checks/model semantics. The description adds genuine meaning only for message ("arrives verbatim as a user message," must be self-contained, keep a leading /goal), and repeats the mode explanation that the schema already gives. Baseline 3 is right when the schema does most of the work.

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?

Opens with a specific verb+resource pair ("Hand a task to DeepSeek Harness, or continue a session") and immediately states the defining trait that separates it from siblings: it "returns at once with a run_id" rather than blocking, which is exactly what distinguishes it from dsh_wait. The new-session vs. session_id continuation split makes the scope unambiguous.

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?

Explicitly routes the agent: "Call it directly, no need to list anything first," names dsh_wait run_ids as the wait mechanism, and gives concrete when-to-use conditions for parallel sessions ("send independent parts to separate sessions in parallel, each owning its own files") and for busy sessions (mode followup vs. steer). It also tells the agent what to do between sends ("review each as it returns and send its fixes at once").

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

Deploy Server

Other Tools