Feature: Official Claude Code MCP Server Implementation

[abhinaykrupa]

Problem

External tools (agents, frameworks) wanting to use Claude Code for local execution today must:

1. Build custom bridges — duplicated effort, maintenance burden
2. Use REST APIs — cloud-only, loses repo context, adds latency
3. Integrate separately — inefficient, no standard pattern

This creates fragmentation: every agent framework reimplements "how to use Claude Code locally."

Vision

Make Claude Code the standard for local LLM-powered code execution, similar to how:

• OpenAI models are the standard for inference
• Vector DBs are standard for embeddings

Proposed Solution

Provide:

1. Official MCP Server — standard way for agents to use Claude Code locally
2. Documented Integration Pattern — reference implementation
3. Production Patterns — security, sandboxing, resource limits

Why This Matters

This positions Claude Code as the canonical backend for:

• Local-first agent workflows
• Code generation + validation loops
• On-premise automation

Instead of N custom bridges, there's ONE official pattern that agents adopt.

Reference

The cowork-to-code-bridge project shows what's needed. An official implementation would be:

• More authoritative (Anthropic-backed)
• Better maintained (no community dependency)
• Widely adopted (agent frameworks would integrate it)

This is a strategic investment: makes Claude Code sticky across the entire agent ecosystem.

[Keesan12]

There is definitely a real gap here, but I think the most important part of an official pattern would be the execution contract around it, not just the transport.

If Claude Code becomes the standard local backend, I would want the reference implementation to be opinionated about:

• capability discovery
• sandbox / permission boundaries
• cancellation and timeout semantics
• typed failures (workspace_untrusted, tool_denied, subscription_unavailable, sandbox_blocked)
• receipts for what actually happened during the delegated run

Otherwise every framework still ends up reinventing the safety/runtime layer even if they share the same MCP envelope.

That has been one of the more useful lessons for us with MartinLoop: standard transport helps, but trust really comes from the run being able to explain what it did, what failed, and why another step is or is not justified.

[tangweigang-jpg]

One acceptance criterion I would add is a clear trust-boundary story for the official MCP server.

If Claude Code becomes a local execution backend for other agents, the risky part is not only invoking code generation; it is what the caller can cause it to read, run, or mutate through repo context. I would expect the reference implementation to document at least:

• read-only vs workspace-write vs command-execution modes
• whether repo/project config can alter the launched tool surface
• how approval prompts are preserved when invoked through another agent
• how logs expose the caller, cwd, command, and file diff
• a negative test where a malicious repo instruction tries to escalate permissions

That would make the integration much easier for other frameworks to adopt without each one inventing a different safety model.