Zero to AI Engineer

Module 27 of 54

Module 27: Building an MCP Client

5 min read822 words
What you'll learn
Explain what an MCP client doesOutline how a client connects and discovers capabilitiesSee how the LLM uses discovered toolsUnderstand the client's role in the loop

"The client is the other half of MCP — it lives in your app, connects to servers, and lets your LLM actually use their capabilities."

Level: Intermediate · Time: ~13 min · Prerequisites: Module 26

Learning Objectives

By the end of this module, you will be able to:

  • Explain what an MCP client does
  • Outline how a client connects and discovers capabilities
  • See how the LLM uses discovered tools
  • Understand the client's role in the loop

1. The Client's Job

If the server offers capabilities, the client consumes them. It lives inside your host application and: connects to a server, discovers what it offers, and relays tool calls between your LLM and the server. A single host can run several clients at once — one per connected server — each keeping its own connection open. So a client is a fairly narrow, focused piece: one connection, one conversation with one server, faithfully relaying messages in both directions.

Explain like I'm new: The client is a translator and messenger. Your app says "connect to this server," the client introduces them, asks "what can you do?", and then carries requests and results back and forth so your LLM can put the server's powers to work.

2. Connect & Discover

The basic flow a client runs:

  1. Connect to a server (launch a local one, or open an HTTP connection).
  2. List the server's tools, resources, and prompts.
  3. Expose those tools to the LLM (as function-callable options).
  4. Relay calls: when the LLM requests a tool, the client asks the server and returns the result.
python
[object Object],
client = ,[object Object], connect_to_server(,[object Object],)
tools = ,[object Object], client.list_tools()      ,[object Object],
result = ,[object Object], client.call_tool(,[object Object],, {,[object Object],: ,[object Object],})

Key idea: Discovery is dynamic. The client doesn't hard-code a server's features — it asks at runtime. Add a new tool to the server and the client sees it automatically, no client changes needed. That's the power of the standard.

3. Wiring the LLM Loop

A client typically drives this loop:

  1. Send the user's message + the discovered tools to the LLM.
  2. If the LLM requests a tool, the client calls it via the server.
  3. Feed the result back to the LLM.
  4. Repeat until the LLM produces a final answer.

This is exactly the agent loop (Module 19) — MCP just standardizes where the tools come from. Instead of tools hard-coded into your app, they arrive from whatever servers the client discovered. So the same loop you learned for LangChain agents powers an MCP-based assistant; only the source of the tools has changed, from in-app definitions to discovered server capabilities.

Real-world use case: Many AI apps (assistants, IDEs) ship with a built-in MCP client, so you rarely write one from scratch — you configure which servers to connect. But understanding the client explains how "add this MCP server" instantly gives your assistant new abilities.

Concept: The client is also the natural place to enforce approval gates. Before relaying a risky tool call (delete, send, pay), it can pause and ask the user to confirm — because every request passes through it, it's the checkpoint where human oversight belongs.

4. Host = Client + LLM + UX

Remember the roles (Module 24): the host is your whole app; it contains the client(s) and the LLM, plus the user interface. Building an app often means: pick an LLM, add MCP clients for the servers you need, and manage the conversation loop.

Common mistake: Connecting to many servers and dumping all their tools into every prompt. Too many tools confuse the model and waste context. Expose only the tools relevant to the task at hand.

Hands-On: Try This

Try this: Many AI apps let you add MCP servers via a config file. Find that setting in a tool you use (or read its docs) and note what connecting a server does. Seeing "add server → new abilities appear" makes the client's discovery role click.

✅ Checkpoint

  1. What does an MCP client do?
  2. Why is capability discovery dynamic?
  3. How does the client relate to the agent loop?

Answers: 1) Connects to servers, discovers capabilities, and relays tool calls between the LLM and server. 2) It asks the server at runtime, so new tools appear automatically. 3) It drives the loop: send tools → model requests one → call it → return result → repeat.

Key Takeaway: The client lives in your host app and consumes server capabilities: it connects, discovers tools/resources/prompts at runtime, exposes them to the LLM, and relays calls — driving the agent loop. Discovery is dynamic, so new server features appear automatically. Most apps ship a built-in client you configure; expose only relevant tools to avoid confusing the model.

Further Learning

Adapted from Microsoft's MCP for Beginners (MIT License).