Allows using Ollama-hosted local models (e.g., qwen2.5-coder) as the backend for autonomous coding tasks and dual-agent verification.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dsh-agent-mcp Migrate the login form from MUI to shadcn and verify with tests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server connecting Google Antigravity, Claude Code, and Cursor to DeepSeek Harness (
@deepseek-ai/dsh) for $0-cost autonomous coding and dual-agent verification.
Frontier LLMs (Gemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o) are phenomenal system architects, but using them to generate hundreds of lines of repetitive boilerplate, mechanical refactors, and test iteration code is:
Expensive: Burns significant paid API tokens.
Prone to Hallucinated Regressions: Without an independent verification loop, self-auditing often misses edge cases.
DSH-Agent-MCP turns your primary AI into a Lead Architect and delegates mechanical implementation to DeepSeek Harness running on your local or free model cluster (Ollama, vLLM, FreeToken, LM Studio), followed by an independent Reviewer Agent before any task is marked complete.
sequenceDiagram
autonumber
actor User
participant Architect as Primary AI (Antigravity / Claude / Cursor)
participant Worker as Agent 1: Task Completion Worker (DSH)
participant Cluster as Local / Free LLM (Ollama / vLLM / Qwen)
participant Reviewer as Agent 2: Reviewer & QA Verifier
User->>Architect: "Migrate Form.tsx from MUI to shadcn"
Note over Architect: Formulates concise intent brief.<br/>DOES NOT write replacement code.
Architect->>Worker: invoke_subagent / dsh_run_task(brief)
Worker->>Cluster: Autonomous AST analysis, edits & build verification
Cluster-->>Worker: Modified files + git diff + build status
Worker-->>Architect: Completion report & git diff
Architect->>Reviewer: invoke_subagent(diff, brief, test_cmd)
Note over Reviewer: Independently inspects diff,<br/>checks regressions & re-runs test suite.
Reviewer-->>Architect: [CONFIRMED / APPROVED]
Architect-->>User: Delivers completed, verified taskRelated MCP server: Multi Agent MCP
Node.js ≥ 20.0.0
A local or remote model endpoint (e.g., Ollama running qwen2.5-coder:32b, qwen3.8:27b, or deepseek-coder-v2).
Add to your mcp_config.json (~/.gemini/config/mcp_config.json):
{
"mcpServers": {
"dsh": {
"command": "npx",
"args": ["-y", "dsh-agent-mcp"],
"env": {
"DSH_BACKEND_TYPE": "ollama",
"DSH_MODEL_ENDPOINT": "http://localhost:11434/v1",
"DSH_MODEL": "qwen2.5-coder:32b"
}
}
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"dsh": {
"command": "npx",
"args": ["-y", "dsh-agent-mcp"],
"env": {
"DSH_BACKEND_TYPE": "ollama",
"DSH_MODEL_ENDPOINT": "http://localhost:11434/v1",
"DSH_MODEL": "qwen2.5-coder:32b"
}
}
}
}Add to .cursor/mcp.json in your workspace:
{
"mcpServers": {
"dsh": {
"command": "npx",
"args": ["-y", "dsh-agent-mcp"],
"env": {
"DSH_BACKEND_TYPE": "ollama",
"DSH_MODEL_ENDPOINT": "http://localhost:11434/v1",
"DSH_MODEL": "qwen2.5-coder:32b"
}
}
}
}Tool | Description |
| Dispatches an autonomous coding task to DeepSeek Harness in headless mode with git diff calculation and real-time activity tracking. |
| Checks DSH installation, endpoint connectivity, latency, settings, and Web UI status. |
| Checks if the official DSH Web UI companion is running on port 3080. |
| Spawns the DSH Web UI companion in background daemon mode ( |
| Terminates the running DSH Web UI companion process. |
| Discovers and inspects previous session histories stored in |
dsh-liveFor interactive or visible streaming directly in your integrated terminal:
# Stream live thinking tokens, tool calls, and syntax-highlighted markdown
dsh-live --cwd "/path/to/project" "Refactor auth middleware to use JWT and verify with npm test"Backend | Example Config | Default Endpoint |
Ollama |
|
|
vLLM / SGLang |
|
|
LM Studio |
|
|
FreeToken Cluster |
|
|
DeepSeek Official API |
|
|
To maximize autonomous reasoning and eliminate token waste, follow this simple protocol:
Replace lines 135-255 of Form.tsx with:
<Dialog open={open}>
... 150 lines of frontier LLM pre-written code ...
</Dialog>Task for src/components/Form.tsx:
1. Migrate the component modal and selects from MUI to shadcn/ui.
2. Maintain existing form state, submit handlers, and validation logic.
3. Replace MUI sx styling with Tailwind CSS utility classes.
4. Verify by running 'npm test'.This repository includes copy-paste templates in the integrations/ folder:
integrations/antigravity/: Subagent definitions (dsh-worker.md, reviewer-worker.md) and dual-agent rules.
integrations/claude/: CLAUDE.md and desktop config.
integrations/cursor/: .cursorrules and mcp.json.
integrations/cline/: cline_mcp_settings.json.
MIT © 2026 Eklavya
Health-check the DeepSeek Harness setup. Checks DSH binary installation, ~/.dsh/settings.yaml configuration, model endpoint connectivity, and Web UI status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly lists what the tool checks and implies a read-only diagnostic nature. It stops short of stating side effects or output behavior, but for a health-check tool the listed scope is meaningful.
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?
A single sentence that front-loads the action and then usefully enumerates the check scope. Every element contributes information, with no filler or redundancy.
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 diagnostic tool with no output schema, the description gives enough context to select and invoke it correctly. It does not describe the format of the health-check result, which would be useful but is not essential for tool selection.
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 is inherently complete. There is no parameter semantics burden for the description to carry, and the baseline of 4 applies.
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 starts with a clear verb, 'Health-check', and names the specific resource, 'DeepSeek Harness setup'. It enumerates the exact components checked (binary installation, settings.yaml, model endpoint connectivity, Web UI status), which distinguishes it from narrower siblings like dsh_web_status.
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?
No guidance is given on when to use this tool versus alternatives. The agent must infer that this is the general diagnostic entry point, and the description does not explicitly distinguish it from dsh_web_status or say when a narrower sibling would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover and list existing DeepSeek Harness sessions stored in ~/.dsh/sessions/, sorted by most recent.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | Optional filter to match workspace path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the storage location and sorting order, which is useful. However, it doesn't mention whether the tool is read-only, whether it can fail (e.g., no sessions exist), or what the output format looks like. For a list operation, the safety profile is fairly obvious, but the description could add more context about edge cases.
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-structured sentence that front-loads the core purpose and includes the key details (location, sorting). Every word earns its place, and there is no redundancy or 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?
For a simple list tool with one optional parameter and no output schema, the description is mostly complete. It covers what the tool does, where it looks, and how results are ordered. The only minor gap is that it doesn't describe the return format or behavior when no sessions exist, but these are relatively minor for a discovery 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?
The schema description coverage is 100%, so the single parameter 'workspace' is already documented in the schema. The description adds the context that the workspace is an optional filter, but it doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose: discovering and listing existing DeepSeek Harness sessions, with a specific location (~/.dsh/sessions/) and sorting behavior (most recent). This distinguishes it from sibling tools like dsh_run_task or dsh_web_status, which have different verbs and resources.
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 context: it's for discovering existing sessions, which is distinct from running tasks or managing web services. However, it doesn't explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear enough for an agent to infer, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatch an autonomous coding task to DeepSeek Harness in headless mode using the configured local/free model. The worker operates directly on the specified repository, reasons autonomously, creates/edits files, executes bash commands, tracks git diffs, and returns structured execution results with zero front-end token burn.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute path to the repository/directory the worker should operate in. | |
| task | Yes | Clear, explicit instructions for the task: files to edit/create, requirements, constraints, and test commands. | |
| verbose | No | Whether to include full raw stdout/stderr in the response (default: false). | |
| timeoutMs | No | Max execution time in milliseconds (default: 1800000 = 30 minutes). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that the worker mutates the repository, creates/edits files, executes bash commands, tracks git diffs, and returns structured results. It stops short of noting risks, permissions, or reversibility, but the core behavioral traits are explicit.
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 one dense, front-loaded sentence that starts with the action and resource, then packs in the behavioral details without redundancy. It is efficient, though a slight structural split would improve scannability.
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 complex mutation tool with no output schema and no annotations, the description covers the critical operational aspects: mode, target repo, autonomy, side effects, and result type. It leaves some return-format details vague ('structured execution results') and does not mention timeout/failure behavior, but the main agent-relevant context is present.
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 all four parameters well. The description adds general context about what the task worker can do, but it does not add per-parameter meaning beyond what the input schema 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 uses a specific verb ('Dispatch') and names the exact resource: an autonomous coding task to DeepSeek Harness in headless mode. It also enumerates observable effects (creates/edits files, executes bash commands, tracks git diffs) that clearly set it apart from the sibling status/management tools.
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 intended use case is clear: run autonomous coding tasks against a repository in headless mode. However, the description never explicitly states when to use this tool versus alternatives or when not to use it, leaving the distinction from sibling tools implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the DeepSeek Harness Web UI companion in background daemon mode on port 3080 (http://127.0.0.1:3080).
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port to bind (default: 3080). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds useful context: background daemon mode and the exact URL/port. However, it does not disclose what happens on startup failure, whether the command is idempotent, or whether it returns immediately (though daemon mode implies it). This is more than a bare 'start' but leaves important behavioral gaps.
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?
A single sentence that front-loads the action, mode, and address. No filler, every phrase earns its place. The URL is included as a compact operational detail.
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 tool's low complexity (one optional parameter, no output schema, no annotations), the description is largely sufficient for correct invocation. It covers purpose, mode, and endpoint. The main missing piece is usage guidance, but that was already scored in its own dimension; for the given complexity, the description is mostly complete.
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% for the single optional 'port' parameter, which already documents the default (3080). The description mentions port 3080 but adds no new semantics beyond the schema. Per calibration, baseline 3 is appropriate.
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 states a specific verb ('Start'), a clear resource ('DeepSeek Harness Web UI companion'), and precise operational details (background daemon mode, port 3080, URL). This distinguishes it from siblings like dsh_web_status, dsh_web_stop, and dsh_run_task without requiring schema inspection.
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 does not provide explicit guidance on when to use this tool versus alternatives like dsh_web_status or dsh_web_stop. It implies usage (start the UI) but offers no exclusions, prerequisites, or mentions of sibling tools. An agent must infer when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the DeepSeek Harness Web UI is currently running on port 3080, and list active sessions count.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port to check (default: 3080). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read-only status check, but it does not explicitly state that the tool has no side effects, nor does it describe what happens when the Web UI is down or how errors are reported.
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 front-loads the main purpose, includes the relevant port, and mentions the session count. Every part contributes useful information without redundancy.
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 tool is simple and the single optional parameter is already documented, but there is no output schema and the description does not specify the return format, such as a boolean plus count. Given the low complexity, this is adequate but leaves some ambiguity about the exact result structure.
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 schema covers 100% of the parameter, including the default port value. The description adds no additional semantic detail beyond what the schema already provides, so it meets the baseline but does not exceed it.
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 states a clear verb and resource: checking whether the DeepSeek Harness Web UI is running on port 3080 and getting an active session count. This distinguishes it from sibling tools like dsh_web_start and dsh_web_stop, though the phrase "list active sessions count" is slightly awkward and could be interpreted as either listing sessions or returning a count.
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 no explicit guidance about when to use this tool versus alternatives. There is no mention of dsh_list_sessions for detailed session inspection, or dsh_web_start/stop for lifecycle management, so the agent must infer selection purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the running DeepSeek Harness Web UI companion process on port 3080.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port to terminate (default: 3080). |
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 explicitly names the affected resource and what happens to it ('Stop the running process'), including the port. It could add more detail about error cases or forceful termination, but for a simple stop operation the core behavior is transparent.
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 clear sentence with no filler. The verb and main action are front-loaded, and every word contributes useful information.
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 simple one-parameter utility tool, the description covers what, where, and the target port. It does not explain return values or behavior when no process is running, but those are minor gaps given the tool's simplicity and the lack of an output schema.
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%: the port parameter is already documented with its default value. The description mentions port 3080 but does not add new semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Stop') with a specific resource ('running DeepSeek Harness Web UI companion process on port 3080'). This clearly distinguishes it from sibling tools like dsh_web_start and dsh_web_status, leaving no ambiguity about what the tool does.
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: use it to stop the running Web UI companion process on port 3080. It does not explicitly name alternatives or state when not to use it, so it is not a perfect 5, but the intended usage is evident from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0dsh_doctordsh_list_sessionsdsh_run_taskdsh_web_startdsh_web_statusdsh_web_stopScored across 6 tools
Each tool targets a distinct concern: running tasks, checking setup health, checking/starting/stopping the web UI, and listing sessions. There is no meaningful overlap, and descriptions make the boundaries clear.
All tools share the 'dsh_' prefix and mostly follow verb_noun (run_task, list_sessions) or web_verb patterns (web_start, web_stop, web_status). 'dsh_doctor' is the only outlier, being a noun rather than a verb phrase, but it is still readable and intuitive.
Six tools is well-scoped for an agent-management server: one primary action, three for web UI lifecycle, one health check, and one session discovery. No tool feels redundant or missing as a lightweight utility.
The core workflows are covered: run a task, check health, manage the web UI, and list sessions. Minor gaps exist (e.g., no session termination or task cancellation), but these are not obvious dead ends for the server's stated purpose.
Build, deploy, and sell AI agents for local-service businesses - from your IDE.
Zero-Ops deploy of a private AI workspace to your own VPS — from your AI chat. Free and open-source.
Local-first, governed memory and session continuity for AI coding agents. No cloud, no telemetry.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
