The AI breakthrough developers can't stop talking about: MCP

Dive into MCP (Model Context Protocol), the groundbreaking open standard that seamlessly connects AI applications to real-time data, eliminating custom integration hassles and unlocking new possibilities for developers.

13 mins read

Mar 17, 2025

What if AI tools could work with live data ... without painful custom integrations?

Right now, most AI applications are stuck in the past. They're smart, but disconnected—relying on outdated training data or requiring fragile, one-off API connections. If you've ever hacked together a function-calling system, struggled with vendor-specific integration quirks, or wasted time hardcoding API connectors for every AI tool you use, then you already know the problem.

Enter Model Context Protocol (MCP).

Instead of forcing developers to reinvent the wheel for every AI integration, MCP introduces a standardized, open-source way for AI applications to fetch real-time data, interact with external systems, and execute actions—without endless custom coding.

In today's newsletter, I'm breaking down:

What MCP actually does (and why it matters)
How MCP compares to traditional AI integrations
How to start experimenting with MCP today

Let's go.

What is MCP, exactly?#

Imagine buying the most advanced smartphone ever—but there's a catch: it doesn’t connect to Wi-Fi, Bluetooth, or your cellular network. Weird, right?

The phone has amazing potential, but it can only use the apps and data already stored inside. No software updates, no live sports scores, no way to pull in new information. Frustrating.

Believe it or not, this is how most AI applications worked until recently.

AI apps like Claude are incredibly smart—but stuck in the past. Traditionally, they could only rely on the information they were trained on, just like that disconnected phone.

That's where MCP changes things.

In late 2024, AI researchers at Anthropic decided enough was enough. They realized developers were constantly reinventing the same wheel—building custom pipes to connect AI apps to external systems. Each integration was fragile, repetitive, and inefficient.

Anthropic had a big idea: “What if there was one simple, universal way for AI applications to access external data?”

Thus, the Model Context Protocol (MCP) was born—an open standard released publicly as open-source in November 2024.

MCP is an open standard that allows AI applications to seamlessly fetch and use real-time external data—without the hassle of building custom integrations for every use case.

We can also think of it as a universal connector—like a USB-C port or Wi-Fi—for AI apps. Instead of endless custom coding, developers now only need to integrate each external data source once as an MCP Server, and every MCP-compatible AI app can use that integration seamlessly.

MCP has been widely embraced as transformative for AI development. However, with its rapid adoption, the community has also raised important concerns—especially around security and data privacy.

MCP’s concept may seem intuitive, but let’s peek under the hood—it’s cleverly engineered, just like a modern car designed for safety, efficiency, and ease of use.

Security: Think of MCP’s security like giving a guest limited access to your home—you don’t hand them your primary keys, just the keys to the rooms they need. MCP similarly ensures AI apps only access precisely what they need, reducing the risk of accidentally exposing sensitive information. But just as you’d install security cameras around your home, experts recommend closely monitoring and classifying data to protect it from misuse or unwanted access.
Performance and scalability: Imagine inviting friends to dinner. Traditional APIs are like cooking a completely separate meal from scratch for every guest—time-consuming and exhausting. MCP, however, is like a potluck dinner—each guest brings their own dish, making it easy to add more people without extra effort. Thanks to lightweight JSON-RPC communication, MCP seamlessly supports multiple integrations without slowing down.

Before MCP, integrating AI with external data meant reinventing the wheel for every application—slow, tedious, and inefficient. MCP changed the game entirely, integrating external data is like assembling ready-made furniture with clear instructions. A growing collection of open-source MCP connectors means you spend less time coding integrations and more time creating amazing AI experiences.

How does MCP work?#

Now that we know what MCP is, let’s explore how it works behind the scenes to make AI applications fully connected:

The AI application becomes an MCP client—the curious friend asking questions.
External systems (databases, APIs, documents, etc.) act as small, helpful assistants called MCP servers, ready to answer questions or perform tasks.
Whenever our AI needs fresh information, it politely sends a clear, structured request like “Hey, can you fetch today’s sales numbers?” or “Can you give me the weather forecast right now?”
The MCP Server quickly finds or computes the needed data and responds directly.
The AI application instantly incorporates this fresh data into its responses, giving real-time, accurate answers.

As a result, MCP transforms isolated, smart—but limited—AI applications into dynamic, connected assistants. Just as connecting your powerful smartphone to the internet finally unleashes its true potential, MCP unlocks the full capabilities of AI apps.

Developers no longer need to endlessly build custom integrations for every different AI application. Instead, they set up their data sources as MCP Servers once—and voilà! Every MCP-compatible AI app can seamlessly leverage that same data. Consider these key points:

