# dsh-mcp-btwy [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/baitouwuya/dsh-mcp-server  
**GitHub Stars:** 5  
**npm Downloads (last month):** 2862  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/dsh-mcp-btwy

## Description
Expose DeepSeek Harness sessions, agents, and tools to any other agent harness over the Model Context Protocol.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "dsh-mcp-btwy": {
    "command": "npx",
    "args": ["-y","dsh-mcp-btwy"]
  }
}
```

## Documentation

## What dsh-mcp-btwy does

dsh-mcp-btwy publishes a Model Context Protocol interface for a running DeepSeek Harness host. External agents can start work in DSH, continue an existing session with its context and workspace, wait for completion, cancel an active turn, and read conversation history.

The interface also exposes session discovery and coordination features. Clients can list sessions with pagination, search for bounded text fragments, and read head, tail, or outline windows with cursors and response budgets. Request inspection surfaces pending approvals and unanswered user questions, while dedicated operations can answer them when those controls are enabled.

A session can ask another session a numbered question and wait for a reply without waking the target session. The server also supports opening a session in the DSH web interface and synchronizing work in the same workspace.

## How it works

The plugin runs inside DSH and forwards MCP calls to DSH services such as its session controller, session query layer, and tools. Clients may connect through Streamable HTTP or stdio. For HTTP, the endpoint publishes a URL and bearer token in `$DSH_HOME/mcp/dsh-mcp-endpoint.json`; the file is created with restrictive permissions.

Long-running calls use an event-stream response after ten seconds. The server sends response headers promptly, emits periodic keep-alive comments, and returns the final JSON-RPC result when the operation finishes. This supports waits that last several minutes without depending on a client’s initial response-header timeout.

Caller identity is derived from request metadata such as headers, MCP `clientInfo`, or User-Agent. Sessions are recorded under that identity, allowing multiple harnesses to use one endpoint. With `restrictToOwner` enabled, callers can access only sessions they created.

## Setup and configuration

Install the `dsh-mcp-btwy` package from the DSH Plugins page or with the DSH plugin command. A source checkout can also be installed through the plugin manager or by supplying its repository path.

After installation, read the generated endpoint file and configure an MCP client with the published URL and bearer token. A typical HTTP connection uses an `Authorization: Bearer <token>` header. The endpoint binds to `127.0.0.1` by default; changing the host is an explicit deployment choice.

The plugin page controls server behavior, including whether the internal tool surface is lazy or full, sidebar grouping, busy-session delivery, progress synchronization, and message presentation. Deployment presets named `delegate`, `strict`, and `observer` can populate fields that have not been set explicitly.

## Tools and capabilities

- Run a prompt and create a DSH session with `dsh_run_prompt`.
- Continue, wait for, cancel, or ask questions of sessions with the corresponding DSH session operations.
- List, search, and window session history instead of returning an unbounded transcript.
- Inspect and answer pending approvals or user questions with request operations.
- Open a selected session in the DSH web GUI.
- Use a lazy three-tool internal entry point—`dsh_mcp_tools`, `dsh_mcp_open`, and `dsh_mcp_call`—or register the full tool surface.
- Deliver inter-session messages and report workspace progress.

## Limitations and notes

The endpoint requires a bearer token for every request and does not accept tokens in URL query parameters. Keep the generated endpoint file protected and connect only harnesses that you trust: calls run against the local DSH installation with the user’s permissions.

Owner restrictions can reject cross-session guest calls. Approval-answering features should be enabled deliberately because delegating approval decisions can grant sandbox permissions. Internal DSH calls remain constrained by the invoking session’s sandbox and workspace.

The plugin is host-side and has no runtime dependencies. Its behavior depends on the DSH service contract rather than importing DSH packages. DSH’s own MCP client can connect to the endpoint, in addition to the plugin’s internal tools.

_Full upstream README: https://allmcps.com/mcp/dsh-mcp-btwy/readme_