Python runtime wheel cannot resolve the first-party MCP client

[Cookie-HOO]

Summary

deepseek-harness-sdk==0.1.0rc6 supports caller-provided Cordis configurations, but the published macOS arm64 runtime wheel cannot resolve the repository's documented @deepseek-ai/dsh-mcp-client plugin. The plugin is absent from the dependency closure compiled into the single-file runtime.

This prevents Python SDK users from using a custom authenticated Streamable HTTP MCP server with the published runtime.

Environment and artifact

• SDK: deepseek-harness-sdk==0.1.0rc6
• Runtime: deepseek-harness-runtime-bin==0.1.0rc6
• Official wheel: deepseek_harness_runtime_bin-0.1.0rc6-py3-none-macosx_14_0_arm64.whl
• Official wheel SHA-256: 2bbd65edd52dfc340d74f88a890e8031a272a820e58406c2de1f5f5dee51bd9f
• macOS arm64
• Python SDK guide: https://deepseek-harness.github.io/deepseek-harness/guide/python-sdk

Minimal reproduction

Use the published SDK and Runtime wheels, then provide this Cordis configuration through DeepSeekHarness(cordis=...):

- id: sdk-jsonrpc-server
  name: '@deepseek-ai/dsh-sdk-jsonrpc-server'
- id: agent-core
  name: '@deepseek-ai/dsh-agent-spine-demo'
  config:
    workspaceContext: false
- id: mcp-streamable-http
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: example
    transport: streamable-http
    url: http://127.0.0.1:12345/mcp
    headers:
      Authorization: Bearer test-token
    failOnStartupError: true

Starting the Harness fails before MCP transport negotiation with module-resolution behavior equivalent to:

ERR_MODULE_NOT_FOUND: Cannot find package '@deepseek-ai/dsh-mcp-client'

The same packaged runtime correctly rejects an intentionally nonexistent plugin, confirming that the custom Cordis configuration is being loaded and that this is a deployment-closure omission rather than a configuration-path issue.

Root cause

python/sdk-runtime/package.json is the deployment root used to form the production runtime closure. It includes the other runtime plugins but not @deepseek-ai/dsh-mcp-client. Because the wheel carries a closed single-file executable rather than a production node_modules tree, users cannot install or place the missing package beside the executable as a supported workaround.

Expected behavior

A caller-provided Cordis composition using the repository's first-party MCP client should be resolvable by the published Python Runtime wheel. On startup it should be able to complete authenticated Streamable HTTP:

1. initialize
2. notifications/initialized
3. tools/list

No model request should be required to verify this path.

Suggested minimal fix

Add the first-party MCP client to the Runtime deployment root:

 "@deepseek-ai/dsh-llm-retry": "workspace:^",
+"@deepseek-ai/dsh-mcp-client": "workspace:^",
 "@deepseek-ai/dsh-output-retention": "workspace:^",

A useful regression test is to start the actual packaged carrier with a loopback, bearer-authenticated Streamable HTTP MCP fixture and assert the three lifecycle methods above. The default bundled Cordis configuration does not need to enable MCP.

Temporary compatibility demonstration

I created a minimal public compatibility fork and macOS arm64 wheel to verify the fix:

• Commit: Cookie-HOO@b52844d
• Release: https://github.com/Cookie-HOO/deepseek-harness/releases/tag/dumpflow-mcp-runtime-v0.1.0rc6.1

The rebuilt packaged executable completed the authenticated MCP lifecycle and tool discovery without a model call. The fork is unofficial, not published to PyPI, and intended to be retired as soon as an official Runtime wheel contains the MCP client.

Source provenance note

The current public source checkout reports 0.1.0-rc.5, while the official Python artifacts are 0.1.0rc6; I could not find a matching public rc6 source tag or commit. The compatibility release documents that limitation and should not be interpreted as an official rc6 rebuild.

[kunwar-vp]

Same root cause as #1240 — the runtime closure omits dsh-mcp-client, so the shipped wheel can't serve any MCP-carrying composition. Verified the one-line manifest fix works end to end (details in #2273). Worth consolidating votes on #1240 since it names the exact change.

[zoahdev]

This is the same deploy-root omission as #2273 — a branch already exists with the exact one-line fix.

• Branch: zoahdev/deepseek-harness@fix/sdk-runtime-mcp-client-closure (cherry-pick-ready against 47f943859b)
• python/sdk-runtime/package.json: @deepseek-ai/dsh-mcp-client: workspace:^ added (with the lockfile), exactly the diff this thread proposes.
• Verified: verify-runtime-closure passes (110 workspace packages, closed graph).

Cross-refs: #2273 / #1240 / #2115 all report the same dsh-mcp-client missing from the runtime closure; this one branch closes all three. A composition that doesn't reference it pays nothing, and one that does now boots on the bundled carrier.