MCP入門 ② 自作 MCP Client から MCP Server を呼び出す MCP入門 ② 自作 MCP Client から MCP Server を呼び出す

The second installment of this introductory MCP series moves from consuming a server through an existing host to building the other half of the connection yourself. Where the first article wired a homemade MCP server into Claude Code and let the assistant do the orchestration, this piece focuses on writing a custom MCP client that talks to that server directly. Understanding both sides of the protocol matters because it demystifies what a host application like Claude Code is actually doing under the hood, and it gives developers the freedom to embed tool-calling into their own applications rather than depending on a vendor's chat interface.

The Model Context Protocol, proposed by Anthropic in late 2024, is an open standard for connecting large language models to external tools, data, and prompts. Its design follows a client-server architecture. A host application embeds one or more MCP clients, and each client maintains a one-to-one connection with an MCP server. The server exposes capabilities in three main categories: tools, which are callable functions; resources, which are readable data sources; and prompts, which are reusable templates. The client's job is to discover those capabilities, surface them to the language model or the surrounding application, and relay the model's requests back to the server.

Under the surface, MCP communication is built on JSON-RPC 2.0. When a client starts, it performs an initialization handshake with the server, exchanging protocol versions and capability declarations so both sides know what features are supported. After that, the client can issue requests such as listing the available tools or invoking a specific tool with arguments. The server responds with structured results. This separation means the same server can be reused by any compliant client, and the same client can connect to many different servers, which is the core interoperability promise that has made the protocol attractive across the industry.

Transport is another concept worth understanding before writing a client. MCP defines how messages travel between client and server, and the two most common options are standard input/output, often called stdio, and HTTP-based streaming. The stdio transport launches the server as a subprocess and exchanges JSON-RPC messages over its input and output streams, which is convenient for local tools. The HTTP approach, which has evolved toward a Streamable HTTP transport, suits remote servers and networked deployments. A custom client typically picks the transport that matches how its target server is run, and the official SDKs abstract much of this plumbing away.

In practice, a minimal custom client written with one of the official SDKs, available for languages including Python and TypeScript, follows a predictable sequence. It establishes a session over the chosen transport, completes the initialization handshake, and calls a method to list the tools the server advertises. Those tool definitions, which include names, descriptions, and JSON schemas for their inputs, can then be passed to a language model so it can decide which tool to call. When the model returns a tool-call request, the client executes it against the server, captures the result, and feeds that back into the conversation so the model can produce a final answer. This loop is essentially what hosts like Claude Code automate, and reproducing it by hand is the most direct way to see how the pieces fit together.

It is worth placing this in broader context. Since its release, MCP has been adopted or trialed by a range of tools beyond Anthropic's own products, and competing AI platforms and editors have shown interest in standardizing tool access in similar ways. The growing ecosystem of community-built servers for filesystems, databases, version control, and web search means a working custom client can immediately tap into a large library of existing integrations. Readers approaching this article will likely benefit from having completed the first part, since familiarity with running a basic server and the general request-response flow makes the client code easier to follow.

The practical takeaway is that building a client is not significantly harder than building a server once the protocol's shape is clear. By owning both ends, developers can integrate MCP-driven tool use into bespoke applications, scripts, or backend services, rather than treating the protocol as something only chat assistants can use. That flexibility appears to be a meaningful part of why MCP has gained traction so quickly.