If you run a SaaS product, you have probably heard both sentences this year: "we already have an API" and "we need an MCP server." They sound like the same thing. They are not, and mixing them up leads to either building nothing or building the wrong thing.
This post explains MCP vs API in plain language: what an API is, what the Model Context Protocol is, how they differ, and how to decide whether your product needs an MCP server on top of the API it already has. I build MCP servers for a living, so the examples come from real ones.
What is an API?
An API (application programming interface) is a contract that lets one piece of software talk to another. Your product exposes a set of endpoints. Another program sends a request to one of them and gets structured data back.
Most web APIs today are REST APIs over HTTP. A request to list changelog posts might look like this:
GET /v1/projects/42/posts?status=published
Authorization: Bearer sk_live_...The response is JSON. The developer who wrote the calling code read your API documentation first, learned which endpoints exist, which parameters they take, and what the response looks like. Then they wrote code that calls those endpoints in a fixed order.
That last part matters. An API assumes a human developer reads the docs and writes the integration. The API itself does not explain when to use it or why. It only answers when called correctly.
APIs are excellent at what they do:
- They are stable, versioned, and predictable.
- They work with every programming language.
- They power your own frontend, your mobile app, and your customers' integrations.
- Tooling around them (authentication, rate limiting, monitoring) is mature.
None of that goes away. An MCP server does not replace your API.
What is MCP (Model Context Protocol)?
MCP stands for Model Context Protocol. It is an open protocol, introduced by Anthropic in late 2024, that standardizes how AI assistants connect to external tools and data. It is now supported by Claude, ChatGPT, and a growing list of AI assistants and developer tools.
The short version: an API is built for programs written by developers. An MCP server is built for AI models that decide what to do on their own.
An MCP server exposes three kinds of things:
- Tools: actions the AI can take, like "create a changelog post" or "search bookmarks."
- Resources: data the AI can read, like a document or a record.
- Prompts: reusable instructions the user can trigger.
Tools are the part most products care about. Here is what one tool definition looks like:
{
"name": "create_post",
"description": "Create a changelog post in a project. Use this when the user wants to announce a new feature, improvement or fix. Posts are created as drafts unless status is set to published.",
"inputSchema": {
"type": "object",
"properties": {
"project_id": { "type": "string" },
"title": { "type": "string" },
"body": { "type": "string", "description": "Post content as HTML" },
"status": { "type": "string", "enum": ["draft", "published"] }
},
"required": ["project_id", "title", "body"]
}
}Notice the description. It is not written for a developer. It is written for the model, and it explains when to use the tool, not only how. That is the core idea of MCP: the server describes itself, and the AI assistant reads that description at runtime and decides which tool to call.
Nobody writes integration code. The user types "announce the new export feature in our changelog," and the assistant finds the right tool, fills in the arguments, and calls it.
If you want the full picture of how the protocol works, I wrote a separate guide to MCP servers.
MCP vs API: the key differences
Here is the comparison side by side.
| API | MCP server | |
|---|---|---|
| Built for | Developers writing code | AI assistants acting for a user |
| Who decides what to call | The developer, in advance | The AI model, at runtime |
| Discovery | Human reads documentation | Model reads tool descriptions automatically |
| Interface | Endpoints, methods, status codes | Tools, resources, prompts |
| Protocol | Usually REST or GraphQL over HTTP | JSON-RPC 2.0 over stdio or HTTP |
| Shape | Mirrors your data model | Mirrors what users want to get done |
| Integration effort for the user | Write and maintain code | Connect once, then just ask |
| Typical consumer | Your frontend, partners, scripts | Claude, ChatGPT, AI coding tools, agents |
Three of these rows deserve a closer look.
Discovery: documentation vs self-description
With an API, discovery happens before the code is written. A person reads the docs.
With MCP, discovery happens every time an assistant connects. The client asks the server for its list of tools and gets back names, descriptions, and input schemas. The model uses that list to plan. If you add a tool tomorrow, every connected assistant can use it tomorrow, with no code change on the user's side.
Granularity: endpoints vs tasks
A good REST API is resource-shaped. It has endpoints for projects, posts, tags, and users, each with create, read, update, and delete.
A good MCP server is task-shaped. Asking a model to chain six low-level calls to finish one job is slow and error-prone. It works much better to give it one tool that does the whole job.
This is why a good MCP server is not a 1:1 copy of your API. For Lytmark, my changelog and roadmap product, the MCP server has 7 tools. The underlying API has far more endpoints. The 7 were chosen by asking what a person would actually say to an assistant: write a post, update it, show me the roadmap, show me what users suggested.
Who is in control
An API call is deterministic. The same code runs the same way every time.
An MCP tool call is a decision made by a model. That changes how you design for safety. Destructive actions need clear descriptions, sensible defaults (drafts instead of published posts, for example), and sometimes a confirmation step. Good tool design is as much about preventing the wrong call as enabling the right one.
How MCP and APIs work together
MCP vs API is a slightly misleading framing, because in practice they stack.
A typical setup looks like this:
- The user asks an AI assistant to do something in your product.
- The assistant picks a tool from your MCP server and calls it.
- Your MCP server translates that tool call into one or more calls to your existing API or database.
- The result goes back to the assistant, which explains it to the user.
The MCP server is a thin layer on top of what you already have. Your API stays the source of truth for business logic, permissions, and validation. The MCP server adds the part your API was never designed for: describing your product to a model in a way it can act on.
So the honest answer to "MCP or API?" is usually both, with the API first.
When an API is enough
You do not need an MCP server if:
- Your product is only used through your own interface, and nobody is asking to use it from an AI assistant.
- Your integrations are machine-to-machine and fixed, like a nightly sync or a webhook.
- You need strict, deterministic behavior where a model making choices would be a risk rather than a feature.
In these cases, a clean API with good documentation is the right investment.
When your product needs an MCP server
An MCP server starts to make sense when:
- Your users already work inside AI assistants. If they draft, plan, and code in Claude or ChatGPT all day, the fastest way to use your product is from there.
- Your product holds data people want to ask questions about. Notes, tickets, analytics, feedback, documents. "What did customers ask for most last month?" is a natural question for an assistant.
- Common tasks take many clicks. If publishing an update means opening the app, finding the project, filling a form, and picking tags, one sentence in a chat is a real improvement.
- You want to be usable by AI agents. Agents pick tools from what is available to them. A product without an MCP server is invisible to them.
- Your competitors have one. Being listed as a connector in an assistant is becoming a distribution channel of its own.
Common mistakes when adding MCP to an existing API
I see the same problems again and again.
Wrapping every endpoint as a tool. Auto-generating one tool per endpoint gives the model fifty choices with near-identical names. It picks the wrong one, or chains them badly. Fewer, task-shaped tools perform better.
Writing descriptions for developers. "Creates a post resource" tells a model nothing about when to use the tool. The description is the most important part of the tool and deserves real testing with real prompts.
Returning raw API responses. A 400-line JSON payload wastes the model's context and buries the answer. Return what is needed to complete the task.
Ignoring authentication until the end. A remote MCP server acts on behalf of a specific user. It must respect the same permissions as your API, per user, from day one.
Not testing in a real assistant. A server can pass every unit test and still be confusing to a model. The only real test is running real prompts and watching which tools get called.
How much work is it to build an MCP server?
Less than building the API was, if the API already exists.
The server itself is a small service. I host mine on Cloudflare Workers, which keeps them fast and close to free to run; the reasoning behind that choice is in my post on the Cloudflare, D1 and Paddle stack.
The real work is design: deciding which tools exist, what they are called, how they are described, and what they return. That is where an MCP server succeeds or fails, and it is why two servers for the same product can feel completely different to use.
The specification and official SDKs are documented at modelcontextprotocol.io.
Frequently asked questions
Is MCP a replacement for REST APIs?
No. MCP does not replace REST APIs. An MCP server usually sits on top of an existing API and translates AI tool calls into API requests. Your API remains the source of truth for data and business logic, while the MCP server makes that functionality usable by AI assistants.
What does MCP stand for?
MCP stands for Model Context Protocol. It is an open protocol that standardizes how AI assistants and agents connect to external tools, data sources, and services, so one server can work with many different AI clients.
Can I build an MCP server without an API?
Yes. An MCP server can talk directly to a database or any other backend. Having an existing API makes it faster and safer, because validation and permissions are already in place, but it is not a requirement.
Do I need an MCP server if my product already has an API?
It depends on your users. If they want to use your product from AI assistants like Claude or ChatGPT, or you want AI agents to be able to use it, an API alone is not enough, because models cannot discover and use it on their own. An MCP server closes that gap.
What is the difference between an MCP tool and an API endpoint?
An API endpoint is called by code a developer wrote in advance. An MCP tool is chosen and called by an AI model at runtime, based on a natural-language description of what the tool does and when to use it. Tools are usually shaped around tasks, while endpoints are shaped around data.
Is MCP only for Claude?
No. The Model Context Protocol is an open standard. It was introduced by Anthropic, but it is supported by multiple AI assistants and developer tools, so a single MCP server can serve all of them.
The short version
An API lets developers build on your product. An MCP server lets AI assistants use your product on behalf of your users. You almost always keep the API and add MCP as a thin, carefully designed layer on top.
If your product has an API and you want it usable from AI assistants, that is exactly the work I do. You can see a live example in Lytmark, where the MCP server writes changelog posts straight from a chat.
