MCP vs API: What MCP Adds to REST, How It Differs from Function Calling and API Gateways, and How to Govern It

MCP vs API in one table

The comparison below uses the current Model Context Protocol specification, version 2026-07-28 (verified October 2026). That release made MCP stateless: the initialization handshake and protocol-level sessions are gone, every request carries its protocol version and client capabilities, and servers must answer a new server/discover request.

The table shows why the question “MCP vs REST API” is a little misleading. The two sit at different layers. A REST API is a contract between programs. MCP is a contract between an AI application and the capabilities it may use, and those capabilities usually call a REST API to do the actual work.

What MCP adds on top of REST and GraphQL

If an agent can already call a REST endpoint, why add a protocol? Four reasons come up in practice.

Run-time discovery. An MCP client asks a server which tools exist and gets back each tool’s name, description and JSON Schema for its inputs. The 2026-07-28 tools specification allows the list to vary with the authorization on the request, so a caller sees only the tools its granted scopes permit. A REST client, by contrast, is written against endpoints someone chose in advance.

Descriptions written for a model. In MCP the tool description is the interface the model reasons about. A good description says what the tool does, when to use it and what it must not be used for. Anthropic’s guidance on building agents recommends treating these descriptions with the same care as documentation for a new developer, because ambiguous descriptions lead to wrong calls.

One calling convention across many systems. Without MCP, each agent framework needs its own adapter for each system. With MCP, a server written once can serve any compatible host, whether that is an IDE assistant, a chat application or an agent platform. That is the main reason the protocol spread so quickly.

More than actions. Besides tools, servers can offer resources (read-only context such as a file or a schema) and prompts (reusable templates). The protocol can also ask the user for missing input through elicitation, delivered in the 2026-07-28 release through a multi round-trip request pattern. The specification deprecated sampling, logging and roots in the same release, so new servers should not build on those features.

What MCP does not add is just as important. It does not decide who may call which tool in your organisation, it does not make an unsafe API safe, and it does not replace the API’s own access control. For a plain-language primer on the protocol itself, see our guide to the Model Context Protocol.

MCP vs REST API: when each fits

A useful rule: if a human developer can decide in advance which call to make, use the API directly. If the decision depends on reading a request or a document, and a model will make it, expose the operation as an MCP tool.

MCP vs function calling

Function calling, also called tool use, is a capability of the model provider’s API. In Anthropic’s Messages API, for example, you pass tool definitions with a name, description and input schema; the model replies with a tool_use block; your code runs the operation and returns a tool_result so the model can continue (verified October 2026). Other providers work the same way with different field names.

MCP sits one layer out. It standardises where those tool definitions come from and who executes them. An MCP host connects to one or more servers, collects their tool lists and hands them to the model as function definitions. When the model asks for a call, the host routes it to the right server with tools/call. Some providers also offer a hosted connector that lets their API reach remote MCP servers directly, which Anthropic documents as its MCP connector.

So the honest answer to “MCP or function calling?” is both. Function calling is how the model expresses the intent to use a tool. MCP is how a business publishes the tools and controls their execution. Our explainer on tool use and function calling goes deeper on the model side.

MCP vs API gateway

An API gateway sits in front of services and enforces traffic rules: authentication, quotas, IP restrictions, caching, routing and logging. Those controls still matter when the caller is an agent.

The line between the two is moving. Azure API Management, for instance, can publish any REST API it manages as an MCP server, turning API operations into MCP tools, and can also front existing MCP servers. Its documentation says policies such as rate limits, JWT validation, IP filtering and caching then apply to the tools, that MCP resources and prompts are not supported, and that the feature is offered on the Developer, Basic, Standard and Premium tiers and on Basic v2, Standard v2 and Premium v2 (verified October 2026). AWS describes its AgentCore Gateway as converting APIs and Lambda functions into MCP-compatible tools.

What an API gateway does not usually know is which agent, acting for which user, in which role, is allowed to use a given tool, and whether the action needs a human approval first. That is the job of an MCP gateway: a registry of approved tools, grants per agent or role, and an audit record of each tool call. Our MCP gateway page explains that layer, and the MCP gateway comparison reviews open-source and cloud options. Model traffic itself, meaning prompts and completions, goes through a separate AI gateway.

A common enterprise layout uses both: agents call the MCP gateway, the gateway calls an MCP server, and the server calls the business API through the existing API gateway.

