Model Context Protocol (MCP) in AI

Introduction to MCP

The Model Context Protocol (MCP) is an open standard designed to connect AI assistants with the systems where data actually lives — from content repositories and business tools to development environments. In essence, MCP creates a universal interface between large language model (LLM) applications and external data or functionality. Anthropic (the team behind the Claude AI assistant) introduced MCP in late 2024 as a solution to the growing integration challenges in AI. Rather than building one-off plugins or custom connectors for every database, API, or knowledge base, developers can use MCP as a common protocol that any AI application (client) and any data source (server) can understand. This dramatically simplifies how AI systems get context (relevant information) and perform actions on behalf of users.

Think of MCP like a “USB-C port” for AI applications — a standardized plug-and-play interface for connecting to all sorts of tools and data. Just as USB-C lets many devices interoperate regardless of manufacturer, MCP defines universal rules that let any LLM-based client talk to any MCP-compliant server. This standardization is comparable to what the Language Server Protocol (LSP) did for programming environments: LSP allowed any code editor to support any programming language through a common protocol, turning an M×N integration problem into M+N.

The key idea is to reduce the number of direct interactions you need to manage. In an M×N integration setup, every component from the first group has to be connected with every component from the second group, leading to M×N pairings. By contrast, when you turn it into an M+N LSP-based approach, you let each of the M components and each of the N components communicate with a centralized protocol (here, the Language Server Protocol). This means you only need to manage M+N connections rather than every possible pair.

Similarly, MCP turns the tangle of custom AI integrations into a more manageable ecosystem — AI assistants and data/services only need to implement MCP once to work with each other. The goal is a more relevant, up-to-date AI (accessing live data) and a more sustainable integration ecosystem where improvements to one MCP server benefit all compatible clients.

MCP architecture illustration — MCP connects AI applications (hosts like Claude or IDEs) through MCP clients (in-app connectors) to various MCP servers. Each server is like a “peripheral” — whether a remote service (Slack, Gmail, Calendar APIs, etc.) or local data (files, database) — all plugged in via the unified MCP interface. This allows the AI assistant to seamlessly access multiple data sources and tools through one standardized hub.

Key Components of MCP

MCP’s design follows a client-server architecture that cleanly separates the roles of AI applications and data connectors. The key components in this architecture include:

MCP Hosts (AI Applications) — The AI or LLM-powered applications that need external information or capabilities. Hosts can be chatbots, IDEs, or any tool where an LLM is embedded. For example, Claude Desktop, a code editor like Cursor, or a chatbot interface could act as an MCP host. The host is responsible for coordinating the LLM’s operations, managing multiple connections, and merging AI outputs with retrieved context. It typically integrates one or more MCP clients.
MCP Clients — The client is a component (often a library or process) that lives within the host application and manages a 1:1 connection to an MCP server. Each data source or tool gets its own client instance. Clients handle all message exchange with the server, route requests/responses, and keep track of what the server can do. They also handle session details like initializing the connection and negotiating capabilities with the server.
MCP Servers — Servers are lightweight programs or services that expose specific data or functionality through the MCP interface. A server could wrap a local resource (like your filesystem or database) or a remote service (like Slack, Gmail, GitHub, etc.). Each server provides one or more capabilities in a standardized way, so any MCP client can query or invoke them. Instead of a host needing custom code for, say, Google Drive vs. Slack vs. a SQL database, each of those can have an MCP server and the host just speaks MCP to all of them. Early examples of servers include connectors for Google Drive, Slack, Git repositories, Postgres databases, and more.
The MCP Protocol (Base Protocol) — This is the language and rules that clients and servers use to communicate. MCP uses JSON-RPC 2.0 as the message format, plus a defined set of methods and message types for common tasks (initialization, listing capabilities, calling a tool, etc.). Communication can happen over different transports — typically stdio (standard input/output streams, for local servers launched by a host) or HTTP with Server-Sent Events (SSE) for remote servers. The protocol layer handles how messages are encoded, exchanged, and how the session is managed (e.g. keeping the connection open for multiple requests).

