Building an MCP Client in Python from Scratch

In most real-world projects, you will either implement an MCP client or an MCP server, but not both. People building applications need an MCP client so their application code can talk to the MCP servers they want to use. People building integrations for a service tend to build the MCP server side. The reason a tutorial might cover both is to show how they fit together end to end. When you understand both halves, you can debug issues across the boundary, design servers that are pleasant to consume from clients, and write clients that are robust against unexpected server behavior.

An MCP client typically consists of two main pieces. The first is your custom MCP client class, which you write to make using the underlying session easier and to integrate cleanly with your application. The second is the client session itself, which is the actual connection to the MCP server and is provided by the MCP Python SDK. The client session requires careful resource management. You need to properly clean up the connection when you are done so you do not leak resources. That is why developers wrap the session inside a custom class that handles the cleanup automatically through context managers.

The MCP client is what enables your application code to interact with the MCP server at two key points in the request flow. First, your code uses the client to get a list of available tools to send to Claude when forming a request. Second, when Claude decides to call a tool, your code uses the client again to actually execute that tool against the MCP server. Everything else, like managing the conversation with Claude, presenting results to the user, and handling user input, lives in your own application. The client is just the bridge to the MCP side.

The list tools function gets all available tools from the MCP server. The implementation is straightforward: you access your stored session, which is the connection to the server, you call its built-in list tools method, and you return the tools from the result. From the application's perspective, this is a simple async function that returns a list of tool definitions. The session and protocol details are completely hidden, so the rest of your application just sees a clean list of tools it can pass to Claude when constructing a request.

The call tool function executes a specific tool on the MCP server. Your function takes two arguments: the tool name and the input parameters that Claude provided. You pass both to the session's call tool method, await the result, and return it back to your caller. This single function is what powers every tool execution Claude triggers. Because the session handles the actual message exchange with the server, your code stays small and focused. The whole client implementation is essentially just a constructor, a list tools method, and a call tool method, plus the lifecycle code that opens and closes the session.

A typical MCP client file includes a simple test harness at the bottom that you can run directly. When you run it, the client opens a session against your MCP server, calls list tools, and prints out the result. You should see your tool definitions, including names, descriptions, and input schemas, exactly as the server exposes them. This quick smoke test confirms three things at once: the transport is working, the session is opening cleanly, and your tool registrations on the server are reaching the client correctly. If anything is misconfigured, you see it here before involving Claude or the rest of the application.

Once the client functions are implemented, you can run your main application and ask something like what is the contents of the report PDF document. Behind the scenes, your application uses the client to fetch the available tools, then sends those tools and your question to Claude. Claude decides to use the read document contents tool. Your application uses the client to execute that tool against the MCP server. The server returns the document contents. Your application passes the result back to Claude, and Claude responds to you with an answer that incorporates the document data. The client is the bridge that makes all of this possible.