---
title: "MCP vs API: The Difference, and What Your MCP Server Leaves Out"
publishedAt: "2026-10-27"
summary: "MCP vs API: an API is a contract for code, MCP lets an AI model find and call tools. Why every MCP server is a subset of the API, and what that leaves out."
author: "Ben Skoog"
authorImage: "/ben_skoog.jpeg"
---

MCP vs API, in one paragraph: an API is a contract that code a developer wrote calls in a fixed way. MCP, the Model Context Protocol, is a standard way for an AI model to discover a product's tools at runtime and decide which to call. An MCP server usually sits on top of the product's API and calls it underneath. So MCP changes who decides what gets called, from the developer to the model. It does not add anything the API cannot already do.

That last sentence is where most explainers stop, and it is the part worth pushing on. In practice an MCP server does not expose the whole API. Every serious vendor exposes a deliberate subset, with guardrails on top, and the published documentation shows it. The subset is not a gap that will close with time. It is a decision the vendor will keep making, because the vendor carries the risk of what an outside agent does in a customer's account.

So if you sell software, shipping an MCP server makes your product callable. It does not make your product's best work available. The work your customers most want done needs more than the tools you are willing to hand to an assistant you did not write.

## The difference between MCP and an API

[Anthropic introduced MCP](https://www.anthropic.com/news/model-context-protocol) on November 25, 2024 as "an open standard that enables developers to build secure, two-way connections" between data sources and AI tools, "replacing fragmented integrations with a single protocol." The [current specification](https://modelcontextprotocol.io/specification/2025-11-25) describes the moving parts: hosts (AI applications), clients (connectors inside them) and servers (services that provide context and capabilities), talking over JSON-RPC 2.0 with "stateful connections" and "server and client capability negotiation."

A server can offer three kinds of things:

- **Tools:** "Functions for the AI model to execute."
- **Resources:** "Context and data, for the user or the AI model to use."
- **Prompts:** "Templated messages and workflows for users."

Here is the comparison most people are looking for.

| | API | MCP |
|---|---|---|
| Who it is built for | Code a developer writes | An AI model choosing at runtime |
| Who decides what to call | The developer, at build time | The model, during the conversation |
| How capabilities are found | Documentation, read by a person | The server lists its tools to the client |
| State | Usually stateless requests | A stateful session between client and server |
| What it can do | Everything the vendor built into it | What the vendor chose to expose, through the API underneath |

[Olostep's rule of thumb](https://www.olostep.com/blog/mcp-vs-api) is a good one: if your code decides what to call, use the API. If the model decides, use MCP. [Wix's explainer](https://www.wix.com/blog/mcp-vs-api) puts the layering plainly: "MCP sits on top of your existing APIs so AI models can reach them without custom code for each one."

Both are right. Neither is the whole picture, because "sits on top of" suggests MCP covers what is underneath. It rarely does.

## In practice, every MCP server is a subset

Read the documentation for the MCP servers that matter and the pattern is the same. Vendors choose what to expose, restrict it further by default, and add confirmation steps that their API does not need.

**Stripe.** The [Stripe MCP server](https://docs.stripe.com/mcp) is one of the most generous. Its `stripe_api_read` and `stripe_api_write` tools reach "much of the API" without loading every endpoint into the model's context. But it publishes an explicit list of supported API methods, and it adds a step the API does not have: "Stripe requires human confirmation before it takes certain `stripe_api_write` actions, such as refunds and outbound payments." Stripe is also tightening keys. Starting in December 2026, Stripe MCP "will stop accepting full-access secret keys and restricted API keys without the Agent tag." The page even invites requests: "If you have feedback or want to see more tools, email us."

**GitHub.** The [GitHub MCP server](https://github.com/github/github-mcp-server) groups tools into toolsets. When none are specified, it enables a default set: `context`, `repos`, `issues`, `pull_requests` and `users`. And "Read-only mode takes priority: write tools are skipped if `--read-only` is set, even if explicitly requested."

**HubSpot.** The [HubSpot MCP server](https://developers.hubspot.com/mcp) gives read and write access to a defined list of CRM objects and engagements, keeps organizational context and marketing content read-only, and "doesn't allow access to custom Sensitive Data Properties, including Personal Health Information."

**Supabase.** The [Supabase MCP server](https://supabase.com/docs/guides/getting-started/mcp) offers a read-only mode, scoping to a single project, and feature groups that "reduce the attack surface and limits the actions that LLMs can perform to only those that you need." It also says something unusually direct about who the server is for: "you should not give it to your customers or end users."

None of this is a criticism. Each of these is a sensible vendor drawing a careful line. That is the point: the line exists everywhere, and the vendor draws it.

## Why the subset will not close

It is tempting to read the list above as a moment in time: early servers, cautious defaults, more tools to come. Some tools will come. But the reason for the line is structural, and it does not go away.

The MCP specification is clear about where responsibility sits. It says "Tools represent arbitrary code execution and must be treated with appropriate caution," and that "Hosts must obtain explicit user consent before invoking any tool." It also says MCP "cannot enforce these security principles at the protocol level." The protocol hands the vendor's capabilities to whatever host the customer connected, and the vendor cannot see or control that host.

So the vendor faces a simple question for every capability: would we be comfortable if an agent we did not write, reading content we cannot see, ran this in a customer's account without anyone watching? For reads, often yes. For a refund, a bulk update, a change to billing, or anything that touches a customer's own customers, the answer is usually no, or yes with a confirmation link. We went through how to draw that line in [what to expose in an MCP server](/blog/what-to-expose-to-your-customers-ai-agents).

That answer does not get easier as models improve. A better model reduces mistakes. It does not move the liability.

## What the vendor's own AI can do that an outside assistant cannot

If MCP is the subset a vendor is willing to hand to anyone's agent, then the vendor's own AI is the one place the vendor can use everything else. Not because it uses a different protocol, but because the vendor controls it end to end.

- **The full product, not the published subset.** The vendor's own AI can use the whole API, internal operations that were never made public, and the product's own rules about what each customer is allowed to do.
- **The vendor's systems, not only the product.** The work customers care about often needs the CRM record, the account owner, a Slack message to the right person, or an email that lands in the right thread. An outside assistant connected to one product's MCP server sees none of that.
- **Responsibility for the result.** A general assistant calls a tool and moves on. Nobody on the vendor's side is watching whether the job got done. The vendor's own AI can be designed, limited, logged and corrected by the people who carry the risk.
- **Work that continues after the conversation.** An MCP session lasts as long as the host keeps it open. The jobs customers pay for, like getting every new hire through onboarding or keeping every location compliant, run for weeks and need someone to notice when they slip.

That last point is the real difference. MCP is very good at letting an assistant do one thing in a product, right now, when a person asks. The work customers most want is a job that someone owns over time. That is what a [service](/services) is: a job the AI owns for each customer and keeps working with the vendor's tools.

## So what should you build?

Both. They do different jobs.

1. **Keep the API as the foundation.** Your own integrations, your partners, and your MCP server all run on it. Nothing about MCP replaces it.
2. **Ship an MCP server for reach.** Customers increasingly work inside AI assistants, and a product those assistants cannot call is a product that gets left out. Expose reads broadly and writes narrowly, as the signed-in customer, with confirmation where a mistake is expensive. If you are weighing MCP against a CLI or code mode, we compared them in [MCP vs CLI vs code mode](/blog/mcp-vs-cli-vs-code-mode-what-to-build-for-ai-agents).
3. **Deliver the valuable work yourself.** The jobs that need your full product, your systems and your accountability are the ones you should not leave to an outside assistant. They are also the ones you can charge for, at your own price, through your own Stripe account, as described on [selling services](/services/sell).

The mistake to avoid is treating step two as the finish line. An MCP server answers "can an AI use our product?" It does not answer "who makes sure the customer's work actually gets done?"

## Where Aimdoc fits

Aimdoc connects to a software company's product through its MCP or API, and to its systems (CRM, Slack, email), then delivers the work its customers need. Every call runs as that customer, with their permissions, in their account. Each job works within a credit budget, a tool allowlist and a kill switch, and the vendor pays Aimdoc in prepaid, capped credits for the AI's work, never per outcome. What the vendor charges its own customers for a service is the vendor's price.

## FAQ

### Is MCP replacing APIs?

No. An MCP server usually calls the product's API underneath. MCP standardizes how an AI model discovers and calls those capabilities, so the API remains the foundation.

### Is MCP just an API for AI?

Close, with two differences. The model, not a developer, decides which tools to call, and the server describes its own tools at runtime. In practice it also exposes less than the full API, by the vendor's choice.

### Should a SaaS company build an MCP server or improve its API?

Start with the API, since the MCP server depends on it. Then add an MCP server for the subset you are comfortable letting outside assistants use, and deliver the higher-stakes work through your own product.

---

An MCP server makes your product callable. Aimdoc makes sure the work gets done, for every customer, through your product and your systems. See how [services](/services) work, or [start free](https://app.aimdoc.ai/signup).