Introducing Model Context Protocol
Understanding Agentic Protocols — Part 1
Over the past few weeks, the AI development community has witnessed a surge in the introduction of new protocols aimed at enhancing interoperability and functionality among AI systems. Notably, the launches of the Model Context Protocol (MCP) by Anthropic and Agent2Agent (A2A) by Google have garnered significant attention.
To be honest, when I read the claim “it is a way to standardize the way we develop and consume agentic components”, my first thought was: isn’t that the claim of all AI frameworks like LangChain, Semantic Kernel, Autogen and others? Are we facing yet another entry in an already over-populated market?
Well, while there is some overlap, these protocols serve distinct purposes within the AI ecosystem. While frameworks like LangChain and Semantic Kernel provide the building blocks for developing AI applications (e.g. Plugins, Tools, Agents, Prompts…), protocols like MCP and A2A focus on standardizing the interactions between AI systems, external tools, other agents, and transactional processes.
In this series of article, we will explore the key concepts of these protocols and how to leverage in concrete applications. In this first Part, we will cover Model Context Protocol, however before digging deeper into it, we first need to understand what even is a protocol.
What is a Protocol?
A protocol is simply a set of rules that defines how two or more systems communicate with each other. For example, when you navigate a website through your browser, the browser “talks” to the website using a protocol called HTTP. This protocol defines a set of rules for how requests and responses should be formatted so the server and client can understand each other.
- The client is the software or user (like a browser or mobile app) making a request.
- The server listens for incoming HTTP requests and returns appropriate responses.
For example, if you want to visit the wiki page for Mount Kilimanjaro, the flow will look like follow:
Now imagine that instead of loading an entire web page, your browser (or app) just needs specific data — like a list of books, weather for Dubai, or details about Mount Kilimanjaro. That’s where REST APIs come in.
REST APIs (Representational State Transfer Application Programming Interfaces) are a way for programs to exchange structured data — also over HTTP — without displaying a full page. They use the same verbs (GET, POST, etc.) and URLs to allow one system to request just the data it needs from another system. However, instead of an HTML page, the server would respond with something like:
{
"name": "Mount Kilimanjaro",
"elevation": 5895,
"location": "Tanzania"
}
This lightweight, machine-readable format is what makes REST APIs so powerful for modern apps and ultimately AI Agents.
Model Context Protocol
Similarly to the HTTP foundational protocol that enables web browsers to communicate with servers, Model Context Protocol (MCP) is designed to standardize how LLMs interact with external tools and data sources. Just as REST APIs provide a uniform interface for web services, MCP offers a consistent framework for AI models to access and utilize various resources.
The ambition of the Model Context Protocol (MCP) is to address several limitations inherent in the current landscape of AI tool integration and orchestration.
- Fragmented Orchestrators and Custom Integrations. The AI ecosystem is populated with numerous orchestrators like LangChain, Semantic Kernel, and Autogen, each offering their own set of pre-built libraries and connectors. While these frameworks facilitate AI development, they often require custom integrations for each tool or data source, leading to a proliferation of bespoke solutions that are difficult to maintain and scale.
- Dependency on Provider-Specific Updates. Integrations built on proprietary APIs are subject to changes dictated by the service providers. When an API is updated or deprecated, developers must modify their integrations accordingly, consuming valuable time and resources. This dependency hampers agility and can lead to system downtimes if not managed proactively.
- Lack of a Common Integration Standard. The absence of a universal protocol for AI tool integration means that each application must implement its own method for connecting with external resources. This siloed approach results in redundant efforts, increased complexity, and challenges in achieving interoperability across different systems and platforms.
Let’s break it down into its main components:
- MCP Host → it’s application or environment that initiates and manages interactions with external tools. Examples include applications that have already adopted the protocol, like Claude Desktop, GitHub Copilot, Cursor, or web-based LLM chat interfaces.
- MCP Client →it’s is a component within the host application that handles the communication between the host and external MCP servers. It establishes and manages connections to MCP servers, translating the host’s requests into standardized protocol messages and handling responses.
- MCP Server →These are external services that the MCP client connects to. They can be tools, data sources or prompts.
MCP operates on a client-server architecture, however there is a major difference: it’s up to the LLM to decide which MCP server to invoke based on the user query, following the function-calling mechanism.
Note
MCP utilizes JSON-RPC 2.0 to define the structure of messages exchanged between clients and servers. This lightweight, stateless protocol allows for remote procedure calls using JSON-encoded messages, specifying methods and parameters in a standardized way.
So, MCP leverages JSON-RPC 2.0 to structure its messages, employs HTTP among other protocols for message transport, and can integrate with existing REST APIs by translating its method calls into RESTful requests.
You can learn more about the MCP transport layer here.
As mentioned above, there are three main types of MCP servers:
- Tools →they are executable functions that AI models can invoke to perform specific actions. These can include operations like querying a database, calling an API, or executing a computation. This is the typical schema of an MCP tool:
{
name: string; // Unique identifier for the tool
description?: string; // Human-readable description
inputSchema: { // JSON Schema for the tool's parameters
type: "object",
properties: { ... } // Tool-specific parameters
}
}- Resources →they represent data or content that servers expose to clients, providing context for AI interactions. This can encompass files, database records, API responses, or any other data that can be read by clients. MCP resources are identified using URIs and include:
{
uri: string; // Unique identifier for the resource
name: string; // Human-readable name
description?: string; // Optional description
mimeType?: string; // Optional MIME type
}- Prompts →they are pre-written, semantic templates or workflows that assist users in accomplishing specific tasks. This is the typical schema of an MCP prompt:
{
name: string; // Unique identifier for the prompt
description?: string; // Human-readable description
arguments?: [ // Optional list of arguments
{
name: string; // Argument identifier
description?: string; // Argument description
required?: boolean; // Whether argument is required
}
]
}Now that we’ve broken down the different types of MCP servers and how they contribute to a modular and flexible AI architecture, it’s time to move from concept to practice.
Hands-on
Let’s say we want to create a simple tool that retrieve the closing price of a given stock. The tool — which is nothing but a python function — looks like follow:
import yfinance as yf
def get_stock_price(ticker: str) -> float:
"""Fetch the latest stock price for a given ticker symbol from Yahoo Finance"""
stock = yf.Ticker(ticker)
return stock.history(period="1d")["Close"].iloc[-1]Now, how do we expose it as an MCP server?
Once we set up our Python environment (you can follow the MCP Python SDK installation guide here), we can initialize an MCP server and add our function to it as a tool as follows:
from mcp.server.fastmcp import FastMCP
# Create an MCP server
mcp = FastMCP("Demo")
# Add an addition tool
@mcp.tool()
def get_stock_price(ticker: str) -> float:
"""Fetch the latest stock price for a given ticker symbol from Yahoo Finance"""
stock = yf.Ticker(ticker)
return stock.history(period="1d")["Close"].iloc[-1]And that’s it! Now we need to add our server to our host. In our case, we will leverage Claude Desktop as MCP host. If this is the case, if you are using uv you can run the following command to install the server:
uv mcp install server.py
This command will automatically populate the claude_desktop_config.json file (it will most likely be in your %APPDATA%\Claude path).
{
"mcpServers": {
"Demo": {
"command": "uv",
"args": [
"run",
"--with",
"mcp[cli]",
"mcp",
"run",
"C:path_to_your_server/server.py"
]
}
}
}Alternatively, you can can add your server manually to
Note: if you want to leverage pre-built servers, here you can find an amazing catalog to sample from: Awesome MCP Servers.
If everything is properly set, you will be able to see the MCP server properly initialized when restarting your Claude Desktop app:
Within the server, you will see the available tools:
Let’s test it:
Conclusions
The Model Context Protocol (MCP) is rapidly emerging as a foundational standard in the AI ecosystem, offering a unified framework for connecting large language models (LLMs) to external tools, data sources, and workflows.
In upcoming articles, we will delve deeper into MCP’s architecture, explore its integration with other agentic protocols like Agent2Agent (A2A), and examine real-world case studies highlighting its impact on various industries. Stay tuned to discover how MCP and similar protocols are shaping the future of AI interoperability and functionality.
