MCP Server vs REST API: What's the Difference?

A REST API is an interface for programs: your code knows the endpoints in advance and calls them. An MCP server is an interface for AI applications: the client asks the server which tools exist, shows their descriptions to a model, and calls them when the model decides to. MCP does not replace your API. In most products the MCP server is a thin layer that calls the same API underneath, adding discovery, descriptions written for models, a standard auth flow and safety hints such as which tools are read-only.

This article shows the difference with real requests against a database backend, explains how MCP relates to the "tool calling" built into model APIs, and gives a rule of thumb for what to build.

#The short version

#What MCP is, precisely

The Model Context Protocol is an open protocol published at modelcontextprotocol.io. The current specification (revision 2026-07-28) defines:

• Hosts, clients and servers. The host is the AI application, the client is its connector, and the server provides the capabilities.
• JSON-RPC 2.0 as the message format.
• Server features: tools (functions the model can run), resources (data for the user or model) and prompts (templated messages and workflows).
• Two standard transports: stdio, where the client launches the server as a subprocess, and Streamable HTTP, where each message is an HTTP POST to one endpoint and replies come back as JSON or a stream.

The spec is also explicit about consent: hosts must get the user's consent before invoking a tool, and tool descriptions from an untrusted server should be treated as untrusted.

#The same task, two ways

Say you want "the five most recent open orders" from a Postgres-backed app.

#Through the REST API

Your code knows the endpoint, the filter syntax and the auth header:

curl "https://<project-ref>.p.stitchdb.com/rest/v1/orders?select=id,total,created_at&status=eq.open&order=created_at.desc&limit=5" \
  -H "apikey: <anon key>" \
  -H "Authorization: Bearer <user access token>"

This is a PostgREST-style API generated from your schema (querying). Row Level Security decides which rows this user may see. It is fast, cacheable and predictable. A program can call it a million times a day.

#Through an MCP server

An AI client first discovers what the server offers:

curl https://stitchdb.com/platform/mcp \
  -H "Authorization: Bearer sdb_pat_..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The answer lists tools such as list_tables, describe_table and execute_sql, each with a description and an input schema. The client passes those to the model. When the user asks "which open orders came in last?", the model might first call describe_table on orders, then:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "project_ref": "<project-ref>",
      "query": "select id, total, created_at from orders where status = 'open' order by created_at desc limit 5"
    }
  }
}

Nobody wrote code for this question. The model picked the tools and wrote the SQL. That flexibility is the point of MCP, and also why it needs guardrails a REST API does not.

#What MCP adds that an API does not have

Discovery at run time. A client connects to a server it has never seen and learns its tools. Adding a tool to the server makes it available in every connected client without a release.

Descriptions written for models. API docs explain parameters to a developer. Tool descriptions explain to a model when a tool is the right choice. A good MCP server has fewer, broader tools than its API has endpoints.

One integration for many clients. Claude Code, Cursor, VS Code, ChatGPT and the OpenAI Responses API can all use the same remote server. Without MCP you would write a plugin per client.

Standard auth for remote servers. An unauthenticated request gets a 401 pointing at protected resource metadata; the client discovers the authorization server and runs OAuth with PKCE. That is how "paste the URL, approve on a consent screen" works in claude.ai and ChatGPT (OAuth and URL options).

Safety hints. Tools can carry annotations such as readOnlyHint and destructiveHint, so clients can ask before running anything that changes data. A server can also hide write tools entirely on a read-only connection.

#What an API does better

• Speed and cost. A REST call is one HTTP round trip. An MCP-driven task involves model inference on every step.
• Determinism. The same request always does the same thing. A model may pick a different tool or write different SQL next time.
• Scale. Your app's users should hit the API, not an MCP server. MCP is for the people and agents building and operating the app.
• Caching, rate limits and CDNs. These are mature for HTTP APIs and built into the request model.

#MCP server vs tool calling

"Tool calling" (or function calling) is a feature of model APIs: you send a list of tools with JSON schemas in the request, the model answers with a call, your code runs it and sends back the result. It works, but every application defines its own tools, and every tool lives in that application's code.

MCP standardizes the other side: where tools come from. Instead of hard-coding the tools in each app, the app connects to MCP servers and passes their tools to the model. Some model APIs can do this directly. The OpenAI Responses API, for example, accepts a remote MCP server as a tool and can require approval for each call:

const response = await openai.responses.create({
  model: 'gpt-5',
  tools: [{
    type: 'mcp',
    server_label: 'stitchdb',
    server_url: 'https://stitchdb.com/platform/mcp',
    headers: { Authorization: 'Bearer ' + process.env.STITCHDB_TOKEN },
    require_approval: 'always',
  }],
  input: 'Which tables in my project have Row Level Security disabled?',
})

So the relationship is: tool calling is how a model asks to run a tool; MCP is how tools are published and found. See the OpenAI API setup for the approval flow.

#Security: the part that differs most

A REST API usually runs on behalf of a known user with a known set of operations. An MCP server runs on behalf of a model that reads untrusted text: your users' rows, web pages, issue comments. That text can contain instructions (prompt injection). So a database MCP server should:

1. Offer a read-only mode that removes write tools, not just one that asks politely.
2. Scope connections to one project or resource.
3. Never return secrets such as the service_role key or the database password.
4. Mark results as untrusted data.
5. Run writes as a restricted role, ideally with approvals for destructive statements and a way to undo.

StitchDB's server does the first four for every connection (AI security), and agent keys add the fifth: their own Postgres role, a query firewall, approvals and per-session undo.

#Which should you build?

• You have a product with an API and want AI tools to use it: build an MCP server on top of the API. Start with a handful of task-level tools and a read-only mode.
• Your users' apps need data: build or keep the API. Do not route production traffic through MCP.
• You are building an agent for one workflow inside your own app: plain tool calling may be enough. Move to MCP when you want the same tools in Claude, Cursor or ChatGPT.
• You need both: most teams do. The API serves the app; the MCP server serves the humans and agents who build and run it.

For a database, you rarely need to build either yourself: a hosted backend gives you the REST API from your schema and a hosted MCP server. A list of servers worth adding is in the best MCP servers for developers.

#FAQ

#Is an MCP server just an API?

It is an API with a specific protocol: JSON-RPC messages, run-time discovery of tools, resources and prompts, and standard transports and auth. Most MCP servers call a regular API underneath.

#Does MCP replace REST?

No. REST serves applications. MCP serves AI clients. They usually sit side by side, with the MCP server built on the REST API.

#What is the difference between MCP and function calling?

Function calling is a model API feature for requesting a tool call. MCP defines how tools are offered by servers and discovered by clients, so the same tools work across many AI applications.

#Do I need to run an MCP server locally?

Only for stdio servers. Remote servers over Streamable HTTP, such as https://stitchdb.com/platform/mcp, need only the URL and a token or OAuth sign-in.

Try both side by side: create a free project, call its REST API, then connect your AI tool with the MCP guide.