Understanding the Model Context Protocol (MCP)
One of the best things about the current generation of AI assistants is their ability to act as agents, reading files, running terminal commands, searching the web, or querying databases to get things done on your behalf.
But behind the scenes, connecting large language models (LLMs) to these external tools has historically been a fragmented, custom-built mess. This post breaks down the Model Context Protocol (MCP): an open standard designed to serve as the universal USB-C port for connecting AI to the software world.
Just an LLM
At its core, a large language model is a reasoning engine, not an application. It is a simple input-output system: you give it text, it runs it through its weights, and it gives you text back.
On its own, an LLM has no internet access, no way to read a file on your local machine, and no database access. It only knows what was in its training data and whatever you pass directly into the prompt.
The Bespoke Integration Problem
To build a useful AI assistant, we have to bridge this gap. We write code that gives the LLM access to external tools:
- A vector database for semantic search.
- A web search API for live results.
- A file system for reading/writing local files.
- Integration APIs (Slack, Jira, GitHub) to perform actions.
When you ask a question, the assistant application determines which tool is needed, calls the tool's API, formats the output into text, and feeds it back into the LLM's context.
While this approach works for simple apps, it breaks down quickly as the number of tools grows:
- API Inconsistency: Every tool has a different interface, response format, and authentication mechanism.
- Cognitive Load on the LLM: The system must teach the model how to construct non-standard payloads for every distinct tool.
- Security Risks: Bespoke integrations often require broad, hard-to-audit permissions, increasing the risk of exposing sensitive data.
- Maintenance Burden: Every API update from a tool vendor can break the integration code, requiring constant updates.
!Without MCP: a custom integration per tool, each with its own protocol
Enter MCP
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic, designed to address this fragmentation. Instead of writing custom connectors for every tool, MCP provides a unified protocol that everything speaks.
!MCP Ecosystem: bridging AI applications on the left to data sources and tools on the right
Think of it this way: the LLM is the brain (handling reasoning and language), and the MCP server is the toolbox (providing the capabilities). The connection between them is standardized.
!With MCP: one standard protocol for every tool, instead of a custom integration each
With MCP, you write or run a server once, and any MCP-compliant client (whether it’s Claude Desktop, Cursor, or a custom command-line agent) can immediately discover and use its resources.
MCP Architecture
MCP operates on a simple client-server architecture containing three main roles:
1. Host: The AI application itself (e.g., Claude Desktop, Cursor, or a custom agent).
2. Client: A protocol-compliant engine running inside the host that initiates and manages a session with a server.
3. Server: A lightweight, standalone process that exposes specific capabilities (tools, resources, prompts) over standard input/output (
stdio) or SSE (Server-Sent Events).A single host can connect to multiple MCP servers simultaneously. For example, your IDE can run three distinct clients to talk to a local file system server, a GitHub server, and a web search server at the same time.
!MCP architecture: a host running multiple clients, each with a one-to-one connection to its own server
What an MCP Server Can Provide
An MCP server can expose three types of context-providing capabilities to an LLM:
- Resources: File-like data that the client can read. This could be a local file path, a database schema, or a live API endpoint return value.
- Tools: Functions that the LLM can decide to execute (with the user's explicit permission) to take actions, such as writing a file, creating a Jira ticket, or running a test.
- Prompts: Pre-configured prompt templates (with arguments) that make it easy for users to trigger common agent workflows.
In practice, tools are the most commonly used feature, enabling LLMs to perform active work rather than just reading static context.
How a Request Actually Flows
When you interact with an MCP-enabled assistant, standard requests follow a clear loop:
!How an MCP request flows: from your request, through tool discovery and selection, to the final answer
1. Input (User Request): You submit a natural-language query to the MCP Host (e.g., *"Find the bug in my latest git commit"*).
2. Discovery (tools/list): The MCP Host queries the connected MCP Servers to discover which tools, resources, and templates they make available.
3. Query + Tools: The MCP Host sends your original query, along with the schemas of all available tools, to the LLM reasoning engine.
4. Tools to Use: The LLM analyzes the request against the tool schemas, decides which tool is needed, constructs the matching arguments, and sends this execution plan back to the MCP Host.
5. Calls the Specific Tool: The MCP Host acts as the execution client, calls the specific tool on the target MCP Server (
tools/call), and receives the raw result of the function execution.6. Returned Output: The MCP Host feeds the raw tool execution results back into the context window of the LLM for synthesis.
7. Output (Final Response): The LLM processes the tool results, constructs a final human-readable response, and returns it to the MCP Host to be displayed as the output.
Because the tool discovery (Step 2) and execution (Step 5) interfaces are completely standardized by the protocol, the LLM treats all tools identically, whether they are local file readers, database connectors, or cloud APIs.
Why It's Worth Using
Adopting MCP simplifies tool integration and agent development in several ways:
- No Custom Code for New Tools: Once your application has a functioning MCP client, you can add new capabilities simply by running a new server.
- Sandboxed Execution: MCP servers run as independent subprocesses, making it easy to isolate and control the environment they access.
- Deterministic Tool Calling: The model calls strict JSON-schemas defined by the server, rather than guessing free-form shell commands.
- Clean Separation of Concerns: The AI application focuses entirely on prompt orchestration and client management, while the server holds the domain-specific business logic.
Closing Thoughts
Just as USB standardized the physical connections for keyboards, mice, and storage drives, MCP is standardizing how AI applications interface with data and actions.
By building tool integrations on top of a shared protocol, the AI community is making it significantly easier to share, reuse, and secure agentic capabilities across different platforms.