MCP Client

MCP Client

External tool server integration via the Model Context Protocol.

No dedicated upstream documentation. Package: @deepseek-ai/dsh-mcp-client@0.1.1-rc.2

What Upstream Provides

dsh-mcp-client is a cordis plugin that bridges external MCP (Model Context Protocol) servers into the harness tool system. It connects to MCP servers, discovers their tool catalogs, and registers each tool on ctx.tools — making external tools appear identical to built-in tools from the model's perspective.

• Protocol: built on @modelcontextprotocol/sdk (the official MCP TypeScript SDK).
  • Tool registration: MCP tool descriptions are parsed and registered via the standard ctx.tools.register() API. The upstream dsh-tools package explicitly handles MCP tool description format in its schema parser. Transport: MCP defines two transport types:
    • stdio — the MCP server runs as a child process, communicating over stdin/stdout.
      • Streamable HTTP (formerly HTTP+SSE) — the MCP server is a remote HTTP endpoint, communicating over HTTP requests and Server-Sent Events.

Current Edge State

Not implemented. dsh-mcp-client is not in Edge's dependencies and no MCP-related plugin is installed. External tool servers are not accessible.

Cloudflare Enablers

Transport	Platform	Plan	Feasibility
Streamable HTTP	Workers fetch() — native HTTP client	Free	High — no platform blockers
stdio	Cloudflare Containers — spawn MCP server process	Paid	Medium — needs Container integration
Streamable HTTP is the natural fit for Edge. Many MCP servers already expose HTTP endpoints (database connectors, API wrappers, SaaS integrations). Workers can fetch() these directly. No child processes, no Containers — just HTTP calls from the DO to external MCP servers.

stdio transport would require Cloudflare Containers to spawn the MCP server as a local process. This is the heavier path — only needed for MCP servers that don't offer an HTTP endpoint.

Security Considerations

MCP servers are external — they execute arbitrary tool logic outside Edge's control. This intersects with:

• Approval — MCP tool calls may need user confirmation before execution (currently not implemented, see Approval wiki).
  • Permission Presets — users may want to allow/deny specific MCP servers or tools (currently not implemented).
  • Credential safety — MCP server URLs and auth tokens must follow the same credential safety rules as DEEPSEEK_API_KEY.

Architecture Summary

Component	Category	Status
dsh-mcp-client plugin	Reuse	Not installed — evaluate
HTTP transport	Reuse	Workers fetch() — ready
stdio transport	Replace	Needs Containers (paid)
Tool registration	Reuse	Standard ctx.tools API

Key observation: MCP integration is a plugin install + transport configuration — not an architecture change. The upstream plugin registers MCP tools through the same ctx.tools API as bash, file, and goal tools. The model doesn't know or care whether a tool comes from MCP or a built-in plugin. The main decision is which transport to support and how to manage MCP server configuration (env vars, settings UI, or per-workspace config).

TODO

Evaluate dsh-mcp-client installation with Streamable HTTP transport. Check inject requirements. The plugin may need a transport provider — evaluate whether the upstream HTTP transport works in Workers or needs an Edge adapter. MCP server configuration (URL, auth) could use the existing Settings or Credential provider seams. Available on free plan.