A worked example: the same invoice API, two ways

Take an accounts payable system with a REST API of some forty endpoints: create, read, update and delete for invoices, suppliers, payments and attachments.

Direct API integration. A developer writes a nightly job that reads unpaid invoices and posts them to a reporting database. The job always calls the same two endpoints with a service credential. No model is involved, and MCP would only add a moving part.

MCP server in front of the API. Finance wants an assistant that answers questions such as “why is this supplier’s invoice on hold?” and can, with approval, release a hold. The team publishes three tools rather than forty endpoints: a search tool for invoices by supplier or status, a read tool that returns one invoice with its match results, and a release tool that removes a payment hold. The first two are granted to the finance assistant role. The third is granted only to a supervisor role and runs behind an approval step. The model never sees the endpoints for changing supplier bank details, because no tool exposes them.

The API did not change. What changed is the shape of what an agent is allowed to do with it.

When to wrap an API as an MCP server

Wrap an API when several AI hosts need it, when a model must choose between related operations, or when you want the tool’s permissions and audit to live in one place. Before you start:

1. Pick operations, not endpoints. Expose the handful of tasks agents need (“find open invoices for a supplier”) rather than mirroring every endpoint. Fewer, clearer tools are easier for a model to use correctly.
2. Split read from write. A read tool can be granted widely. A write tool should be separate, narrowly granted and placed behind an approval step.
3. Write descriptions for the model. State purpose, inputs, side effects and what the tool must not be used for. Return errors the model can act on.
4. Validate everything. The specification requires servers to validate tool inputs, enforce access control, rate-limit invocations and sanitise outputs.
5. Prefer an output schema. Structured results that match a declared schema are easier for clients to check before the model sees them.
6. Decide where it runs. A server that reaches internal systems should run inside your network, with egress limited to the APIs it needs.

Do not wrap an API when a direct, governed call from one agent is enough, or when the operation is so sensitive that it should never be available to a model at all.

Security and governance: what the MCP specification requires

The 2026-07-28 authorization specification (verified October 2026) sets out the following for HTTP-based servers that implement authorization:

• Optional but standard. Authorization is optional. HTTP implementations should follow the specification; stdio servers should not, and take credentials from the environment instead.
• OAuth 2.1 roles. A protected MCP server acts as an OAuth 2.1 resource server; the client acts as an OAuth client on behalf of the resource owner.
• Discovery. Servers must publish OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can find the authorization server.
• Client registration. Client ID Metadata Documents are the preferred registration method; dynamic client registration is now deprecated and kept for compatibility.
• Audience binding. Clients must send a resource indicator (RFC 8707) naming the server, and servers must reject tokens that were not issued for them.
• No token passthrough. Servers must not accept or forward tokens meant for other services, and must not pass a client’s token on to a downstream API.
• Least-privilege scopes. Servers should say in their challenge which scopes an operation needs, and clients should request only those, stepping up when a privileged operation first runs.

The tools specification adds that clients should keep a human in the loop who can deny tool invocations, should confirm sensitive operations and should log tool usage for audit. It also says tool annotations, such as hints that a tool is read-only, must be treated as untrusted unless the server is trusted.

Two practical points follow. First, the API’s own authorization still applies; an MCP server that calls an internal API with a powerful service account has quietly widened access. Second, the OWASP Top 10 for LLM applications names “excessive agency” (too much functionality, permission or autonomy) as a core risk, and recommends least privilege, user-scoped credentials, human approval for high-impact actions and authorization checks in the downstream system rather than in the model.

How VDF AI connects agents to APIs

VDF AI runs on your servers, in a private cloud or air-gapped, with VDF AI Cloud as a hosted alternative. In Agent Hub, tools come from an MCP tool registry that administrators control, and each role receives only the tools assigned to it, so a prompt cannot widen an agent’s reach. Internal services can be wrapped as MCP endpoints and registered there, and the platform’s MCP server layer exposes systems such as Jira, GitHub, GitBook and Slack as governed tools.

For APIs that do not need a dedicated server, the API invoke tool calls REST endpoints on allow-listed hosts with credentials from your vault, and the OpenAPI invoke tool validates parameters against the API’s specification before the request leaves your environment. Write actions can sit behind a human approval step, and every tool call is logged with the agent, role and user. The MCP lesson in the academy walks through connecting a tool, and our companion article on running an MCP registry covers how to decide which servers are allowed in.