Client-agnostic integration: The AI client could be the Claude desktop application, an IDE, or even one of your applications. As long as the client supports MCP, everything just works.
Plug-and-play flexibility: Need to switch to a different AI application or tool? No problem—just plug in the new MCP-compatible client, and all your existing data integrations remain intact and instantly accessible without additional coding.

This is the magic of MCP: a standardized connector that enables AI applications to interact dynamically with the outside world, making your AI smarter, more flexible, and significantly more powerful.

How MCP stacks up against existing AI context methods#

If you’re thinking, “Wait, didn’t we already have ways to connect AI models to external data?”—yes! You’re absolutely right. But these earlier methods had their quirks, complexities, and limitations.

Let’s quickly unpack how MCP compares with these older approaches so you can appreciate why MCP has developers excited.

Previously, developers gave AI applications/models direct access to complete APIs—imagine giving an AI assistant full control over your Gmail account. It could potentially read, delete, or manage emails without restrictions. Each integration required developers to carefully handle permissions and build custom connectors for every API and each specific AI model separately. It wasn’t just tedious; it posed major security and privacy risks.

With MCP, things are different. Instead of handing AI models the primary key to your entire API, developers can expose only specific actions the model needs. Want your AI application to only read emails but never delete them? MCP makes that simple and safe by providing fine-grained control, drastically reducing security risks and unnecessary complexity.

Another method providers used was proprietary function calling, which let AI models invoke predefined actions directly. Think of these as brand-specific universal remotes: each works well but only with devices of the same brand. OpenAI had its format; Anthropic had another. Switching your AI provider meant redefining functions from scratch.

MCP standardizes this across AI platforms, offering one universal “remote” compatible with any AI model. It also adds advanced features like structured data retrieval (resources) and reusable prompt templates—powerful tools missing from earlier proprietary solutions.

To make these differences crystal clear, here’s a side-by-side table that summarizes the key points at a glance:

Aspect	Direct API Access	Proprietary Function Calling	Model Context Protocol (MCP)
Basic Concept	AI model directly calls an API, often using full credentials or tokens.	AI model is granted access to a set of “functions” (like an internal remote-control), typically in a vendor-specific format.	AI model interacts with a standardized “MCP Server” that exposes resources, tools, and prompts, giving finely controlled access.
Security Model	High risk if not carefully managed (the AI may have full access to the API).	Some risk; each vendor’s approach to permissions and scope can vary.	Fine-grained permissioning (only expose specific actions/data). Still requires careful setup, but drastically reduces risk of accidental data leaks.
Integration Complexity	Each API integration must be built from scratch; overhead in customizing requests, handling auth.	Fewer lines of code than raw APIs (the AI “calls” a function), but each AI vendor has a distinct function format, requiring rewrites.	Integrate each external system once (as a server), then any MCP-compatible AI app can leverage it. Reusable, “plug-and-play” integrations.
Vendor Lock-In	None with standard APIs, but each integration is custom—migrating to new AI models can be tedious.	High lock-in with a specific AI vendor’s function-calling spec (e.g. OpenAI vs. Anthropic).	Low lock-in—MCP is an open standard. You can switch AI models or front-end clients without rewriting how you expose data or tools.
Scalability	Potentially high (e.g. you can create multiple API keys), but each new integration is manual.	Typically limited to the scope of that vendor’s function-calling environment.	Offers a universal “hub.” Adding more AI clients or data sources is straightforward—just register them with the MCP Server.
Features Beyond Data	Purely raw data. No built-in concept of “tools” or “prompts” to guide AI.	Some advanced function calls allow for custom logic, but often limited or brand-specific.	Not just data—MCP also supports powerful, standardized tools and prompts (e.g., structured queries, pre-made templates) that any AI model can discover and use.

MCP server resources#

Imagine you have a giant library of useful information—files, database records, screenshots, logs, and more. In the MCP world, these are called resources. They’re essentially the data that the server makes available to the AI client.

Resources can be anything from the text inside a file to a snapshot of your system’s current status. Each resource is identified by a unique URI (like an address): file:///home/user/documents/report.pdf or postgres://database/customers/schema.

The client application decides when and which resources to use. Some clients, like Claude Desktop, ask you to explicitly select which resource to load, while others might pick them automatically based on smart heuristics. Sometimes, the AI model itself may even decide which resource it needs!

Here’s an example from their official documentation of implementing resource support in an MCP server:

Python 3.10.4

from mcp.server import Server, stdio_server
import mcp.types as types
from pydantic import AnyUrl
app = Server("example-server")
@app.list_resources()
async def list_resources() -> list[types.Resource]:
    # We return a list describing what resources our server provides
    return [
        types.Resource(
            uri="file:///logs/app.log",   # Unique address for our log file
            name="Application Logs",
            mimeType="text/plain"
        )
    ]
