The difference between MCP and an API is who calls it and when they learn how. An API (here, a REST API) is an interface for software. A developer reads the documentation and writes code that calls fixed endpoints. MCP, the Model Context Protocol, is an open protocol for AI applications, in which a host such as ChatGPT, Claude or an IDE asks an MCP server which tools it offers while it runs, and the model picks a tool from its name and description. An MCP server rarely replaces an API. It usually sits on top of one, turning a broad set of endpoints into a few tasks a model can use safely, with each user signing in through OAuth.

MCP vs API at a glance

What differs REST API MCP server
Who calls it Code a developer wrote An AI application, on behalf of a model, while it runs
How the caller learns it Documentation, an OpenAPI file or an SDK, read before coding A tools/list request for each tool’s name, description and input schema
Who the descriptions are for People The model, which chooses a tool by its description
What it exposes Resources and endpoints (GET /invoices, POST /refunds) Tasks (list_unpaid_invoices, refund_invoice)
Wire format HTTP methods, paths and status codes JSON-RPC 2.0 messages, over standard input and output or Streamable HTTP
How errors reach the caller HTTP status codes JSON-RPC errors, and tool results marked isError that the model reads and can act on
Sign-in API keys, or an OAuth app you register For remote servers, OAuth with protected resource metadata. Revision 2026-07-28 prefers Client ID Metadata Documents over registering each client
Safety hints None standard Tool annotations such as readOnlyHint and destructiveHint, which clients must treat as untrusted unless the server is trusted
Where customers find it Your developer portal ChatGPT’s plugin directory, Claude’s connector directory, IDE settings

The same task, both ways

Say a support agent needs a customer’s unpaid invoices. Through a REST API, a developer writes the call once:

GET /v1/invoices?customer=C-4410&status=unpaid
Authorization: Bearer <api key>

Through MCP, the server describes the task, and the model decides when to use it. This is the tool definition the server returns from tools/list:

{
  "name": "list_unpaid_invoices",
  "title": "List unpaid invoices",
  "description": "List a customer's unpaid invoices, newest first, at most 20. Use before discussing a balance. It can't take payment.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string", "description": "Customer ID, such as C-4410"}
    },
    "required": ["customer_id"],
    "additionalProperties": false
  },
  "annotations": {"readOnlyHint": true}
}

When the model chooses it, the host sends a tools/call request with {"name": "list_unpaid_invoices", "arguments": {"customer_id": "C-4410"}}, and the server’s code calls the same GET /v1/invoices endpoint with the signed-in user’s token. (Requests on revision 2026-07-28 also carry a _meta block with the protocol version and client details. The specification’s own examples leave it out for brevity, and so do we.)

Three things changed between the two versions:

  • The description is now a prompt. It tells the model when to use the tool and what it can’t do. A vague description gets the wrong tool called, so tool descriptions need testing like any prompt. Our guide on how to test an MCP server covers tool-use evals.
  • The task is narrower than the endpoint. The API can filter invoices any way a developer likes, but the tool does one job. Narrow tools are easier for a model to use correctly and limit what a mistake, or a planted instruction, can do.
  • The user’s identity travels with the call. The server acts for the person signed in to ChatGPT or Claude, not with one shared API key.

MCP vs function calling

Function calling, or tool use, is a feature of model APIs. Your code passes tool schemas with each request, the model replies with the call it wants, and your code runs it. It’s the right choice when you build your own agent and call your own API. MCP standardises the other side with one server that any compatible host can discover and call, so the same tools work in ChatGPT, Claude and IDEs without each team wiring them up. Many agents use both, function calling inside the app and MCP to reach other companies’ products.

When a SaaS company needs an MCP server

  • Customers ask to use your product inside ChatGPT, Claude or their own agents. Without a server, they either can’t, or they wire your API up themselves.
  • You want a listing in ChatGPT’s plugin directory or Claude’s connector directory. Both review OAuth, tool annotations and test access, and our MCP server development page lists what each one checks.
  • Your API is broad and a model needs a few safe tasks. A server is where you decide which writes need a confirmation step and which tools can only read.

When your API is enough

  • Your customers are developers who use your SDKs and write their own integrations.
  • Systems call systems. A nightly sync or a webhook has no model choosing calls.
  • You’re building your own agent. Call your API through function calling, and add an MCP server later if customers want your product in their tools.

What an MCP server adds to your work

  • Tool design and evals. Descriptions decide behaviour, so they need tests, and those tests need re-running when models change.
  • Per-user OAuth. Accept only tokens issued for your server, and never pass a user’s token on to another API. Our MCP security best practices guide maps each rule to the specification, and our MCP OAuth and CIMD guide covers sign-in.
  • Two protocol eras at once. Revision 2026-07-28 dropped sessions, but clients on the earlier revisions still expect them. Our MCP stateless migration checklist covers serving both.
  • Errors a model reads. Tool errors come back as results the model sees, so write them for the model. Our guide to MCP error codes explains each one.
  • A specification that moves. MCP has changed several times since its first revision in November 2024, and the latest, 2026-07-28, removed sessions. Plan for maintenance, not a one-off build.

Our view

Build the MCP server as a thin layer of tasks over the API you already have, not as a second API. Start with a handful of read-only tools that answer the questions customers ask most, add write tools one at a time with a confirmation step, and test every tool description the way you’d test a prompt. The API stays the source of truth, and the server decides what a model is allowed to do with it.

If you’d rather we did this

Our engineers build MCP servers over existing APIs for ChatGPT plugins and Claude connectors, with OAuth to revision 2026-07-28 and tests on both protocol eras. See MCP server development.

Sources

All pages opened on 5 November 2026.

  • MCP specification, revision 2026-07-28: Tools (tool definitions, tools/list and tools/call, error handling, annotations treated as untrusted).
  • MCP specification, revision 2025-11-25: Transports (standard input and output, Streamable HTTP, sessions).
  • JSON-RPC 2.0 specification.
  • MCP TypeScript SDK, @modelcontextprotocol/sdk on npm, version 1.32.2 (the protocol revisions it supports, from 2024-10-07 to 2025-11-25).