Claude Code MCP 深入解析（8）：由 MCP 客戶端轉為 MCP 伺服器

TL;DR: The first seven articles treated Claude Code as an MCP client connecting to someone else's servers. Claude Code can also run in the opposite role. claude mcp serve starts a local stdio MCP server so another MCP client can discover and call capabilities exposed by Claude Code. The direction changes, but the protocol still uses the familiar tools/list and tools/call boundary.

After Part 7 covered resources and elicitation, it is time to reverse the connection. In Part 1, we separated the host, client, and server roles. For most of this series Claude Code has been the client: it connects to an external server, discovers what that server offers, and makes those capabilities available in its own agent loop. Now turn the picture around. Another application can connect to Claude Code as a server.

This is not just a theoretical reading of the protocol. Claude Code's current documentation gives the command:

claude mcp serve

It starts Claude Code as a stdio MCP server, meaning the calling application launches it as a local subprocess and communicates over standard input and output. That is the same transport pattern we examined in Part 3, but with Claude Code on the server side of the pipe.

One tool definition, another exit

Inside Claude Code, a tool has a name, a description, an input schema, and an implementation. During an ordinary conversation, the agent loop presents those definitions to the model and validates the model's arguments before executing a selected tool. As an MCP server, Claude Code can adapt the relevant definitions to the protocol's tool listing format instead.

The source path examined for this series does that conversion at the server entry point. When an external client asks for tools/list, Claude Code enumerates the tools it exposes and converts their input schemas to JSON Schema. When the client sends tools/call, Claude Code locates the requested implementation, checks that it is available, validates the arguments, runs it, and packages the result for the MCP response.

Conceptually, the two directions look like this:

Claude Code as client:
  Claude Code → external MCP server → external tool

Claude Code as server:
  external MCP client → Claude Code MCP server → Claude Code tool

The protocol does not force every host to implement a different tool engine for each direction. The useful implementation insight is that the tool's description, schema, and execution logic can be reused while the boundary around them changes.

What the reuse does—and does not—prove

This symmetry supports an architectural inference: Claude Code's tool abstraction is not solely a piece of prompt text tied to one conversation loop. It is structured enough to be projected outward as MCP tool metadata and executed when a different program initiates the call.

But there is a limit to that inference. “Same underlying tool implementation” does not mean an external caller inherits exactly the same context, permissions, or user interaction as an interactive Claude Code conversation. The MCP server has its own runtime conditions, tool availability, and security boundary. A client author should inspect what tools/list actually returns and test the calls they intend to make rather than assuming every internal feature is exposed or behaves identically.

The analogy with Part 4 is still useful. There, Claude Code brought external MCP tools into its tool catalog, giving each one a server-qualified name. Here, it takes tool definitions on the inside and presents them through MCP. Both directions depend on describing an operation in a way another component can discover and call.

The permission discussion in Part 5 remains relevant too. Exposing a callable capability is not the same as declaring every call safe. If you let another application launch claude mcp serve, treat that application's configuration and the resulting tool access as a real trust decision. The outside client is no longer merely reading a document; it is gaining a path to actions performed by the Claude Code process.

A practical integration shape

A compatible local MCP client generally needs a server configuration that launches the claude executable with mcp serve as its arguments. The client starts the subprocess, negotiates MCP, requests tools/list, and can then issue tools/call for the exposed names. There is no separate remote HTTP endpoint implied by this command. Standard input and output are the transport; process lifecycle and the local environment are part of the integration.

That makes this feature useful for an IDE or another automation host that already speaks MCP and wants to reuse capabilities Claude Code exposes, rather than reimplementing them from scratch. It is a narrower use case than connecting Claude Code to a familiar Jira or database server, but it completes the picture of MCP as a role-based protocol, not a one-way plugin mechanism.

Earlier drafts of this research treated the reverse role as something visible mainly in source code. The public documentation now explicitly includes “Use Claude Code as an MCP server” and the claude mcp serve command. The implementation detail about converting internal tool schemas remains a source-level observation; the existence of the user-facing command is documented behavior.

The takeaway

Claude Code can be an MCP client, a stdio MCP server, or part of a larger host that mediates several integrations. The roles describe which side discovers and invokes capabilities on a given connection. They do not dictate that a product must have only one role forever.

The final article returns to a practical design question: when a new capability is needed, should it be a Tool, a Skill, an MCP server, or a Plugin?

References

• Claude Code: Use Claude Code as an MCP server
• MCP specification: Tools
• MCP specification: Transports
• Part 3: From a Child Process to a Remote Service
• Part 4: From Tools List to an Entry in the Tool List