Recommended resources
The freely available resources this lesson will direct you to.
Hello! Welcome back.
In our previous lesson, we established why a new approach to tool integration was needed for AI agents. We diagnosed the "N×M integration problem" and saw how it leads to bloated context windows and brittle, unscalable systems. We introduced the Model Context Protocol (MCP) as the conceptual solution—an open standard designed to be the "USB-C port for AI."
Today, we move from the "why" to the "what." This lesson will address the learning outcome: Describe the MCP architecture (hosts, clients, servers) and compare it with direct function calling. We will dissect the components of MCP and then place it side-by-side with the traditional method of integrating tools to understand the fundamental architectural differences and trade-offs.
1. The MCP Architecture: A Coordinated System
As you know from your software engineering experience, a good protocol is defined by clear roles and responsibilities. MCP is no different. It uses a client-server architecture to decouple the AI application from the tools it uses.
To get a clear mental model of how these parts fit together, let's start with a video that builds on the USB-C analogy from our last lesson.
MCP vs API: Simplifying AI Agent Integration with External Data
This video from IBM Technology provides an excellent and concise explanation of the MCP architecture, defining the roles of the host, client, and server.
Watch the segment from 00:49 to 02:59. As you watch, focus on identifying the three main components (host, client, server) and understanding the role each one plays. Notice how the USB-C port analogy maps to these components.
As the video explained, the MCP architecture consists of three main components working together. Let's formalize those definitions.
What Is the Model Context Protocol (MCP) and How It Works
The following article from Descope provides a detailed breakdown of the MCP architecture. We'll read the section that defines the core components.
Read the section titled 'Core components'. It clearly defines the Host application, MCP client, MCP server, and the Transport layer. This will solidify the concepts from the video.
To summarize and structure what you've just learned from the video and text:
- Host Application: This is the user-facing application where the LLM lives. Think of it as the "chassis." Examples include Anthropic's Claude Desktop or an AI-powered IDE like Cursor.
- MCP Client: This component resides within the Host Application. Its job is to manage connections to various MCP servers. It speaks the MCP language (using the protocol) on behalf of the host.
- MCP Server: This is a standalone application that acts as a standardized wrapper around a tool or data source (e.g., a database, a set of files, or a third-party API like GitHub). It exposes the tool's capabilities through the MCP protocol, hiding the underlying implementation details.
These components communicate over a Transport Layer, typically using JSON-RPC 2.0 messages. This can happen locally via STDIO or remotely over HTTP.
2. The Alternative: Direct Function Calling
Before we can fully appreciate the MCP architecture, we must clearly understand the approach it improves upon: direct function calling (also called "tool use" by some providers like Anthropic).
In this model, there is no standardized protocol or separate server. The responsibility for defining, managing, and executing tools falls entirely on the developer's application code.
The video below explains this traditional workflow and its inherent challenges.
MCP vs Function Calling - Clearly Explained
This video clearly explains the mechanics of traditional function calling and highlights the maintenance burden it places on developers.
Watch the segment from 01:48 to 04:29. Pay close attention to the description of the workflow: how function definitions are provided to the LLM, how the LLM responds with a request to call a function, and how the developer's code must then execute that function. Note the discussion of the problems this creates as the number of tools grows.
In short, the direct function calling process is:
- The developer defines the available tools as a JSON schema.
- This schema is included in the API request to the LLM, along with the user's prompt.
- The LLM analyzes the prompt and decides if a tool should be used. If so, it responds with the name of the function to call and the arguments to use.
- The application code receives this response, parses it, and executes the corresponding function with the provided arguments.
- The application then sends the function's output back to the LLM in a subsequent API call so it can generate a final answer.
3. MCP vs. Direct Function Calling: A Comparison
Now that we have defined both approaches, we can compare them. While function calling is effective for simple cases, MCP's architecture provides significant advantages for building scalable, maintainable, and secure AI systems.
The following image provides a high-level visual comparison of the two architectures.
To dive deeper into the trade-offs, the next resource offers a comprehensive comparison from a developer's perspective.
MCP vs. Function Calling: How They Differ and Which to Use
This article is an excellent, detailed comparison of MCP and function calling across several dimensions that are critical for any software project.
Read the sections titled 'Architecture and design philosophy', 'Implementation complexity and developer experience', 'Authentication and security', and 'Vendor lock-in and portability'. These sections directly compare the two methods on key engineering criteria.
Let's synthesize the key points from that article into a clear summary.
| Aspect | Direct Function Calling | Model Context Protocol (MCP) |
|---|---|---|
| Architecture | Tightly Coupled. Tool logic is embedded within the main application. Every change to a tool requires redeploying the entire application. | Decoupled (Client-Server). Tools are independent servers. They can be developed, deployed, and scaled separately from the client application. |
| Standardization | Provider-Specific. Each LLM provider (OpenAI, Anthropic, Google) has its own schema format and API for tool use, leading to vendor lock-in. | Open Standard. Provider-agnostic. The same MCP server can be used by any MCP-compliant client, regardless of the underlying LLM. "Build once, integrate many." |
| Discovery | Static. The application must know all available tools at compile time and include their definitions in the prompt. | Dynamic. The client can query a server at runtime to discover its capabilities (e.g., tools/list). This allows agents to adapt to new tools without code changes. |
| Security | Centralized Credentials. API keys and other secrets are stored in the main application's environment. A compromise of the application exposes all secrets. | Isolated Credentials. Credentials live inside their respective MCP servers. The client never sees them, adhering to the principle of least privilege. |
| Best For | Rapid prototyping, simple integrations, and projects committed to a single LLM provider's ecosystem. | Production systems, applications with many tools, sharing tools across teams, and maintaining long-term flexibility and security. |
Finally, it's important to understand that MCP and APIs are not mutually exclusive. In fact, they are complementary.
MCP vs API: Simplifying AI Agent Integration with External Data
Let's return to the IBM Technology video for a final, important clarification on the relationship between MCP and the APIs it often uses.
Watch the concluding segment from 11:48 to 12:46. The key insight here is that MCP is often a wrapper around existing APIs.
As the video states, MCP and APIs are not adversaries; they are layers in the AI stack. An MCP server often translates the standardized MCP requests from a client into native API calls for the underlying service (e.g., a REST API for GitHub). MCP provides the "AI-friendly" interface on top.
Conclusion
In this lesson, you have moved from understanding the problem of tool integration to understanding the solution's architecture. We've dissected the components of MCP and contrasted them with the more traditional direct function calling approach.
Key Takeaways:
- MCP Architecture: Consists of a Host (the AI application), a Client (manages connections), and one or more Servers (standalone wrappers for tools), all communicating via a standardized protocol.
- Direct Function Calling: A tightly-coupled approach where tool schemas and execution logic are embedded directly within the application, making it dependent on a specific LLM provider's API.
- Key Differences: MCP's client-server model enables decoupling, dynamic discovery, credential isolation (security), and portability across LLMs. Function calling is simpler for small projects but creates long-term maintenance, security, and lock-in challenges.
- Complementary Layers: MCP is not a replacement for APIs but rather a standardized abstraction layer built on top of them to make them easily consumable by AI agents.
You now have a solid architectural understanding of MCP. In the next lesson, we will put this theory into practice as you take the first step in building with this protocol: setting up your first MCP server to expose tools to an LLM client.