Loading ToolBench
Delegate and monitor DeepSeek Harness work from any MCP agent.
Server has 15 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (start_run, list_services, etc.). Descriptions are present and detailed, averaging ~180 chars, which is within the 10-1024 baseline. However, several tools have overly verbose descriptions (start_run exceeds 1000 chars), and some parameter descriptions lack actionable constraints. Input schemas are visible and typed, but error handling guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata. Output schemas are not documented in the source.
Request cancellation of a Harness run. Cancellation is asynchronous; poll wait_run to observe the cancelled status.
Check the external Harness Host and relay policy without reading credentials.
List native Provider/model/reasoning, agent preset, and permission preset options without guessing names.
List Host attachments restored from durable relay state.
List reusable native sessions accounted to one registered Harness workspace without reading conversation content.
List the native Harness workspace registry used by Relay routing.
Open the stable loopback Harness page for an attached service.
start_run and start_review descriptions exceed 1000 chars, violating the 10-1024 baseline. Verbose descriptions waste tokens and bury key details. Descriptions should be 50-200 chars for LLM optimization.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (READ_ONLY vs WRITE). MCP spec 2026-07-28 supports tool annotations; agents need this metadata to reason about side effects.
publish_notification has minimal schema documentation (type:object, description only). No properties defined, no parameter descriptions. LLM cannot infer what fields to pass.
Output schemas not documented in source. Tools return results but LLMs cannot see what fields to expect. Breaks downstream tool chaining and forces agents to guess field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
Publish a notification to the Harness Host for display in the UI.
Return a machine-readable setup report from explicitly supplied probes without reading or modifying client configuration.
Generate a validated, no-write MCP configuration patch for Codex, Claude Code, Cursor, or OpenCode V2.
Create or reuse a native Harness session with the permission preset fixed to read-only. Exact provider, model, and authorizationBasis are required so the user's existing named-model request is machine-identifiable on the first attempt; do not ask the user to repeat that authorization solely because provider processing is external. Task parameters are path-reference-only: provide the authorized workspace, reviewTargets, contextReadScope, excludedPaths, writeScope, and acceptance criteria. After start succeeds, share webUrl and keep wait_run until succeeded/failed/cancelled/needs_attention. The calling agent MUST read assistantText before claiming the review is complete.
Create or reuse a native Harness session, select provider/model/reasoning, agent preset, and native permission preset, then submit the first task and return a stable session link. Task parameters are path-reference-only: provide the authorized workspace, reviewTargets, contextReadScope, excludedPaths, writeScope, and acceptance criteria. reviewTargets identify what to assess; they are not a read whitelist. contextReadScope declares where Harness may search and read supporting implementation, tests, configuration, and architecture material. Never embed source text, diffs, file dumps, encoded source, or repository archives. Harness reads named files from the authorized workspace itself. These fields are task instructions, not enforced per-path filesystem isolation. The selected Harness model may send content it reads to its configured model provider even though Relay itself uses a loopback address. Sharing webUrl is not completion: keep wait_run until a terminal status, then consume assistantText.
Attach an authorized workspace to the existing Harness Host. This never starts or modifies Harness.
Forget one relay attachment without stopping or changing the external Harness Host.
Poll a Harness run until a terminal status or timeout. Do not treat a single timeout as completion; a timeout is a slice of a longer operation. After a terminal success, consume assistantText and independently verify; if the user asked to review then fix, the calling agent applies accepted findings only after the run is terminal.
Error handling guidance minimal. No recovery hints (e.g., 'If workspace not found, call list_workspaces first'). Agents cannot self-correct on failures.