feat(mcp): bridge runtime-added MCP tools into the core tool registry

[paperview]

Issue for this PR

Follow-up to #37678 (comment thread). Fixes the runtime MCP feature
(#37308) for the primary user-facing prompt path.

Type of change

• Bug fix
• New feature

What does this PR do?

The daemon has two independent MCP services:

• @opencode/MCP (packages/opencode/src/mcp) — target of the runtime POST /mcp endpoint added in feat(core): add runtime MCP controls #37308. Used by SessionPrompt.prompt (the direct v2 /session/:id/message and /session/:id/prompt_async endpoints).
• @opencode/v2/MCP (packages/core/src/mcp) — the service the v2 SessionRunner reads tools from via ToolRegistry.materialize. Only populated from static config files at layer construction.

They live in different Effect layer graphs (opencode's server app graph vs. the locationServices graph) so bridging them at the Effect service level requires a large layer-plumbing refactor — several unrelated deps (Location, Form, Integration, Credential) would need to enter the server graph. As a result, tools added via the runtime /mcp endpoint were invisible to the v2 SessionRunner — the primary user-facing prompt path — and the runtime MCP feature was effectively broken for MCP-mediated conversation flows.

This PR bridges them via a small in-process registry:

• Add a module-level Runtime map + RuntimeToolEntry shape to the existing core reconciler (packages/core/src/tool/mcp.ts). The reconcile function now iterates bothmcp.tools() and Runtime.list(), wrapping each runtime entry into a Tool.make with a promise-based execute that calls back into the opencode-side MCP client via an injected closure. Same permission/output shape as MCP-service-sourced tools.
• In the opencode-side MCP service (packages/opencode/src/mcp), after storeClient succeeds (or the ToolListChanged notification fires), call McpTool.Runtime.set(server, tools) with a wrapped client.callTool execute. On client.onclose, call McpTool.Runtime.remove(server).
• The existing McpEvent.ToolsChanged event (already published by the opencode side) triggers the core reconcile which re-scans both sources, so runtime-added tools become visible to the SessionRunner on the next event fire.

Not a service-level bridge (which would require the layer-graph plumbing above) — a shared in-process registry, which the two independent Effect service instances both read/write. This is intentional: it's a smaller, contained diff that unblocks the primary user-facing path today and can be replaced with a proper unified MCP service later if maintainers prefer.

How did you verify your code works?

Full end-to-end via an external orchestrator (a sync_server chatbot bridge, Kimi K3 via kimi-for-coding/k3):

1. Orchestrator: POST /mcp?directory=<sync_dir> with {name: \"sync-bot-65\", config: {type: \"remote\", url: \".../mcp/chatbot/65?turn_token=...\"}} → daemon connects, fetches tools/list, stores update_field in s.defs[\"sync-bot-65\"] and calls McpTool.Runtime.set.
2. Orchestrator: creates a session (POST /session?directory=<sync_dir>), sets model to kimi-for-coding/k3, posts a user prompt.
3. Runner: SessionModelRequest.prepare builds the LLM request with sync-bot-65_update_field in the tools list — because ToolRegistry.materialize sees it via Tools.Service.register from the bridged reconcile.
4. Kimi K3 invokes the tool (method: \"tools/call\", params: {name: \"update_field\", arguments: {field: \"favorite_color\", value: \"blue\"}}).
5. The orchestrator's MCP endpoint receives the call, applies the mutation, and downstream state reflects it.

Before this PR: Kimi's assistant response was "I don't have an update_field tool available in my toolset" — the tool never reached the LLM request. After: Kimi calls it correctly.

Typecheck clean: bun turbo typecheck --filter=@opencode-ai/schema --filter=@opencode-ai/core --filter=opencode.

Scope / not addressed

• Static config-file MCP entries continue to flow through the core @opencode/v2/MCP.tools() path unchanged.
• Prompts and resources on the runtime side are not bridged — this PR is tools-only, since that's the SessionRunner's read path. Bridging prompts/resources would follow the same pattern.
• Per-turn toolChoice for the legacy /api/session/:id/prompt endpoint (which goes through SessionPending → SessionRunner) is still hard-coded at packages/core/src/session/model-request.ts:90. That's a separate wiring effort — see the follow-up call-out in feat(session): expose toolChoice via PromptInput and agent config #37678.

Related

• toolChoice unwired at v2 HEAD — Kimi K3 skips MCP tool calls under default "auto" #37672 — consolidation issue that flagged this alongside the toolChoice split.
• feat(session): expose toolChoice via PromptInput and agent config #37678 — my toolChoice patch (direct-endpoint half).
• feat(core): add runtime MCP controls #37308 — the runtime MCP endpoint that this PR unblocks for the primary prompt path.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally (end-to-end via external MCP orchestrator + Kimi K3)
• I have not included unrelated changes in this PR

[paperview]

Stacking note: this PR's branch is currently stacked on top of #37678 for local verification. If maintainers prefer, I can rebase off dev and drop the toolChoice commit — or land #37678 first and this rebases cleanly.

Rebase caveat:dev moved a packages/core/src/tool/mcp.ts refactor after I branched. A rebase will need a light manual resolve on that file; the bridge lives at the same call sites so the resolve should be straightforward.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.