Deconstructing the Model Context Protocol - The Lingua Franca for AI Agents

Introduction

In the rush of AI development, we’re often so focused on what we can build that we forget to ask how we’re building it. We create AI agents that can write code, analyze data, and interact with users, but connecting these systems to the real world usually means an “API jungle”: each new tool or data source needs a custom, brittle integration, and the result is a tangled mess that’s difficult to scale and maintain.

The Model Context Protocol (MCP) exists to fix that. It’s a common language that AI agents can use to interact with any tool. But calling it a “protocol” is a strong claim. It implies a level of standardization and structure that goes beyond a simple library or SDK. So what is MCP, really? Is it a true network protocol? How did it come to be, and what properties define it? Let’s take it apart.

Is MCP a Network Protocol? The Application Layer Explained

Yes, with an important distinction. MCP is an application-layer protocol, sitting at the very top of the network stack alongside HTTP, FTP, and SMTP.

To place it, here’s the network stack from the bottom up:

• Physical & Link Layers (The Wires & Wi-Fi): The fundamental hardware that moves bits around.
• Internet Layer (IP): The global postal system that routes packets between networks.
• Transport Layer (TCP): The certified mail service that ensures your packets arrive reliably and in the correct order.
• Application Layer (HTTP, MCP): The rules defining the content and format of the message inside the envelope.

MCP doesn’t reinvent the wheel. It doesn’t care how data packets are routed or reassembled. It uses the proven, universal foundation of TCP/IP and HTTP to handle the actual data transport, and defines the rules of conversation that happen on top of HTTP.

If HTTP is the mail truck that reliably delivers an envelope from point A to point B, MCP is the standardized business form inside the envelope, like a tax return. The mail carrier doesn’t need to understand the form, but the recipient’s accounting office knows exactly how to process it because it follows a predictable, standard layout.

So MCP is a protocol that standardizes how an AI “host” and a tool “server” communicate, using HTTP as its primary vehicle.

The Birth of a Standard: How MCP Became a Protocol

Protocols typically become standards in one of two ways: through a formal, slow-moving standards body like the IETF, or by emerging organically from the industry to solve a pressing, common problem, becoming a de facto standard.

MCP is a textbook example of the latter. It came out of necessity, with strong backing from companies like Vercel, to bring order to early AI agent development.

Here’s how it happened:

1. The Problem: In the early days of AI agents, every developer created their own bespoke method for an AI to call an API. An agent built to use the Stripe API was useless for interacting with the GitHub API without a completely new, custom-built adapter. This was the “API jungle”: inefficient, not scalable, and a nightmare to maintain.

2. The Proposal: Instead of every team reinventing this crucial piece of infrastructure, key players in the community proposed a single, open standard. The idea was simple: if everyone agrees on the format of the conversation, then any AI can talk to any tool, and any tool can be used by any AI.

3. The Solution (MCP): A protocol was designed with a clear, simple structure based on familiar web standards. It focused on two fundamental actions that form the basis of all tool use:

   • Discovery: “What can you do?”
   • Execution: “Do this specific thing for me.”

4. Adoption and Growth: The protocol’s success was fueled by its open-source nature and the creation of easy-to-use libraries and SDKs. As major platforms and tool providers began offering MCP-compliant servers, a network effect took hold. It became easier to adopt the standard than to build a custom solution.

No committee decreed MCP into existence. It became a protocol by providing a practical solution to a real-world problem that thousands of developers were facing at the same time.

The Anatomy of a Protocol: Core Properties of MCP

These are the defining characteristics that make MCP a true protocol and not just a library:

1. Client-Server Architecture: The protocol strictly defines two roles. There is an MCP Host (the AI application) that initiates requests and an MCP Server that provides the tools and responds. This clear separation of concerns is a hallmark of well-designed network protocols.

2. Standardized Endpoints: An MCP server is predictable. It’s expected to have specific API endpoints that act as the “verbs” of the protocol. The two most important are:

   • GET /tools: The universal command for discovery.
   • POST /tool/{tool_name}: The universal command for execution.

3. Schema-Driven Communication: This is MCP’s most important property. Every tool must be described by a schema (typically JSON Schema) that details:

   • The tool’s name.
   • A natural language description of its purpose.
   • A list of parameters it accepts, including their types and descriptions. The schema does double duty: it validates data, and it’s also the instruction manual the LLM reads to decide which tool to use and how to call it correctly.

4. Statelessness: Like a well-designed REST API, MCP is stateless. Each request from the client must contain all the information necessary for the server to process it. The server doesn’t hold memory of past requests, which makes the system highly scalable and resilient.

5. JSON-Based Payloads: The data exchanged (schemas, arguments, results) is formatted as JSON, the common format of modern web APIs. This ensures maximum compatibility across different languages and platforms.

6. Transport Agnostic: While typically implemented over HTTP/HTTPS, the core principles of MCP aren’t strictly tied to it. It could be adapted to run over other transports like WebSockets or gRPC in the future.

Why This Matters for You

Understanding MCP as a protocol is more than an academic exercise. It means we can stop writing one-off integration hacks and start building on a stable, interoperable foundation.

When you build a tool that speaks MCP, it can be understood not just by your current AI model, but by any future AI agent that also speaks the protocol. That’s the difference between building a disposable solution and contributing to a growing, interconnected ecosystem, and it makes for more reliable, more maintainable applications.