Dear Ben… What is MCP (Model Context Protocol)?

Building AI agents requires live data, action-taking, and memory – MCP provides a foundation for that world.

Apr 10, 2025

LLMs are getting more capable, but are still siloed by default. Each integration is bespoke, every model has its own quirks, and context still resets between apps.

Retrieval Augmented Generation (RAG) has been a popular attempt to solve this problem. While RAG works, there’s a new term creating buzz – MCP.

Model Context Protocol (MCP) is a proposed standard that aims to make connecting AI applications to external data sources easier.

I have been struggling to understand how MCP stands out amongst dozens of existing solutions and the reason why we need a common standard. Every post online is about “how MCP works”, but I want to understand why we should care about it.

So we did some research and spoke to our community to identify some key questions that we answer. Hopefully it helps you get a better look at MCP, keeping all the hype aside.

Let’s start broad.

Q1: What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open, standardised protocol suggested by Anthropic (the makers of Claude).

Think of it as a set of rules designed to act as a two-way communication bridge. This bridge connects AI models to the outside world – external tools, data sources, applications, and services that live outside the AI's initial training data.

Its core purpose is to solve a fundamental limitation: AI models are often trained on vast but static datasets with a "knowledge cutoff" date. They don't inherently know about current events or have access to your specific private data (like your company's internal knowledge base or your real-time calendar).

MCP aims to provide a structured, secure, and universal way for AI to:

Request and receive specific, relevant context from these external sources when needed.
Potentially trigger actions in those external tools (e.g., update a record, send a message).
Handle metadata about the context (like where the data came from, how fresh it is) to ensure reliability.

a way for the chatbot to interact with and control other software on your computer
- Wyatt Barnett

Q2: But OpenAI and Anthropic already have "function/tool calling" features, how is MCP different? I still have to define tools, right? The coding complexity seems similar.

This is a crucial point, especially for developers. You're right that at first glance, the immediate task of defining a tool might feel similar. The core difference lies less in the initial coding effort for a single integration and more in the long-term vision of standardisation vs. proprietary implementations:

Proprietary tool calling: Features like OpenAI's function calling or Anthropic's tool use are specific to that provider's system. The way you define the tool, the format the AI model expects, and how the interaction works are all tied to their unique API. If you decide to switch your underlying AI provider, you essentially have to rebuild that integration layer to match the new provider's requirements. It locks your integration into their specific ecosystem.
MCP's goal - standardisation & interoperability: MCP aims to be a universal standard, independent of any single AI provider. The ambition is:
- Server-side reusability: A company (like Salesforce) could build one MCP server exposing its tools (e.g., "fetch_contact_record"). Any AI application designed as an MCP client could potentially use that server, regardless of whether its "brain" is powered by OpenAI, Anthropic, Cohere, or something else.
- Client-side flexibility: As an application developer using an MCP client structure, you could connect to various tools that offer MCP servers. More importantly, you could potentially swap the underlying AI provider powering your application without rewriting all your tool integrations, assuming the new provider also supports the MCP client role.
Decoupling & ecosystem: MCP aims to decouple the tool from the AI provider. This separation fosters a potential ecosystem where tool providers offer standard MCP endpoints, and AI developers consume them using standard MCP client patterns. Current proprietary methods keep these integrations siloed within each provider's walled garden.
Beyond basic calls: MCP specifications also include concepts for stateful sessions (allowing more complex, multi-step interactions with a tool than simple request-response) and potentially standardised capability discovery.

So, while the coding complexity for one specific, custom-built tool might feel similar today, MCP's proposed value lies in reusability, avoiding vendor lock-in for integrations, and enabling a more open, interconnected ecosystem in the long run. If standard MCP servers become common, plugging them into your app should be simpler than writing bespoke function-calling logic for each one.

Q3: This sounds very developer-focused. Does it matter for the end-user if a data source is connected via MCP versus some other direct integration? An end-user of my app doesn't need to learn MCP, right?

You've nailed it.

Completely transparent to users: For the person simply using the AI application (chatting with a bot, using an AI assistant), the underlying mechanism like MCP is invisible and irrelevant. It's backend plumbing. They won't know or need to care whether the weather information came via an MCP connection or a custom API call.
No user burden: Absolutely no end-user needs to learn or understand MCP.
Developer & admin realm: MCP lives firmly in the world of the software developers building the AI applications and the systems providing the external data, and perhaps the IT administrators managing integrations and security permissions within an organization.

The benefit to the end-user is indirect. If MCP successfully makes it easier, faster, and more secure for developers to integrate more tools and capabilities into AI applications, the user ultimately gets a potentially more powerful, helpful, and up-to-date application.

💡Note: MCP servers can be added to desktop AI apps like plugins by editing some files on your system – kinda like installing mods for a video game. But with the recent pace of adoption, this complexity will likely be dealt with by developers.

Q4: Let's get a bit more technical. When a developer writes code, they don't usually need to explicitly import libraries for using HTTPS, but it sounds like they do need specific libraries or imports for MCP. Why is that different?

That's an excellent observation about different layers of software abstraction.

HTTPS: This is a fundamental transport layer security protocol (SSL/TLS over HTTP). It's deeply integrated into operating systems and the standard networking libraries developers use. When you use a modern HTTP client library (like Python's requests or JavaScript's Workspace), that library automatically handles the complex HTTPS negotiations (the handshake, encryption/decryption) when you connect to a https:// URL. The developer works at the HTTP level (sending requests, receiving responses) and the lower-level security is largely abstracted away.
MCP: This is a higher-level application layer protocol. It defines a specific way for applications to structure their conversation – rules about roles (Client, Server, Host), message formats (likely using standards like JSON-RPC), the sequence of interactions, how to manage state in a session, how to negotiate capabilities, etc. Because MCP dictates these specific application-level rules, developers need dedicated MCP libraries or SDKs. These libraries provide the necessary functions and structures to correctly format MCP requests, parse responses according to the MCP standard, manage MCP sessions, and generally handle the protocol's logic without the developer needing to implement the entire MCP specification from scratch using raw HTTP messages.

