What Is MCP? Model Context Protocol Explained

TL;DR: MCP (Model Context Protocol) is an open standard from Anthropic that gives AI applications one consistent way to connect to external tools and data. It replaces a tangle of custom, per-model integrations with a single client-server protocol. MCP is not RAG and not just function calling. It is the connection layer that lets any MCP client use any MCP tool, and it is now the default way serious AI workflows reach the outside world.

What Is MCP?
Why MCP Exists: The M×N Problem
How MCP Works
MCP vs Function Calling
MCP vs RAG
MCP vs Traditional APIs
What You Can Build with MCP
MCP Security Considerations
MCP in Heym
How to Get Started with MCP
Common Mistakes
Key Takeaways
FAQ

What Is MCP?

Definition: The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, that defines a single client-server way for AI applications to discover and use external tools, data sources, and prompts. The model stays the same. The integration becomes one protocol instead of one bespoke connector per tool.

Every useful AI system eventually needs to reach outside the model. It has to read a database, search a codebase, file a ticket, or call an internal API. Before MCP, each of those connections was a custom piece of glue code, written differently for every model and every tool. MCP turns that glue into a standard.

The common analogy is a USB-C port for AI applications. A laptop does not ship a different physical port for every monitor or drive. It exposes one standard port, and any compliant device plugs in. MCP gives AI clients that same standard port for tools and data.

MCP is open source and model-agnostic. It started at Anthropic, but through 2025 it was adopted across the industry, including by OpenAI, Google, and Microsoft tooling. That broad adoption is why MCP matters: a tool you expose once is reachable from many AI clients, not locked to one vendor.

Why MCP Exists: The M×N Problem

Picture a team running three AI clients and ten internal tools. Without a standard, every client needs its own connector to every tool. That is thirty integrations to write and maintain. Add a fourth client and you write ten more. This is the M×N integration problem, and it grows fast.

MCP collapses M×N into M+N. Each tool is wrapped once as an MCP server. Each AI client implements the MCP client side once. Now three clients and ten tools is thirteen pieces of work, not thirty, and every new tool is reachable from every client for free.

Key principle: MCP does not give models new abilities. It removes the integration tax that used to make those abilities expensive to wire up. The value is standardization, not magic.

Notable fact: MCP started at Anthropic in November 2024, but OpenAI announced support in March 2025, and Google and Microsoft added MCP across their AI tooling during 2025. That cross-vendor adoption inside a single year is why MCP is treated as an industry standard rather than one vendor's protocol (Model Context Protocol, Wikipedia, 2026).

This is the same shift that happened with database drivers, language server protocols, and container runtimes. The protocol becomes boring infrastructure, and that is exactly the point. Boring, standard infrastructure is what lets teams build on top without renegotiating the basics every time.

How MCP Works

MCP has a small, well-defined architecture. There are three roles, a message format, a set of transports, and a set of primitives. Once you know those four pieces, the protocol is straightforward.

Definition: An MCP server is a program that wraps a set of tools, data resources, or prompt templates and exposes them over the protocol. An MCP client is the component inside an AI application that connects to servers, lists what they offer, and invokes them on the model's behalf. The host is the AI application itself, such as a desktop assistant or a workflow engine.

The three roles. The host is the application a person uses. Inside it, one or more MCP clients each hold a connection to one MCP server. Servers are independent and composable, so a host can talk to a GitHub server, a database server, and an internal server at the same time without any of them knowing about each other.

The message format. MCP messages use JSON-RPC 2.0. Every request, response, and notification is a structured JSON-RPC message, which keeps the protocol language-neutral and easy to implement in any stack.

The transports. A local server typically uses stdio, communicating over standard input and output on the same machine. A remote server uses Streamable HTTP, the network transport defined in the 2025 specification, which superseded the earlier HTTP plus Server-Sent Events approach that many deployed servers still use. Local is simple and private. Remote is shared and authenticated.

The primitives. Servers expose three core primitives. Tools are actions the model can invoke, such as "create issue" or "run query". Resources are readable data the model can pull in as context, such as a file or a record. Prompts are reusable templated instructions a server can offer. Together these cover reading context, taking action, and standardizing instructions.

A typical exchange runs like this. The client connects and asks the server what it offers. The server returns its tools, resources, and prompts. The model, through the host, decides to call a tool. The client sends a JSON-RPC request, the server executes it, and the result returns to the model as context for its next step.

MCP vs Function Calling

This is the most common point of confusion, so it is worth being precise. Function calling and MCP are not competitors. MCP is built on top of the idea of tool use that function calling introduced, and it standardizes it across models and processes.

Dimension	Function Calling	MCP
What it is	A model feature: the model emits a structured call to a function you defined	A protocol: a standard client-server layer for exposing and invoking tools
Scope	One model, one application, functions defined inline	Many clients, many tools, defined once and reused
Reusability	Rewritten per model and per app	Write the server once, any MCP client uses it
Discovery	You hardcode the function list	The client asks the server what tools exist at runtime
Process boundary	Usually in-process with the app	Tool runs as a separate local or remote server
Best for	A few private functions tied to one model	Reusable, shareable tools across clients and teams

