ChatGPT–DSH Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| dshCliPath | No | Path to the DeepSeek Harness CLI (dsh.cmd) when it cannot be auto-detected, supplied during installation with -DshCliPath. | |
| allowedRoots | No | Whitelisted project directory for the bridge, supplied during installation with -AllowedRoots. An empty whitelist only allows health checks. | |
| writeModeEnabled | No | Set to "true" in the actually launched bridge instance configuration to enable write mode; it can also be enabled during installation with -EnableWriteMode. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
ChatGPT-DSH Bridge dispatches local coding work to DeepSeek Harness (DSH) headless. Respect three conversation modes: AUTO (default; use DSH only when local execution is actually needed), GPT_ONLY (never call DSH tools), DSH_REQUIRED (plan, dispatch, then review DSH output). Default to read-only. Never request workspace-write without explicit user approval in the current conversation; workspace-write also requires a valid local write grant created by the user. Do not ask the user for a token. Call dsh_health_check before the first task. Start a task, then use bounded wait_seconds calls (at most 6) rather than tight polling. Call dsh_get_result before reporting completion, and review tests and errors. Never claim files changed or tests passed unless DSH output supports it. Do not expose credentials or tokens. Host limitation: local MCP tools may not be available in ordinary ChatGPT Chat. Only claim success after a real tool call returns.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dsh_health_checkA | Check the local DSH CLI, headless profile, DeepSeek account route, local write authorization, and credential-file presence without reading credentials. Set probe=true to make a tiny live DSH model call and verify the model connection. Does not modify files. |
| dsh_start_taskA | Start an asynchronous headless DSH task in an absolute workspace. Permission mode: read-only (default; cannot write) or workspace-write (requires allow_write=true plus a valid local write grant for this exact workspace). The write grant is created locally; no token is sent to the model. danger-full-access is intentionally unavailable. The default is read-only. Use this only when local work is actually needed, not for ordinary conversation. Poll with dsh_get_status/dsh_get_result using wait_seconds instead of tight loops. |
| dsh_get_statusA | Return the bounded status of a DSH task. Set wait_seconds for a short long-poll (maximum 25s) instead of polling rapidly. When terminal is true, call dsh_get_result. |
| dsh_get_resultA | Return the final answer, a bounded test-line summary, errors, usage, and timing for a terminal DSH task. If the task is still running, use wait_seconds (maximum 25s) rather than repeated immediate calls. Review the result before claiming that tests passed. |
| dsh_cancel_taskA | Terminate a running DSH task and its process tree. Cancellation is idempotent: if the task already finished, returns cancelled=false. Only use when the user asks to stop, or when a task is clearly runaway. |
| dsh_list_tasksA | List the bounded set of DSH tasks retained by this MCP server process, newest first. Use to recover a task id; task state is in memory and does not survive a server restart. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool maps to a distinct lifecycle stage (health, start, status, result, cancel, list). The only mild overlap is dsh_get_status vs dsh_get_result, but descriptions clearly separate bounded status polling from retrieving the terminal answer.
All tools use a consistent dsh_ prefix with a predictable verb_noun pattern (health_check, start_task, get_status, get_result, cancel_task, list_tasks). No mixed conventions.
Six tools is well-scoped for an async task bridge, with each tool earning its place across the task lifecycle. Nothing feels redundant or missing at the count level.
Full task lifecycle is covered: health probe, start, poll status, fetch result, cancel, and list. Minor gaps like explicit cleanup/retention management or streaming output are workable given the bounded in-memory task model.