MCP Capabilities (Features):

What exactly can an MCP server expose? The protocol defines three main categories of features a server can provide to an AI model:

Resources — Read-only data that the model can retrieve as context. Resources are like files or documents: they have content the model can read, but fetching them shouldn’t trigger heavy computation or side effects. Examples include the text of a document, the contents of a database record, a wiki page, or any static content identified by a URI(uniform resource identifier). In MCP, resources are often referenced by URI-like identifiers (for instance, a server might define a resource users://{id}/profile to fetch a user profile by ID). The client can request a resource, and the server returns the content to be inserted into the LLM’s context (prompt). Resources ground the AI in real data – instead of relying purely on the model’s training, the model can be provided with up-to-date information on demand.
Tools — Executable functions or actions that the model can invoke (typically with user permission). Tools let the AI do something more than just reading data: they can perform calculations, query an API, send a message, update a record, etc. Each tool is defined with a name, a description, and an input schema specifying what arguments it expects. For example, a server might have a tool get_weather(latitude, longitude) that returns the current weather at given coordinates. An AI model can decide to call this tool when needed – analogous to an LLM using a calculator or calling an API. Tools are powerful because they enable agentic behavior: the AI can act as an agent that not only chats, but also interacts with other systems via these functions.

For example, a tool might allow the AI to send messages, update records, or even send email with MCP through a connected server.
For safety, the client/host usually asks the user to approve tool use before execution. Tools may have side effects or heavy computations, unlike resources which are side-effect free.

Prompts — Predefined prompt templates or conversational workflows that help the model with specialized tasks. Think of prompts as canned guidance or multi-turn templates that can be injected when needed. For instance, a server might provide a prompt template for code review or for debugging an error, structuring how the conversation with the model should proceed. Using a prompt template ensures the AI follows a certain pattern — much like using a standard form or script — which can yield more consistent results for that task. Prompts essentially let the server supply best-practice instructions so the user or client doesn’t have to craft them from scratch each time.

These three feature types aren’t rigid silos — ultimately they all just supply information into the model’s context window (usually as text). However, distinguishing them helps clients handle them appropriately (e.g. tools require parameter passing and user approval, while resources are fetched and inserted as content). In practice, many AI integrations focus heavily on tools (since tools enable active operations), but resources and prompts are equally important for providing passive context and guidance.

Use Cases and Benefits

MCP’s standardized approach brings a number of practical benefits for AI development. For example, developers can send email with MCP easily, streamlining communication tasks within complex workflows.

Here are some further key use cases and advantages of adopting MCP:

In summary, MCP’s benefits boil down to making AI systems more powerful and easier to build. It unlocks richer capabilities for the AI (with real-time, contextual data) while reducing the headache for developers who want to add those capabilities. As the MCP ecosystem grows, we’re likely to see more creative agent behaviors (since models can dynamically discover new tools) and more organizations trusting AI with integrated workflows (thanks to the security and control MCP offers).

Technical Details: MCP Architecture and Workflow

Diving deeper, let’s explore how MCP actually works under the hood — from the initial handshake between a client and server to the way they exchange data. The MCP communication is grounded on JSON-RPC 2.0, a lightweight RPC (Remote Procedure Call) format using JSON. This means every request or response is a JSON object with a defined structure ({"jsonrpc": "2.0", "method": ..., "params": ...}, etc.), making it language-agnostic and easy to parse. Both synchronous requests (with responses) and asynchronous notifications/events are supported.

Connection and Transport: MCP is designed for stateful, long-lived connections between clients and servers, rather than one-off HTTP calls. When an MCP client starts up a connection to a server, it will typically do so in one of two ways:

Local (stdio) transport: If the server runs as a local process (for example, a CLI program or a subprocess launched by the host), the client and server can communicate via the process’s standard input/output streams. This is similar to how the Language Server Protocol often runs language servers as child processes talking over stdio. It’s efficient and avoids network overhead for local tools.
Remote (HTTP + SSE) transport: If the server is a remote service or running separately (e.g., on a server or cloud), MCP can operate over HTTP. In this mode, requests may be sent as HTTP POSTs, and Server-Sent Events (SSE) are used for the server to push responses or events back to the client. SSE allows the server to stream data over an HTTP connection, which is useful if a tool’s result is large or if the server sends incremental updates (imagine streaming a long text or progress updates). In either case, the transport layer is responsible for carrying the JSON-RPC messages reliably.

Initialization Handshake: When a connection is established, the first thing that happens is a handshake to initialize and negotiate capabilities. The client sends an initialize request indicating the MCP protocol version it supports and some info about itself. The server replies with its own version info and the capabilities it offers. This handshake ensures both sides speak a compatible dialect of MCP and agree on basic settings. (For example, if the MCP spec evolves, a client might only support v1.1 and the server v1.2 – they need to find a common ground or fail gracefully.) The handshake may also include initial configuration like what “roots” or scopes the client is requesting. In MCP, roots often refer to the base context or permitted dataset for the server – for instance, a root directory path for a filesystem server, or an account scope for an API server. Clients can provide these so the server knows its boundaries or starting point.

Discovering Server Capabilities: After initialization, the client will usually query what the server can do. MCP defines standard methods to list each type of capability:

tools/list – The client calls this to get a list of all tools the server provides, along with details like each tool’s name, description, and input schema. The server responds with a JSON object containing the list of tools and their definitions. Now the client (and ultimately the LLM) knows what actions are available. Similarly, there are likely resources/list and prompts/list methods (or the client may get these in the initialize response) to enumerate available resource endpoints and prompt templates. With this information, the host can decide how to present or utilize these capabilities. For example, an IDE might show a list of accessible resources (files) to the user, or the client might embed the tool descriptions into the system prompt for the LLM so the model is aware of them.
Using Tools (function calls): When the AI model decides to invoke a tool, the sequence might look like this: The model’s output (to the client) indicates a desire to use a particular tool (e.g., get_weather) and provides the arguments (this could happen via a special response format or function-calling mechanism, depending on the AI). The MCP client then (often after user confirmation) sends a tools/call request to the server with the name of the tool and the arguments to use. For example, {"method": "tools/call", "params": {"name": "get_weather", "arguments": {"latitude": 45.5, "longitude": -122.6}}} would ask the server to execute the weather tool with those coordinates. The server executes the corresponding function (which could involve API calls, database queries, etc.) and returns the result. The result is typically returned in a structured format as part of the JSON-RPC response. In MCP’s design, the server can indicate the type of content in the result; for instance, it might return a JSON object or a text blob, along with metadata like who the intended audience is (the model or the user). In our weather example, the server might respond with {"result": {"content": [{"type": "text", "text": "{\"temperature\": 12, \"conditions\": \"cloudy\", ...}", "annotations": {"audience": ["assistant"]}}]}} – essentially giving the weather data in JSON as text, marked for the assistant to see. The client receives this and injects it into the LLM’s context (e.g., as if the assistant “saw” that text), so the model can use it to formulate its next reply to the user. All of this happens behind the scenes in seconds, making the AI’s interaction with external data feel seamless.
Reading Resources: When a model or user needs some contextual data, the client will request a resource from the server. This could be triggered by the model mentioning a resource URI or by the user explicitly asking for a file. The client sends a resources/read (or similar) request with the identifier of the resource (for example, {"method": "resources/read", "params": {"uri": "users://123/profile"}}). The server then fetches that resource (e.g., looks up user 123’s profile) and returns its content (often as text or structured text). The client can then insert that content into the conversation with the model, typically as part of the prompt (so the model can reference it when answering). Resources might also support partial reading or subscriptions (in case of logs or streaming data), but fundamentally they behave like reading files in a filesystem – you ask for content and you get it.
Using Prompt Templates: Prompt capabilities might be used when the host or user selects a specific template to guide the conversation. For instance, if a user says “help me debug this error” and the server has a debug_error prompt template, the client could fetch that prompt (which may be a series of messages or instructions) and prepend it to the conversation. Under the hood, this could be a prompts/get call or simply provided at connection time. Prompts might also be listed via prompts/list so the client UI could show “available strategies” to the user. Once delivered, the prompt guides the LLM on how to structure its response or interaction.

Session and Lifecycle: MCP’s client-server connection remains active, allowing multiple sequential interactions. The client manages the lifecycle — it can shut down a server when done, or keep it running for as long as the host application is open. If the server provides notifications or events (for example, a file resource might notify if the file changed), those are sent as asynchronous JSON-RPC notifications to the client, which the client can handle by updating the context or informing the user. MCP being stateful also means the server can maintain context across calls if needed (for example, caching data, or keeping track of a user session to an external API).

All these details (methods, message formats, error handling, etc.) are defined in the MCP specification. The goal is that any MCP-compliant client and server implement these same methods and message types, so they can interoperate. The technical design, using JSON-RPC and a client-server model, ensures low coupling: the AI model itself doesn’t directly speak JSON-RPC; it’s the client as an intermediary. This keeps the LLM interface (prompts and responses) separate from the protocol, which is good for security and clarity. The LLM “sees” the results or available tool descriptions, but the JSON API calls happen out-of-band via the client. This design is why you can, for example, use OpenAI’s GPT-4 (which supports function calling) as a host with MCP — the client just maps the model’s function call to an MCP tools/call request, and vice versa. The model doesn’t need to know MCP exists; the client handles it.

In summary, the MCP workflow is: Connect (open channel, handshake) → Discover (what can the server do?) → Use (model/user requests resource or tool, server returns result) → repeat Use as needed → Close (shutdown). Throughout, the heavy lifting of formatting requests and handling responses is done by the MCP client and server libraries, so developers using MCP can focus on the high-level logic (what tools or data to provide) rather than networking details.

Implementation Guide: Using the MCP Python SDK

One of the easiest ways to get hands-on with MCP is by using the Python SDK, which is the reference implementation of the protocol in Python. This SDK allows you to create your own MCP servers (or clients) and experiment with connecting them to AI models. In this section, we’ll walk through setting up the SDK, building a simple MCP server, and running it.

Installation

The MCP Python SDK is available via PyPI. You can install it with a simple pip command. It’s recommended to include the “cli” extra to get command-line tools for testing and running servers:

pip install uv
pip install "mcp[cli]"

This will install the mcp package and related tools. (Alternatively, pip install mcp works for core functionality, or you can use the project’s own environment tool uv as shown in the official docs.

Ensure you have Python 3.10+ as required by the SDK. Once installed, you should be able to run mcp --help in your terminal to see the available commands.

Creating a Simple MCP Server

Let’s build a basic MCP server in Python. This server will demonstrate two types of capabilities — a tool and a resource — to showcase how each is defined.

Example: We’ll create an MCP server(server.py) that can do a simple addition calculation (tool) and provide a greeting message (resource).

# server.py
from mcp.server.fastmcp import FastMCP

# Initialize an MCP server instance with a name
mcp = FastMCP("Demo Server")
# Define a tool function (simple addition)
@mcp.tool()
def add(a: int, b: int) -> int:
 """Add two numbers."""
 return a + b
# Define a resource function (personalized greeting)
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
 """Get a greeting message for the given name."""
 return f"Hello, {name}!"

In this code, we import FastMCP – a high-level class that makes building servers easy. We create an mcp server instance named "Demo Server". Then we use decorators provided by the SDK to register a tool and a resource:

The @mcp.tool() decorator transforms the add function into an MCP tool. By default, the tool’s name will be the function name (add), and the SDK uses the type hints and docstring to automatically generate the input schema and description. This tool simply returns the sum of two integers.
The @mcp.resource("greeting://{name}") decorator registers get_greeting as a resource identified by a URI pattern. The string "greeting://{name}" means this resource can be accessed via a URI scheme greeting:// with a dynamic path (name). If the client later requests greeting://Alice, this function will be called with name="Alice" and return "Hello, Alice!". The docstring can serve as documentation for the resource.
Now click on the local host you will see the MCP inspector.

That’s it — we have a functioning MCP server with one tool and one resource. You could add more tools or resources in a similar way, or even define prompt templates with @mcp.prompt() if needed.

Running the Server

To run this server, you have multiple options:

Development Mode (Inspector): The MCP SDK includes a developer tool called the MCP Inspector that can simulate a client and let you interact with your server. You can launch it with: mcp dev server.pybut before that make sure you have node installed.

This will start your server.py and open an interactive UI where you can test calling the add tool or reading the greeting://... resource. This is very handy for quick testing and debugging.

Direct Execution: You can also run the server as a standalone process. For example, simply execute your script: python server.py
Under the hood, because we used FastMCP, it will automatically run an event loop and wait for a client connection (by default using stdio transport). We could also explicitly call mcp.run() in a if __name__ == "__main__": block to start the server. The server will then await an MCP client to connect via stdio.
Alternatively, the SDK provides a shortcut: mcp run server.pywhich does the same thing — runs your server script and keeps it open for a client.
Integrating with an AI Host: To see the real magic, you would connect this server to an MCP-compatible AI client. If you have Claude Desktop, you can install the server so Claude can use it. For instance: mcp install server.py --name "Demo Server"
This command registers your server with Claude Desktop (the --name gives it a friendly name in the UI). Then, in Claude’s interface, you’d be able to enable and use “Demo Server” as a data source. Claude could call the add tool or fetch the greeting resource as part of conversations. (Typically, you’d prompt Claude with something like “use the Demo Server to add 2 and 3” and it would invoke the tool via MCP.)
If you don’t have Claude, other clients are emerging. For example, you could write a small MCP client script that connects to server.py and issues a tools/call or resources/read – but that’s beyond our scope here. The key is that any MCP client can interface with this server now.

This simple demo barely scratches the surface. With the Python SDK, you can build much more complex servers: connecting to external APIs, wrapping database queries, or even controlling hardware. The SDK supports async functions (as we used in the weather example earlier) and provides utilities for streaming results, handling images, managing authentication, and more. There are also SDKs in TypeScript, Java, and Kotlin with similar functionality, enabling developers to implement MCP servers in the environment of their choice.

MCP is a relatively new entry in the AI tooling space, and it’s natural to ask how it compares to other ways of integrating external data or functions with AI. Here’s a look at a few related concepts and how MCP is different:

Conclusion

In this in-depth exploration, we saw how MCP works, its components (hosts, clients, servers), and the kinds of capabilities it supports (resources, tools, prompts). We walked through technical workflows showing that under the hood MCP is a clean JSON-RPC protocol that any platform can implement. The Python SDK example illustrated that creating an MCP connector is as straightforward as writing a few functions with decorators, immediately making that functionality available to any MCP-aware AI. And when comparing MCP to other approaches, we found that while there are other ways to plug tools into AI, MCP’s open, interoperable design sets it apart as a foundation for a growing ecosystem.

MCP is still evolving (as of this writing, it’s in active development with an open-source community, but its core ideas have struck a chord in the AI community. Major IDEs and assistants have begun adopting it, and developers are rallying to contribute new servers. If you’re building AI applications, it’s worth keeping an eye on MCP — or even trying it out. You might find that instead of re-inventing yet another integration, you can leverage this “USB-C of AI” to connect your model to whatever it needs to know. The end result is AI systems that are more context-aware, capable, and connected to the world around them — a crucial step towards more intelligent and practical AI.

References

Introducing the Model Context Protocol \ Anthropic

What is Model Context Protocol (MCP): Explained in detail — DEV Community

Model Context Protocol (MCP) — NSHipster

What is the Model Context Protocol (MCP)? — WorkOS

Thank you for being a part of the community

Before you go:

Be sure to clap and follow the writer ️👏️️
Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Differ
Check out CoFeed, the smart way to stay up-to-date with the latest in tech 🧪
Start your own free AI-powered blog on Differ 🚀
Join our content creators community on Discord 🧑🏻‍💻
For more content, visit plainenglish.io + stackademic.com

Search across your past Websets

Articles: The Model Context Protocol (MCP), reputable sources

Search Criteria

Enrichments

Find more results