Learn about the three pillars of MCP architecture and how the Host, Client, and Server work together to connect AI to the real world.
O Host is the application where the AI model actually runs. It’s the starting point for everything: the interface the user sees, the environment that contains the model, and the place where communication with the outside world begins. Without the Host, the model has nowhere to exist—it’s the AI’s “home.”
The Host is the host application that hosts the AI model and manages the entire interaction lifecycle. It is responsible for initiating communication, displaying results to the user, and coordinating the clients that connect to the servers. Concrete examples of hosts include:
Anthropic's official application that runs Claude locally with native MCP support.
IDE that integrates AI models to assist with programming and can act as an MCP Host.
Custom internal application that embeds an AI model to automate processes.
The concept of Host in MCP was inspired by the architecture of Language Server Protocol (LSP), created by Microsoft for code editors. As with LSP, where the editor (VS Code, Neovim, etc.) is the host that communicates with language servers, in MCP the Host is the application that contains the model and orchestrates communication. This architectural choice allows any application become an MCP Host—from personal assistants to large-scale enterprise platforms.
O Client is the messenger in the MCP architecture. It lives inside the Host and is responsible for translating the model’s needs into standardized requests that Servers can understand. Each Client maintains a dedicated connection to a specific Server, and a single Host can contain multiple clients — each connected to a different Server.
The Client manages the connection lifecycle between the Host and a Server. Its responsibilities include: starting and ending connections, sending requests in MCP format, receiving and processing responses, handling errors and timeouts, and maintaining session state. The Client abstracts away all the communication complexity — the model doesn't need to know how to talk to each tool; it just asks for what it needs, and the Client translates. A Host like Claude Desktop can have one Client connected to GitHub, another to PostgreSQL, and another to the local file system at the same time.
The Client is like a simultaneous translator between the model and the tools. Imagine the model speaks "Portuguese" and each tool speaks a different language — the database speaks "SQL", GitHub speaks "REST API", and the file system speaks "OS commands". The Client translates everything into the standardized MCP format, ensuring communication flows smoothly without either side having to learn the other's language.
O Server is the component that actually exposes capabilities to the AI model. It provides Tools (tools that perform actions), Resources (data that can be read) and Prompts (reusable interaction templates). Each server specializes in a specific domain: there’s a server for GitHub, another for databases, another for email, and so on.
The MCP Server is a program that exposes standardized capabilities to be consumed by Clients. It bridges the MCP protocol and real external systems. For example, a GitHub Server receives an MCP request like "list open pull requests" and translates it into calls to the GitHub API, returning the result in the standardized format. The idea is for each Server to be focused and specialized — one Server for each domain, each doing one thing well.
Now that you know the three pillars—Host, Client, and Server—it’s time to see how they work together in a real end-to-end flow. From the moment the user asks a question to the final answer, each component plays a specific role in this orchestration.
The MCP flow follows a well-defined chain: the user sends a request to the Host, the model inside the Host identifies that it needs external data or actions, the Client translates that need into a standardized MCP request, the Server performs the action in the external system, and the result makes its way back to the model, which formulates the final response to the user. All this happens transparently — the user doesn't need to know that multiple systems were consulted behind the scenes.
The user sends a message to the Host. Example: "What pull requests are open in my repository?"
The AI model inside the Host analyzes the question and determines that it needs to access GitHub to answer it. It identifies which MCP Server tool to call.
The Host Client translates the model’s need into a standardized MCP request and sends it to the GitHub Server.
The GitHub Server receives the request, calls the GitHub API, retrieves the list of open pull requests, and formats the result.
The Server sends the standardized response back to the Client, which passes it on to the model inside the Host.
The model processes the received data and formulates a natural-language response to the user: "You have 3 open PRs: #42 (fix login), #38 (add tests), #35 (update docs)."
To solidify the architecture in your mind, let’s build a mind map of the MCP framework. Visualizing how the pieces fit together is essential for understanding where each component begins and ends, and how information flows between them.
The MCP architecture follows a clear hierarchy of containment and connection:
The Host contains the model and the Clients. Each Client connects to exactly one Server. Each Server connects to one or more external systems. This separation ensures modularity, security, and scalability.
Think of the MCP architecture as a modern office. The Host is the office building where everything happens. The AI model is the director who makes decisions. The Clients are the executive assistants—each specialized in handling a different vendor. And the Servers are the external vendors (bank, mail, IT) that perform the requested services. The director doesn't call each vendor directly—they ask the right assistant, who knows exactly how to communicate with that vendor.
Theory comes to life through concrete examples. Let’s look at two real-world scenarios for using the MCP architecture—one for developers and one for business teams—to see how the Host, Client, and Server work together in practice.
The beauty of the MCP architecture is that it works from the same way independent of the scenario. Whether you're a programmer requesting code analysis or a sales team checking metrics, the Host → Client → Server flow remains identical. What changes are the Servers connected and the Tools available—but the architecture, protocol, and communication standard are always the same. This consistency is what makes MCP so powerful.
A developer opens Claude Desktop and asks: "Analyze the latest commits in my repo and suggest improvements."
Host: Claude Desktop (application with the Claude model)
Client: Claude Desktop's internal MCP Client
Server: GitHub MCP Server (accesses the GitHub API)
Flow: Claude identifies the need → Client sends a request to the GitHub Server → Server queries commits via API → result returns → Claude presents analysis with suggestions
A sales manager uses the company’s internal platform and asks: "What was the revenue by region last quarter?"
Host: Internal company application (with an integrated AI model)
Client: MCP Client configured in the application
Server: PostgreSQL MCP Server (connects to the database)
Flow: Model identifies need for data → Client sends request to PostgreSQL Server → Server executes SQL query → result is returned → Model presents formatted report with data by region
Be careful with permissions! The fact that an MCP Server can perform actions in external systems makes access control essential. Each Server should have only the minimum permissions it needs—the GitHub Server doesn't need database access, and the PostgreSQL Server doesn't need GitHub access. Always apply the principle of least privilege: grant only the permissions strictly necessary for each Server to perform its function.
Next Module: 1.4 — Seeing MCP in Action