Guide

MCP vs traditional API integration: what actually changes

Published 30 September 2026

MCP does not replace API integration. Almost every MCP server you build makes an ordinary API call somewhere inside it, with the same auth and the same upstream rate limit it always had. What changes is who writes the glue, and who decides when the call happens.

The USB-C line, and what it hides

The Model Context Protocol homepage offers the analogy: "Think of MCP like a USB-C port for AI applications." That describes the wiring well and the traffic badly. What crosses the boundary is a description written in prose, read by a language model deciding whether this is the tool for the job. The connector is standardised. The judgement is not.

What stays exactly the same

The MCP docs architecture overview puts it plainly: MCP server refers to the program that serves context data, regardless of where it runs. Serving context usually means calling something: your database, your CRM, someone else's REST endpoint. None of that goes away.

The same page points you at standard HTTP authentication for the Streamable HTTP transport: bearer tokens, API keys and custom headers, with OAuth recommended for obtaining tokens, which is the auth story you already had. Microsoft's MCP for Beginners curriculum lists familiarity with REST and HTTP concepts among its prerequisites. That tells you where MCP sits: on top of what you already know.

What actually changes: who does the integrating

With MCP, you stop writing glue for each app and tool pair. The tool describes itself over the wire, any compliant client can consume that description, and the arithmetic changes from N times M to N plus M.

Write a custom integration and you write glue for one pair: this app, that tool. Add a consumer and you write it again; add a tool and you write it for every consumer. An N by M problem, every cell hand-maintained.

MCP inverts the direction of description: the tool describes itself over the wire, and any compliant client can consume that description without you writing anything for it. The server-concepts page's operation list is the mechanism: among the operations it names are tools/list and tools/call, resources/list and resources/read, prompts/list and prompts/get. A client that speaks those verbs can enumerate your server with no shipped adapter, so the arithmetic changes from N times M to N plus M. The MCP homepage, naming Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam as supporting the protocol, frames the payoff as building once and integrating everywhere.

The second change: the model is the caller

The spec's tools page states: "Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." The server-concepts page draws the same line in a control table:

What Controlled by
Tools the model
Resources the application
Prompts the user

That promotes the tool description from documentation to interface. A vague docstring in a client library costs a developer one detour into the source. A vague MCP tool description produces the wrong tool called, or the right one with the wrong arguments, repeatedly and at runtime.

Errors shift the same way. The spec distinguishes protocol errors, returned as JSON-RPC errors for unknown tools and malformed requests, from tool execution errors reported in the result with isError: true, which it describes as containing "actionable feedback that language models can use to self-correct and retry with adjusted parameters". A bare Request failed is not just unhelpful, it is a broken retry path.

What you still own

The model now decides when a call happens and reads its errors. Auth, quota, upstream failures and cross-call state are still yours: MCP gives you a place to put authentication, not an implementation, and nothing in the protocol budgets your upstream quota.

Question Custom API integration MCP server
Who decides a call happens your code, at a call site you wrote the model, from the tool description
What the caller needs in advance a hand-written client for that pair a compliant client, plus tools/list
Where the interface lives docs a developer reads once the description the model reads every time
Who reads an error your retry logic the model, which may retry with new arguments
Cross-call state whatever your client holds nothing implicit, you pass a handle
Auth, quota, upstream failures yours still yours

Auth. MCP gives you a place to put authentication, not an implementation. The Streamable HTTP page is blunt: servers must validate the Origin header to prevent DNS rebinding attacks, should bind only to localhost rather than all network interfaces, and should implement proper authentication for all connections.

Rate limits. Nothing in the protocol budgets your upstream quota. The transports overview is clear about scope: a transport defines how messages are framed and delivered and how cancellation is signalled. And the caller is now a model that may try several variations where your code tried one.

State. The spec states that MCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next. Servers needing cross-call state are told to return an explicit handle from a creation tool and accept it as an argument on later calls.

Do not compare against a stale MCP

Much of the head-to-head writing contrasts stateless REST with a stateful, session-negotiating MCP. That is out of date. The current revision is 2026-07-28, whose architecture page states: "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities." The versioning page adds: "There is no negotiation handshake." It classes 2025-11-25 and earlier as Legacy. Good material lags too: Microsoft's curriculum README says, "This curriculum is aligned with MCP Specification 2025-11-25 (the latest stable release)." Check which revision your reference targets.

When a plain API call is still the right answer

  • The call site is fixed, or has to be. You know the endpoint, arguments and order at build time, or the sequence must be identical on every run: billing, migrations, anything where a model choosing differently today is an incident.
  • One consumer, one tool. N and M are both one, so there is no multiplication to collapse.
  • Bulk data movement. Reshaping a large body of records is pipeline work, not per-record model work.
  • No model in the picture at all. Obvious, and still a common case of MCP being reached for by reflex.

Build an MCP server when you cannot name the call in advance because a model has to choose, or when the capability must be reachable from clients you do not control. MCP does not remove the human check: the spec's tools page states that "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations". A model-controlled caller is a different threat surface from your own code.

Where this fits if you use Bespoke Prompting

The MCP Tool build type emits eight fixed sections, including the ones this article says you still own: TOOL_DESCRIPTION, FUNCTION_SIGNATURE, OUTPUT_CONTRACT, SECURITY_GUARDRAILS. It derives a tool count of one, on the doctrine that a callable tool does one job, and flags contradictions rather than guessing: multi_user_implied fires when stdio plus a multi-user scenario means you need streamable HTTP instead. Three error codes are floored into every tool spec, because the error text is part of the interface the model reads.

Sources

Suggested internal links