The key difference: HTTPS is foundational plumbing handled by standard network/HTTP libraries. MCP is a specific recipe for how AI components should talk to each other over secure connections like HTTPS, requiring its own set of tools (libraries) to follow that recipe correctly.

Q5: So, can companies support MCP by essentially wrapping their existing APIs inside an "MCP Server"? And where would that server actually live – on my machine, or theirs?

Yes, wrapping existing APIs: That's exactly the idea. A company wanting its data or tools to be accessible via MCP would build an MCP Server. This server acts as a standardised adapter. It listens for incoming requests formatted according to the MCP protocol, translates those requests into calls to the company's internal APIs or databases, takes the results, and then formats them into standard MCP responses to send back to the requesting MCP client.
Server hosting: This MCP server is a network service, so it needs to be hosted somewhere accessible. Typically:
- Provider's infrastructure: The most common scenario is that the company providing the data or tool (like Salesforce, Google, Atlassian, etc.) would host and manage the official MCP server endpoint in their own cloud infrastructure (like AWS, Azure, GCP) or data centres. This makes sense because they control the underlying service and can manage performance, security, and updates.
- Internal/on-premises: For tools used only within a specific company, the MCP server could be hosted on their private network.
- Developer's machine (limited use): While a developer could run an MCP server locally for testing or wrapping a local resource (like a database on their machine), this isn't how you'd typically connect to major third-party services.

In short: You connect your AI application (acting as an MCP client) to the MCP server that is hosted and managed by the entity providing the external tool or data service.

Q6: Reading the documentation and thinking about this, MCP feels a bit like React for JavaScript frontend. You could use vanilla JS, but React became the standard way many developers to build complex UIs because it provides structure and improves the process. Is it logical to say MCP wants to be the "React for connecting AI to your data"?

It’s a smart comparison… Let's break it down a bit:

The aspiration: Your framing – MCP wants to be the "React for connecting AI to your data" – captures the spirit well. Just as React provided a structured, component-based approach that became the de facto standard for building complex JavaScript UIs (offering benefits over manipulating vanilla JS directly), MCP aims to provide a standardised, structured approach for the complex task of integrating AI models with diverse external data sources and tools.
Why it fits (better than USB-C/HTTPS):
- De facto vs. universal: React isn't the only way to build web UIs, but it became a dominant, preferred standard through adoption and proven utility. Similarly, MCP is being proposed as a standard way to do AI-data integration. Its success isn't guaranteed; other methods might persist or emerge. This contrasts with HTTPS or USB-C, which are deeply embedded, universal standards with little fragmentation in their core domains. MCP is still in the phase where it needs to prove its value to gain widespread adoption, much like React did in its earlier days.
- Structure and developer experience: Both aim to impose a structure and improve the developer experience for complex tasks, promoting reusable components (React components, potentially reusable MCP servers/tools) and established patterns.
Where it differs: As we noted, React is a library/framework for building UIs, while MCP is a protocol/standard for communication between systems. But the core idea of establishing a preferred, standardized, and more efficient way to handle complexity holds.

So, yes, thinking of MCP as aspiring to be the "React for AI-data integration" – the go-to, standardised method that brings structure and efficiency to a complex problem, but whose widespread adoption isn't yet a foregone conclusion – seems like a logically sound and useful way to understand its goals and current position.

Just like USB lets you connect different devices to your computer without needing special knowledge about each device, MCP lets AI assistants connect to different services without needing custom configuration for each one. You plug in the MCP "connector," and the AI can immediately understand what tools are available and how to use them.

How It Works
- An AI assistant uses an "MCP client" (like a USB port)
- This client connects to an "MCP server" (like a USB cable)
- The server connects to various services like search engines, file systems, or other tools
- The AI can ask "what tools do you have?" and automatically learn how to use them

The Big Benefits
Discovery: AI can automatically find what tools are available
Learning: AI gets prompt templates that teach it how to use the tools effectively
Evolution: As tools improve or new ones are added, the AI immediately gets those benefits without you needing to update anything
Access to Resources: The AI can access files, databases, screenshots, or whatever the service provides

In Plain Language...Without MCP, teaching an AI to use a tool is like giving it a detailed instruction manual for each individual tool. With MCP, it's more like the AI walking into a workshop and being able to ask "what can I do here?" and the workshop itself explains what each tool does and how to use it.This is still an evolving standard, and it's not perfect yet, but it represents a big step toward making AI assistants more capable and easier to work with - they can adapt to new tools without someone having to rewire them each time.

- Christian Roy

Summing it up

Model Context Protocol (MCP) is an effort to standardise how AI models interact with external tools and data. It’s not introducing radically new capabilities, but it does offer a cleaner, reusable, and vendor-neutral way to build those integrations.

For developers, MCP could:

reduce complexity
avoid lock-in
and make it easier to build AI systems that are context-aware and up to date

For end users, it means AI that feels more connected, relevant, and useful, without needing to understand what’s happening behind the scenes.

Whether MCP becomes the dominant standard remains to be seen, but it’s already getting its fair share of love.

Sources and extra reading:

Explanations:

Building:

Written by Keshav. Edited by Shanice and Ben. Includes contributed sources, questions or info by community members; Millidude, Wyatt Barnett, Mike Rhodes, Christian Roy, Rael Cline, Alexander Orlov and Amie Pollack.