@app.read_resource()
async def read_resource(uri: AnyUrl) -> str:
    # When the client asks to read a resource, this function is called
    if str(uri) == "file:///logs/app.log":
        # Here we’d load the content of the log file from disk
        log_contents = await read_log_file()
        return log_contents
    raise ValueError("Resource not found")
# Start server (stdin/stdout)
async with stdio_server() as streams:
    await app.run(
        streams[0],
        streams[1],
        app.create_initialization_options()
    )

The code snippet above sets up an MCP server that exposes a resource—the application log file. The @app.list_resources() decorator defines a function that returns available resources, while @app.read_resource() handles fetching the contents of a given resource. Finally, the server is started and listens for incoming requests.

By making data accessible on demand, resources let the AI step beyond its original training data. This means when your AI needs up-to-date or specific information, it can simply ask for the relevant resource rather than relying on outdated static data.

MCP server tools#

Think of tools as the server exposing executable functions to the AI. While resources let you read data, tools let the AI take action—like a universal remote that works with every device.

Tools are like mini-programs that the server makes available. They can perform everything from simple calculations to interacting with external APIs.

For instance, a tool might add two numbers or even create a GitHub issue. Each tool is defined with a clear name, a description, and a JSON schema that tells the AI what inputs it expects. When the AI wants to act, it sends a structured request to the tool. The server then executes the function and sends back the result.

Here’s an example from their official documentation of implementing a basic tool in an MCP server:

Python 3.10.4

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    # We define the tools we want the AI to be able to call
    return [
        types.Tool(
            name="calculate_sum",
            description="Add two numbers together",
            inputSchema={
                "type": "object",
                "properties": {
                    "a": {"type": "number"},
                    "b": {"type": "number"}
                },
                "required": ["a", "b"]
            }
        )
    ]
@app.call_tool()
async def call_tool(
    name: str,
    arguments: dict
) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]:
    # When the AI calls a tool, we match the name and execute it with the given arguments
    if name == "calculate_sum":
        a = arguments["a"]
        b = arguments["b"]
        result = a + b
        # Return result as text
        return [types.TextContent(type="text", text=str(result))]
    raise ValueError(f"Tool not found: {name}")

In this example, the server declares a tool called calculate_sum that adds two numbers. The @app.list_tools() decorator provides a list of available tools and @app.call_tool() defines how the tool is executed when the AI calls it. If the tool is invoked with the proper arguments, it returns the sum as text.

Tools are designed to be model-controlled. This means they’re intended to be invoked automatically by the AI (with human approval when needed). By standardizing these functions, MCP removes the need for custom code for each integration ... making your life as a developer much easier.

MCP server prompts#

Prompts are like prewritten templates or scripts that guide the AI in handling specific tasks. They help standardize how the AI interacts with users or data, making the whole process smoother.

A prompt in MCP is essentially a reusable template that can accept dynamic arguments. It is a fill-in-the-blanks instruction set that the AI can follow. For example, a prompt might be designed to generate a Git commit message based on a description of code changes. The client discovers prompts through a simple list endpoint.

When the AI needs to use a prompt, it sends a request with the necessary arguments (like a programming language or a code snippet), and the server returns the pre-constructed messages that guide the AI’s response.

Here’s an example from their official documentation of implementing prompts in an MCP server:

Python 3.10.4

from mcp.server import Server
import mcp.types as types
# Define available prompts
PROMPTS = {
    "git-commit": types.Prompt(
        name="git-commit",
        description="Generate a Git commit message",
        arguments=[
            types.PromptArgument(
                name="changes",
                description="Git diff or description of changes",
                required=True
            )
        ],
    ),
    "explain-code": types.Prompt(
        name="explain-code",
        description="Explain how code works",
        arguments=[
            types.PromptArgument(
                name="code",
                description="Code to explain",
                required=True
            ),
            types.PromptArgument(
                name="language",
                description="Programming language",
                required=False
            )
        ],
    ),
}
@app.list_prompts()
async def list_prompts() -> list[types.Prompt]:
    # Return our predefined prompts so the AI knows what's available
    return list(PROMPTS.values())
@app.get_prompt()
async def get_prompt(name: str) -> types.Prompt:
    if name in PROMPTS:
        return PROMPTS[name]
    raise ValueError("Prompt not found")
@app.render_prompt()
async def render_prompt(name: str, arguments: dict) -> list[types.Message]:
    # Combine the prompt template with user-provided arguments
    if name not in PROMPTS:
        raise ValueError("Prompt not found")
    prompt = PROMPTS[name]
    # Build or "render" the actual text messages
    messages = [
        types.Message(role="system", content=f"You are generating {name}."),
        types.Message(role="user", content=str(arguments))
    ]
    return messages

