Use an API or SDK when application code already knows which operation to call. Use MCP when a model needs to discover and choose capabilities at runtime. Most production MCP tools call an existing API underneath, so the two interfaces usually complement each other.
MCP adds discovery and model-facing contracts. It does not replace your backend API, authorization, data model, or the authentication boundary around the MCP server.
The difference is who chooses the operation
Fixed code can call POST /refunds because a developer already selected the endpoint and mapped the fields. An agent investigating a support case may need to decide among get_invoice, explain_charge, request_refund, and escalate_case after reading the evidence. MCP gives the model a current list of those tasks and their schemas.
The MCP tools specification makes tool discovery and invocation part of the protocol. OpenAPI can describe an HTTP API, but it does not by itself decide which endpoints should become agent tasks.
API, SDK, and MCP side by side
| Question | API or SDK | MCP server |
|---|---|---|
| Primary caller | Application code with a known path | Model selecting a capability during a run |
| Discovery | Documentation, types, or OpenAPI used during development | tools/list, resources, and negotiated capabilities at runtime |
| Contract shape | Endpoint or method inputs and outputs | Tool intent plus input and optional output schema |
| Authentication | API-specific | MCP transport authorization plus any separate upstream auth |
| Authorization | Enforced by the backend | Still enforced by the backend |
| Best use | Deterministic workflows and internal service calls | Dynamic tool choice and portable agent clients |
| Main failure | Integration code calls the API incorrectly | Model selects an ambiguous or overly broad tool |
GraphQL belongs with APIs for this decision. Schema introspection helps a developer or client construct queries, but an unrestricted graph is rarely a good agent toolset.
When direct API calls are clearer
Use the API directly when:
- the call always happens at the same point in the workflow;
- code already has the required values;
- the operation is latency-sensitive and another protocol hop adds no decision value;
- the integration needs a provider-specific feature MCP does not expose;
- a small typed SDK already gives the application the required contract.
For example, a checkout handler should call the payment API through reviewed application code. A model should not choose whether to create a charge after the user submits a deterministic checkout form.
When MCP earns its place
Use MCP when:
- the model must choose among several capabilities;
- tools need to work across several compatible agent clients;
- the tool list or available resources can change during a session;
- a user needs to connect their own account through a standard agent flow;
- the client benefits from structured content, resource links, or server-provided prompts.
The REST-to-MCP tutorial starts with one task and wraps the API behind it. It avoids the common one-tool-per-endpoint conversion.
MCP is not a security boundary
Hiding an API endpoint from tools/list does not revoke the credential behind it. The MCP server must authenticate the client, authorize the represented user, and use an upstream credential intended for the target API. The backend then authorizes the resource again.
The MCP authorization specification also forbids token passthrough. A token issued for the MCP server should not be forwarded to a downstream service.
Avoid a mechanical wrapper
Generating one MCP tool for every REST endpoint often creates overlapping choices and exposes internal implementation details. Start from user tasks:
User task: "Where is order 1842?"
Weak toolset:
get_order_row
get_shipment_row
translate_status_code
Better tool:
get_order_status
The server can call several APIs internally and return the smallest useful result. The model should not coordinate internal joins unless that judgment belongs in the agent.
Audit the steps that never vary
List every MCP call in one workflow. If application code always chooses the same tool with the same argument mapping, replace that layer with a typed API or SDK call unless MCP provides another concrete benefit.
The prompt below finds those unnecessary wrappers and preserves MCP where the model is making a real choice.