cordis.yml builder
Configure one MCP server
Configuration fields are valid.
Both documented transport paths now have a direct test
The fixture deliberately used deterministic local echo Tools so registration, schema, calls, headers, failure, cleanup, and recovery could be separated from model behavior and external network conditions.
Retained lab record
MCP Tools over stdio and Streamable HTTP
- Client
- DSH 0.1.0-rc.7 · MCP SDK 1.30.0
- Runtime
- Windows 11 · Node v24.11.1 · isolated DSH profile
- Servers
- Deterministic local echo fixtures over stdio and localhost HTTP
- Credentials
- No API key, model call, external provider, or real secret
Where this entry belongs
The official MCP client bridge uses one plugin instance per MCP server in cordis.yml. It registers each server Tool under a qualified name such as mcp__github__create_issue. Server names must be unique across live instances.
What the generator validates
| Field | Boundary |
|---|---|
| serverName | Required for both transports; 1–32 characters matching letters, numbers, underscore, or hyphen. |
| command / args / env | stdio process and environment references. |
| url / headers | Streamable HTTP endpoint and optional authentication headers. |
| toolCallTimeoutMs | Per-tool timeout; official default is 60,000 ms. |
| reconnect | Automatic reconnect, delay backoff, and attempt budget. |
Current MCP bridge limitations
- Tools only: Resources and Prompts are not bridged.
- Schema cost: discovered Tool definitions consume context on each request while registered.
- Cache stability: unchanged tools stay prefix-stable; a changed tool set or schema can invalidate reuse from the first changed token.
- Non-text rendering: images, audio, resources, and unsupported blocks become placeholders in native model context even though canonical execution data retains JSON blocks.
- Startup timeout: connection/discovery currently inherits the MCP SDK’s 60-second request default.
Visual context for the two transport branches
The embedded segment demonstrates stdio and Streamable HTTP inside a custom MCP Apps plugin. It is useful for architecture context; the built-in bridge generator and compatibility result above remain tied to official documentation and direct tests.
YouTube · community observed
Custom MCP bridge transport branches
Demonstrates stdio and Streamable HTTP branches inside a custom MCP Apps bridge.
Boundary: Useful visual context, but not a standalone tutorial for the built-in DSH MCP Client Bridge. The generator fields and transport claims come from the official README and our direct tests.
Open the cited segment on YouTube ↗Provenance ledger
Evidence sources used on this page
- Official Official MCP Client Bridge README ↗
stdio and Streamable HTTP configuration, namespacing, reconnect behavior, and Tools-only boundary.
- Direct test HarnessBase MCP end-to-end test
Deterministic local stdio and Streamable HTTP echo fixtures on DSH 0.1.0-rc.7 and MCP SDK 1.30.0.
- Official Official DeepSeek Harness repository ↗
Canonical identity, quick start, Developer Preview status, source workflow, and plugin architecture.
- Community 01Coder MCP plugin segment ↗
Visual custom-bridge example for stdio and Streamable HTTP; not the authority for built-in bridge fields.