A useful way to hold it in your head: function calling is how a model says "I want to call this". MCP is how that call reaches a tool in a standard, reusable way no matter which model asked.

MCP vs RAG

MCP and RAG are often mentioned together and confused just as often. They solve different problems and frequently run side by side in the same system.

Definition: RAG (Retrieval-Augmented Generation) retrieves relevant passages from a knowledge base, usually a vector database, and injects them into the model's prompt so it can answer with information it was not trained on. It is a knowledge-grounding pattern, not a connection protocol.

Dimension	RAG	MCP
Problem it solves	The model lacks knowledge	The model lacks a standard way to reach tools and live systems
Direction	Read-only: fetch text into context	Read and act: query data and trigger actions
Typical backend	Vector database of embedded documents	Any tool, API, database, or workflow wrapped as a server
State changes	None, retrieval only	Yes, tools can create, update, and delete
Freshness	As fresh as the last index update	Live at call time
Used together?	Yes, MCP can expose a retrieval tool that runs RAG	Yes, an MCP tool can itself be a RAG pipeline

The cleanest mental model: RAG changes what the model knows for one answer. MCP changes what the model can reach and do across a session. A production assistant often uses RAG to ground answers and MCP to take action on what it found.

MCP vs Traditional APIs

If a tool already has a REST API, why wrap it in MCP? Because a REST API is designed for programmers who read documentation, and an MCP server is designed for models that discover capabilities at runtime.

Dimension	Traditional API	MCP Server
Consumer	A developer reading docs	A model discovering tools at runtime
Discovery	Out-of-band documentation	Built into the protocol, queried live
Schema	Varies per API	Standard JSON-RPC and tool schema
Auth	Per-API conventions	Standard patterns, token or key based
Reuse across AI clients	Custom adapter each time	One server, every MCP client

MCP does not replace your APIs. It is a thin, model-friendly layer in front of them. The REST API still does the work. The MCP server makes that work legible and callable for any AI client without a hand-written adapter.

What You Can Build with MCP

The use cases follow directly from the primitives. Anything you can wrap as a tool, resource, or prompt becomes available to every connected AI client.

Developer assistants that read a repository, run tests, and open pull requests through a code MCP server.
Data agents that query a production database through a read-scoped Postgres MCP server and summarize results.
Support automation that pulls a customer record, checks an order system, and files a ticket, each step a separate MCP tool.
Internal operations bots that expose company workflows as MCP tools so any approved AI client can trigger them safely.
Research assistants that combine a web-search MCP server with an internal knowledge MCP server in one session.

The pattern is always the same. Wrap the capability once, scope its permissions, and it becomes reusable across every client and every workflow that speaks MCP.

MCP Security Considerations

Because MCP lets models take real actions, security is not optional. The protocol is a transport, so the safety properties come from how servers are built and deployed.

Key principle: Treat every MCP tool as a privileged action surface. The risk is not the protocol, it is an over-permissioned or unauthenticated server that a model can be manipulated into misusing.

The main risks and their mitigations:

Prompt injection through tool metadata. A malicious server can put instructions in tool names or descriptions. Mitigation: only connect servers you trust, and treat tool descriptions as untrusted input.
Over-broad permissions. A database tool with write access when it only needs read is a standing hazard. Mitigation: scope every tool to the minimum permission it needs.
Unauthenticated remote servers. A reachable remote server with no auth is an open door. Mitigation: require an API key or OAuth token on every remote server.
No audit trail. If you cannot see what tools ran, you cannot investigate. Mitigation: log every tool call with inputs and outputs.

Notable fact: Independent security analysis in 2025 found that a large share of internet-exposed MCP servers were running with no authentication at all, and that tool poisoning and prompt injection through tool descriptions were the primary attack vectors against MCP deployments (Red Hat, 2025).

These are operational controls, not protocol features, which is why the platform you run MCP on matters as much as the protocol itself.

MCP in Heym

Heym is a source-available, self-hosted AI-native workflow automation platform with a visual canvas. We built MCP into it as a two-way capability, because in practice teams need both directions. Sometimes a workflow needs to consume an external tool. Sometimes the workflow itself should be the tool that an AI client calls.

Consuming MCP tools inside a workflow. Register an MCP server in the MCP panel, then use it on the canvas in one of two ways. The MCP Call node invokes a specific tool deterministically when you already know which one you need, with no model in the loop.

The Agent node takes the other path. It attaches the whole server so the model can choose which tools to call and chain them across multiple steps. For a step-by-step build, see how to build an MCP server and the curated best MCP servers for 2026.

Exposing a workflow as an MCP server. Toggle MCP on any workflow and Heym publishes it as a callable tool. The default server exposes every MCP-enabled workflow under one endpoint. Named servers give a group of workflows their own URL and API key, which keeps team boundaries clean. Any MCP client, including Claude and Cursor, can then call your workflow as a tool, authenticated with an API key or OAuth token, with every invocation written to the trace log.

