What Is an MCP Server? Meaning, MCP vs API, and When You Need One
What an MCP server is in plain terms, how it differs from an API and from RAG, when your product needs one, what it takes to build, and the security work behind every tool.
If someone has asked whether your product should have an MCP server, the short answer is: only if people already use AI assistants to do work your product is part of, and you already have an API. An MCP server does not replace your API. It describes your API's functions so that any AI app speaking the protocol can discover and call them, with the user's permission.
This guide explains what MCP is in plain terms, how it differs from an API and from RAG, when a product needs a server, what one costs to build and run, and the security work most teams underestimate. Facts are from the protocol's own site and each AI platform's documentation, read in November 2026. We build MCP servers as part of our AI integration work, so weigh our view with that in mind.
What Is an MCP Server? The Meaning in Plain Terms
MCP stands for Model Context Protocol. Its documentation describes it as an open-source standard that connects AI apps to outside systems, and compares it to a USB-C port for AI apps. Anthropic introduced it on November 25, 2024, describing the problem as every new data source needing its own custom integration.
There are three roles. The host is the AI app a person uses, such as Claude, ChatGPT or an editor like VS Code. Inside it, a client holds the connection. The server is the piece you would build: it tells the client what your product offers and runs the calls. Messages use JSON-RPC 2.0.
A server can offer three things. Tools are functions the model can run, such as "look up an order". Resources are data for the user or model to read. Prompts are templated messages a user can pick. Most business servers are mostly tools. Here is what one tool looks like to an AI app, in the format the spec defines:
{
"name": "get_order",
"title": "Order lookup",
"description": "Get the status of one order the signed-in customer owns",
"inputSchema": {
"type": "object",
"properties": {
"order_id": { "type": "string", "description": "Order number, e.g. A-1042" }
},
"required": ["order_id"]
}
}The model reads the name and description, decides the tool fits the user's request, and fills in the arguments. Your server then does what your API already does, under the user's identity.
See One Tool Call, Step by Step
The trace below follows a customer asking an AI assistant about an order, then asking for a refund. Watch where the checks happen. The model only chooses. The server and your API decide what is allowed.
MCP Server vs API: What Is Different
An API is a contract for programs written by developers who read your docs. An MCP server is a contract for AI apps that read your tool descriptions at run time and decide what to call. Under the hood, the server usually calls the API you already have.
Three things change. Discovery is built in, since a client asks tools/list and gets every tool with its input schema. Authorization is standardized: for servers over HTTP, the spec builds on OAuth 2.1, and requires servers to publish metadata that tells clients where to sign the user in. And one server works across many hosts, so you do not write a separate plugin for each AI app.
What does not change is the hard part. Your API still enforces who can see what, your data still needs to be correct, and your rate limits still apply. A weak API becomes a weak MCP server, now reachable by a model.
RAG vs MCP: Not the Same Job
RAG, or retrieval-augmented generation, is a technique inside your own AI feature: search your content, put the best passages into the prompt, and have the model answer from them. MCP is a way for someone else's AI app to reach your product. They solve different problems and often work together.
| API | RAG | MCP server | |
|---|---|---|---|
| What it is | A contract for programs | A technique for grounding answers | A protocol for AI apps to use tools and data |
| Who calls it | Code a developer wrote | Your own AI feature | A model inside an AI app, with user consent |
| Who controls the model | No model involved | You | Usually the host, not you |
| Typical use | Integrations, mobile apps | Support bots, search over docs | Your product inside Claude, ChatGPT or an editor |
| Works with the others | Sits under both | Can be exposed as an MCP search tool | Usually wraps your API |
A concrete overlap: for ChatGPT's deep research and company knowledge features, OpenAI asks for a server with two read-only tools, search and fetch. Behind that search tool there can be a RAG pipeline you already run. If you are deciding whether you need retrieval at all, our guide to chatbots and AI agents covers that choice.
Which AI Platforms Support MCP
Support is broad, and we checked each platform's own docs rather than lists. As of November 2026:
- Anthropic. Claude's MCP connector lets the Messages API call remote MCP servers directly. It is marked beta.
- OpenAI. The Responses API has an
mcptool for remote servers, and ChatGPT can add a custom MCP server from its Plugins page. OpenAI says connector IDs are deprecated for models released after September 1, 2026, in favor of server URLs. - Google. Gemini's Interactions API can connect to remote MCP servers, Streamable HTTP only.
- Microsoft. VS Code lets Copilot agents use MCP servers, with prompts to review a server before trusting it.
The widely quoted adoption figure has a primary source. Anthropic's December 9, 2025 post gave 97 million monthly SDK downloads across Python and TypeScript, and more than 10,000 active public servers. The protocol's own blog put Tier 1 SDK downloads at close to half a billion a month on July 28, 2026.
Should Your Product Have an MCP Server?
Answer six questions about your product. The result shows each rule we applied, so you can disagree with a specific step.
When it is worth it. Your customers already work in an AI assistant all day, and your product holds something they want there: their orders, tickets, documents, analytics or code. A server lets them ask for it in the tool they already use, and makes your product one connector away instead of a copy-and-paste away.
When an API is enough. You are adding an assistant to your own app and it only calls your own backend. You control the model, the prompts and the code, so function calling through your model provider is simpler and has one less layer to secure. One partner who wants an integration is also an API job.
When it is too early. You have no API, or you cannot yet name the first task an assistant would do. Both are cheaper to fix first.
What an MCP Server Costs to Build and Run
The spec and SDKs are free. The cost is engineering time, and most of it goes on authorization and tool design, not the protocol itself.
| Scope | What it includes | Engineer-weeks |
|---|---|---|
| Internal, read-only | Your team's assistants, credentials from the environment, a few lookup tools | 1โ2 |
| Customer-facing, read-only | Remote HTTP server, OAuth 2.1 per user, protected resource metadata, rate limits, logs | 3โ6 |
| Add write actions | Narrow scopes per action, confirmation flow, audit trail, limits on amounts | +2โ4 |
| Internal-only API first | Versioning and documenting an API that outside clients will now depend on | +1โ3 |
Running it is usually small next to your API's own bill, because the server does little work itself. The July 28, 2026 revision helps here: it removed protocol-level sessions, so the protocol's blog says any instance can answer any request and servers fit serverless and edge platforms without sticky routing.
The ongoing cost is keeping up. The spec has had two revisions in eight months, 2025-11-25 and 2026-07-28, and the latest deprecated Roots, Sampling and Logging. Its policy now keeps a deprecated feature for at least twelve months, or ninety days under an expedited-removal exception, which makes planning easier, but someone has to own the upgrades. Tool descriptions also need care, because they are what the model reads to decide. A vague description gets a tool called at the wrong time.
MCP Security: Permissions, Auth and Injection
The spec is blunt: tools "represent arbitrary code execution and must be treated with appropriate caution", and hosts must get explicit user consent before invoking any tool. Your server cannot control what a host shows its users, so it has to be safe even when the host is careless.
- Check the token every time. The authorization spec says servers must validate that access tokens were issued specifically for them, and must not accept or pass through any other token. Passing a user's token straight to a downstream API is named as an anti-pattern.
- Ask for the smallest scopes. The security guide warns against wildcard scopes such as
files:*and recommends starting with low-risk read scopes, then asking for more when a privileged tool is first used. - Check ownership inside each tool. A token proves who the caller is, not that the record belongs to them. The spec's guidance on state handles says the same: possession of a handle is not authentication.
- Treat results as untrusted. Whatever a tool returns goes into the model's context. OpenAI warns that a malicious server can steal sensitive data from anything that enters the model's context. The reverse holds too: a poisoned record in your data can steer the model that reads it.
- Do not trust annotations from strangers. The spec says clients must treat tool annotations, such as a read-only hint, as untrusted unless they come from a trusted server.
Prompt injection is the risk no filter fully removes. Our guide to preventing prompt injection explains why the answer is to limit what the model can reach, and it applies directly to choosing which tools to expose.
How We Would Build One
We would treat the MCP server as one more adapter over the core of the product, not a new product. On AskOrac, we pulled limits, lifecycle and escalation out of the chat route into a channel-agnostic engine that returns a typed outcome, so new channels become adapters instead of rebuilds. An MCP server fits the same shape: the rules stay in one place, and the server only translates.
Ownership checks belong in every tool. In BlurbBio, the API routes run ownership checks on every project route, and a tool that reaches the same data needs exactly that. For anything that changes data, we would copy another BlurbBio rule: authors approve what enters their Story Bible, so the AI cannot quietly rewrite a book's facts. Write tools should work the same way, with a person confirming the change.
In practice, the first version we would ship has three to five read-only tools, OAuth per user, logs of every call with its arguments, and a switch to turn the server off without a release. Write tools come later, one at a time.
Where This Is Heading
- Simpler hosting. The July 28, 2026 spec made MCP stateless, removing the initialize handshake and session IDs. Expect servers to run on the same serverless platforms as the APIs they wrap.
- Neutral stewardship. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded with Block and OpenAI. That lowers the risk of building on one vendor's protocol.
- Platforms converging on server URLs. OpenAI is moving from its own connector IDs to MCP server URLs for models released after September 1, 2026, and Gemini's Interactions API accepts remote MCP servers. One server reaching several assistants is becoming the normal case.
- A smaller core. Roots, Sampling and Logging were deprecated in the 2026-07-28 revision, with suggested replacements. Build on tools and resources, which are the stable center of the protocol.
Start With One Read-Only Tool
If the fit check says yes, pick the single question your customers most often leave your product to answer, expose it as one read-only tool, and connect it to the assistant they use most. Measure whether they use it before you add a second. If it says no, the better investment is probably your API, or the AI feature inside your own product.
Our AI integration team builds MCP servers and the AI features around them, and our backend and API team can get the API underneath ready first. Send us your API docs and the first task, and we will tell you whether a server is worth building yet.
Sources (17)
Common questions
What is an MCP server in simple terms?
It is a small service that describes your product's functions and data in the Model Context Protocol format, so AI apps such as Claude, ChatGPT or VS Code can discover and call them with the user's permission. It usually sits on top of your existing API.
What is the difference between an MCP server and an API?
An API is a contract for code that developers write. An MCP server is a contract for AI apps, which read tool descriptions at run time and decide what to call. The server normally calls your API underneath, so it does not replace it.
Is MCP the same as RAG?
No. RAG is a technique inside your own AI feature that retrieves passages and adds them to a prompt. MCP is a protocol that lets other AI apps reach your product. They can work together, for example an MCP search tool backed by a RAG pipeline.
Which AI platforms support MCP?
As of November 2026, Anthropic's Claude API has an MCP connector in beta, OpenAI's Responses API and ChatGPT support remote MCP servers, Google's Gemini Interactions API supports remote servers over Streamable HTTP, and VS Code supports MCP servers for Copilot agents.
Is MCP secure?
It can be, but the protocol cannot enforce safety on its own. The spec requires servers to validate that tokens were issued for them and asks hosts to get user consent before running tools. Servers still need narrow scopes, ownership checks in every tool, and caution about prompt injection.
Find out if your product needs an MCP server
Send us your API docs and the first task you would want an AI assistant to do. We'll tell you whether an MCP server is worth building now, or whether your API or in-app AI should come first.