MCP clients

You know what an MCP server is and why it exists. Now the question is how your application actually talks to one — and the answer is the MCP client, the piece of code that handles all the protocol details so your application logic does not have to.

The MCP client is the communication bridge between your server and the MCP servers you connect to. It is your single access point for discovering and invoking whatever tools an MCP server offers, and it abstracts away the transport and message formatting.

Transport agnostic communication

The client and server communicate over whatever transport makes sense for the deployment. The most common setup runs both on the same machine and talks over stdin/stdout — fast, local, zero network. But MCP is transport agnostic: the same protocol works over HTTP, WebSockets, and other network transports when you need to cross process or machine boundaries.

For this course, stdin/stdout is what you will use. Everything else is a deployment detail.

The two message types that matter

Once a client and server are connected, they exchange structured messages defined in the MCP spec. For tools, there are two request/result pairs you will see constantly:

• ListToolsRequest / ListToolsResult — the client asks the server "what tools do you provide?" and gets back the list of available tools with their schemas.
• CallToolRequest / CallToolResult — the client asks the server to run a specific tool with a given set of arguments, and gets back the tool's result.

That is the whole tool-side vocabulary. Discovery, then invocation.

The full request flow

Here is what actually happens when a user asks your chatbot "What repositories do I have?" End to end, user back to user:

1. User query. The user submits the question to your server.
2. Tool discovery needed. Your server needs the list of available tools to pass to Claude.
3. Server asks the client. Your server calls into the MCP client for the current tool list.
4. ListTools exchange. The MCP client sends a ListToolsRequest to the MCP server and receives a ListToolsResult.
5. Claude request. Your server sends the user's query plus the tool list to Claude.
6. Tool use decision. Claude decides it needs to call a tool to answer the question.
7. Execution request. Your server asks the MCP client to run the tool Claude specified.
8. CallTool exchange. The MCP client sends a CallToolRequest to the MCP server, which performs the actual GitHub API call.
9. Results flow back. GitHub responds, the MCP server wraps the result as a CallToolResult, and it returns to your server.
10. Results to Claude. Your server sends the tool results back to Claude.
11. Final response. Claude uses the repository data to formulate an answer.
12. User gets the answer. Your server delivers Claude's response to the user.

Twelve steps sounds like a lot, but each component has a single, clear responsibility. The MCP client's job is to abstract steps 4 and 8 — the actual protocol exchange — so your application code only has to ask for a tool list or request a tool call. Everything else is either your server's orchestration or Claude's reasoning.

Internalise this flow now. You will see every one of these steps in the next module when you run the CLI chatbot and build out both sides of this conversation yourself.