Overview of Model Context Protocol
Large Language Models like Claude are incredibly powerful, but they have a fundamental limitation: they are trained on data up to a specific point in time, and they cannot directly interact with the outside world. Think of an LLM as a brilliant mind trapped inside a room with no windows or doors—it knows a tremendous amount, but it cannot see what’s happening outside or take any actions in the real world.
This limitation becomes apparent when you ask an LLM to perform calculations. Despite their sophistication, LLMs don’t actually “calculate” in the mathematical sense. They predict the most likely next token based on patterns learnt during training. Ask an LLM to multiply 7,849,231 by 3,492,107, and it might give you an answer that looks plausible but is actually incorrect. The model is essentially making an educated guess based on patterns it has seen, not performing actual arithmetic.
Now consider a simple calculator—it performs that same multiplication instantly and with perfect accuracy. The solution becomes obvious: instead of asking the LLM to calculate, why not give it access to a calculator? When it needs to multiply those numbers, it can delegate to a tool that excels at that task.
The Need for Standardization
This is the core insight behind the Model Context Protocol: LLMs become dramatically more useful when they can access external tools and data sources. But how do you build these connections in a scalable, standardized way?
Before MCP, connecting AI applications to external tools was a fragmented mess. Imagine you’re building an AI assistant that needs to access your calendar, email, file system, and database. You would need to write custom integration code for each connection. Now multiply that by every AI application that might want similar capabilities—each would need its own custom connectors.
If you have n AI applications and m data sources or tools, you end up with n × m custom integrations. With 10 AI apps and 20 tools, that’s 200 separate integrations to build and maintain. Each one is different, with its own API conventions, authentication methods, and data formats. This approach simply doesn’t scale.
MCP solves this problem through standardization—much like USB-C revolutionized physical connections for electronic devices. Before USB-C, every manufacturer had proprietary connectors. Your phone charger wouldn’t work for your laptop, and your laptop’s charger was different from your tablet’s. Now, with USB-C, one cable works for almost everything.
The MCP Architecture
The Model Context Protocol creates a similar universal standard for AI integrations. Instead of n × m custom connections, you get n + m implementations: each tool implements the MCP protocol once, and each AI application implements it once. They can then all communicate with each other seamlessly.
A database that exposes itself via MCP can be accessed by Claude Desktop, VS Code, Cursor, or any other MCP-compatible host. An AI assistant that supports MCP can immediately work with any MCP server, whether it provides access to files, APIs, databases, or custom business logic.
The Model Context Protocol consists of three main components that work together to enable AI applications to interact with external tools and data sources. Understanding this architecture is essential before building your first MCP server.
Hosts are the LLM applications that users interact with directly. These are the “front-end” of the MCP ecosystem. The applications are where users type their queries and receive responses. Examples include Claude Desktop, Cursor (the AI-powered code editor), VS Code with AI extensions, and custom AI applications built by developers.
The host’s responsibility is to manage the user interface, handle conversations with the LLM, and coordinate access to MCP servers. When a user asks a question that requires external data or tool usage, the host recognizes this need and facilitates the connection to the appropriate MCP server.
Clients are the protocol handlers that live inside hosts. Each client maintains a one-to-one connection with an MCP server. Think of clients as translators. They understand the MCP protocol and handle the communication details so the host can focus on higher-level concerns.
When Claude Desktop connects to your custom MCP server, a client component inside Claude Desktop manages that connection. The client handles protocol negotiation, message formatting, and ensuring reliable communication between the host and server.
Servers are the capability providers. They are the components that bridge MCP to external systems. An MCP server exposes specific tools, resources, or data that AI applications can use. In this lesson, you’ll build a server that provides a “dog age to human age” calculator tool.
MCP servers can be remarkably simple or incredibly sophisticated. A server might expose a single function, like your calculator example, or it might provide access to an entire database, a collection of APIs, or complex business logic. The key is that servers implement the MCP protocol, making their capabilities available to any compatible host.