With prompts, you don’t have to reinvent the wheel for common tasks. They help the AI consistently deliver quality responses by providing a structured, context-rich starting point. And because prompts can be updated and versioned, they evolve with your application’s needs.

An MCP server combines these three components—resources, tools, and prompts—to create a seamless ecosystem for AI interactions. Resources provide the raw data, tools let the AI perform actions, and prompts guide the conversation. Together, they transform static AI models into dynamic, real-time assistants that can understand and act on up-to-date information.

How to build your own MCP servers#

Building your own MCP server can be complex, but it is possible with a deep dive into the documentation and by developing comfort with the underlying technology.

If you’re eager to get started and get your hands dirty, here’s a shortcut: You can download the full MCP documentation file and feed it directly to your LLM.

Then, simply add a structured prompt that explains exactly what kind of server you want to build. Be as specific as possible about the following:

What resources your server will expose: For example, will it serve database records, log files, or API responses?
What tools it will provide: List the functions you want the AI to be able to invoke. For instance, simple calculations, API calls, or system operations.
Any prompts it should offer: Define reusable templates that guide common workflows or interactions.
What external systems does it need to interact with: Specify databases, APIs, or other software systems the server will integrate with.

For example, imagine you want to build an MCP server that handles bug reports. Here’s a sample prompt you might feed to your LLM:

Build an MCP server that:

Connects to our Sentry bug-tracking system to receive bug reports.
Exposes the bug report details (like error messages and stack traces) as resources.
Provides tools for analyzing bug reports and accessing the company’s codebase so that AI can determine the root cause.
Offers prompts for common workflows, such as automatically generating a pull request on GitHub to fix the issue and triggering the build process once the fix is merged.

This approach lets you quickly prototype your MCP server without immediately getting bogged down in every technical detail.

If you’re looking for inspiration or a head start, you can find many MCP servers already built for various use cases on Composio—a great repository of integrations.

What is the biggest challenge facing MCP adoption?#

Now, let’s address a practical, real-world question: How does one MCP server handle more than one client simultaneously, and can it be deployed on serverless platforms like Vercel or AWS Lambda?

By default, many simple MCP server demos store the transport or connection in a single in-memory variable, meaning only one client can connect simultaneously. Even if you track multiple transports in memory, you end up with a stateful server that doesn’t gracefully survive restarts. The solution is storing connection information in an external data store—like Redis or any key-value database—so the server can be stateless. That way, you won’t lose your active connections if you deploy to a serverless environment (where instances spin up and down all the time). It’s a small extra step, but it frees you from the dreaded “single client only” trap, making your MCP server production-friendly.

Several teams have paved the way by open-sourcing examples of how to store state in Redis, handle concurrency, and keep everything ephemeral-friendly. Yes, it’s a touch more overhead than a purely in-memory approach, but you gain the enormous benefit of scaling seamlessly—and not worrying about your server vanishing when the platform recycles containers. If you aim to go big with MCP in a real-world environment, you’ll want this stateless approach in your toolkit.

Also, even though MCP limits which resources and actions an AI model can access, you still give a powerful model some real-world control. In practice, that’s been safe so far—no glaring red flags have emerged. Still, as with any evolving technology, it pays to stay vigilant.

What’s next for MCP?#

MCP is still in its early days, with tight integration around Claude models and limited support for OpenAI, LangChain, or LlamaIndex—for now. But the ecosystem is evolving fast, and broader adoption feels inevitable.

Industries from fintech (Block's automated financial reporting) to software development (tools like Replit and Sourcegraph) and even healthcare and cybersecurity are already exploring MCP's transformative potential.

Soon, we can expect to see extended compatibility, more open-source connectors, and new industry applications that push AI capabilities beyond what we've experienced until now.

If you’re an AI developer, now is the time to start experimenting—because MCP might just redefine how AI applications interact with the real world.

Three ways to dive in:

MCP Fundamentals for Building AI Agents - Master the basics of MCP to build AI agents fast and effectively.
Exploring OpenAI API – Learn how to work with OpenAI's API and integrate external data sources.
Essentials of Large Language Models: A Beginner's Journey – Understand how modern LLMs work and their basic architecture.

And in the meantime, stay tuned for updates as MCP continues to mature.

Written By:

Usama Ahmed

The AI Infrastructure Blueprint: 5 Rules to Stay Online

Whether you’re building with OpenAI’s API, fine-tuning your own model, or scaling AI features in production, these strategies will help you keep services reliable under pressure.

9 mins read

Apr 9, 2025

The AI breakthrough developers can't stop talking about: MCP

What is MCP, exactly?#

How does MCP work?#

How MCP stacks up against existing AI context methods#

The main components of an MCP server#

MCP server resources#

MCP server tools#

MCP server prompts#

How to build your own MCP servers#

What is the biggest challenge facing MCP adoption?#

What’s next for MCP?#