This two-way design is the practical payoff of a standard protocol. The same Heym workflow that consumes a GitHub MCP server can itself be exposed as an MCP tool to a desktop assistant, with no extra integration code on either side. It fits naturally into a broader AI workflow automation practice, and pairs well with the patterns in how to connect two APIs in a workflow.

How to Get Started with MCP

You do not need to learn the entire specification to use MCP well. Start by consuming one server, then expose one workflow. The full sequence is in the steps at the top of this guide, but the short version is four moves.

First, pick one external MCP server that removes real toil, such as GitHub or Postgres, and connect it. Second, wire it into a workflow with an MCP Call node for a fixed step or an Agent node for model-driven tool choice. Third, toggle MCP on one of your own workflows to publish it as a tool. Fourth, point an MCP client at it and confirm the call in the trace log.

Once that round trip works, MCP stops being a concept and becomes plumbing you reach for by default.

Common Mistakes

Treating MCP as a replacement for RAG. They are different layers. Use RAG to ground knowledge and MCP to reach tools. Many systems need both.
Exposing one giant tool. A single tool that does everything is hard for a model to use well. Expose a few sharply scoped tools instead.
Skipping authentication on remote servers. A reachable, unauthenticated MCP server is a security incident waiting to happen. Authenticate every remote server.
Granting write access by default. Start every tool read-only and widen only when a workflow genuinely needs it.
No observability. If you cannot see tool calls, you cannot debug or audit them. Log every invocation from day one.

Key Takeaways

MCP (Model Context Protocol) is an open standard from Anthropic, introduced in November 2024, for connecting AI applications to external tools and data.
It solves the M×N integration problem by turning per-model connectors into one reusable client-server protocol, collapsing M×N work into M+N.
MCP is not RAG and not just function calling. RAG grounds knowledge, function calling is a model feature, and MCP is the standard connection layer that makes tool use reusable across clients.
The architecture is small: hosts, clients, and servers, JSON-RPC messages, stdio or Streamable HTTP transports, and three primitives (tools, resources, prompts).
Security lives in deployment, not the protocol. Authenticate remote servers, scope permissions tightly, and log every call.
Heym supports MCP both ways: workflows consume external MCP tools through the MCP Call and Agent nodes, and any workflow can be exposed as an authenticated MCP server.

Build It in Heym

Stop reading about the protocol and run it. Open Heym, connect one MCP server, and call a real tool from a workflow in about ten minutes. Then toggle MCP on that workflow and watch a desktop AI client invoke it as a tool. That round trip is the moment MCP clicks.

Start building with MCP in Heym →

FAQ

What is MCP in simple terms?

MCP (Model Context Protocol) is an open standard introduced by Anthropic in November 2024 that defines one consistent way for AI applications to connect to external tools, data sources, and systems. Instead of writing a custom integration for every model and every tool, you expose a tool once as an MCP server and any MCP-compatible AI client can use it. It is often described as a USB-C port for AI applications.

Is MCP the same as RAG?

No. RAG (Retrieval-Augmented Generation) fetches relevant text from a vector database and injects it into the prompt so the model has more knowledge. MCP is a connection protocol that lets a model discover and call live tools and data sources, including actions that change state. RAG answers what the model knows. MCP governs what the model can do and reach. Many production systems use both together.

Do I need MCP if I already use function calling?

Function calling is how a single model decides to invoke a function you defined for that model. MCP is a transport-agnostic standard so the same tool works across Claude, ChatGPT, Cursor, and any MCP client without rewriting it per model. If you only ever use one model and a handful of private functions, plain function calling is enough. If you want reusable, shareable tools across clients, MCP removes the per-model rewrite.

What is the difference between local and remote MCP servers?

A local MCP server runs on the same machine as the AI client and communicates over stdio (standard input and output). It is simple and private but only available to that machine. A remote MCP server runs as a network service and communicates over Streamable HTTP, so multiple users and clients can reach it with authentication. Heym exposes workflows as a remote MCP server with an API key or OAuth token.

Is MCP secure?

MCP itself is a protocol, so security depends on how the server is deployed. The known risks are prompt injection through tool descriptions, over-broad tool permissions, and unauthenticated remote servers. Mitigations are authenticating every remote server, scoping each tool to the minimum permission, validating tool inputs, and logging every tool call. Heym applies API key or OAuth authentication and records every MCP tool invocation in the trace log.

Can I build my own MCP server?

Yes. You can write an MCP server in Python or TypeScript using the official SDKs, or you can expose an existing workflow as an MCP server without writing protocol code. In Heym, toggling MCP on a workflow publishes it as an MCP tool on a default or named server endpoint that Claude, Cursor, or any MCP client can call.

References

Anthropic, 2026. Model Context Protocol: introduction and specification
Wikipedia, 2026. Model Context Protocol: history, adoption, and architecture
IBM, 2026. What is Model Context Protocol (MCP)?
Microsoft Learn, 2026. Extend an agent with Model Context Protocol
Google Cloud, 2026. What is Model Context Protocol (MCP)? A guide
Red Hat, 2025. Model Context Protocol (MCP): understanding security risks and controls