MCP vs API for production AI integrations

MCP does not replace a good API. It gives AI clients a standard way to discover and call selected capabilities, usually by sitting in front of APIs, databases, or local tools that still do the real work. Choose MCP when several agent clients need the same usable tool contract. Keep a direct API integration when your application already knows exactly what operation to call and needs tight control over every request.

That distinction prevents an expensive category error. Teams often compare an MCP server with a REST endpoint as if both were competing backend designs. They are usually different layers. REST exposes application operations to software. MCP packages some of those operations, descriptions, schemas, and results for a model driven client. The extra layer earns its place only when reuse, discovery, and agent behavior outweigh its latency, authorization, and operational cost.

MCP is an agent adapter, not a new backend

A Model Context Protocol server is an adapter at the boundary between an AI host and a capability. It speaks a common protocol to the host, advertises tools or resources, validates arguments, invokes downstream systems, and returns model usable results. Your database constraints, business rules, API idempotency, and audit records still belong behind that adapter.

A direct REST integration starts with a developer who knows the endpoint, method, request shape, response shape, and authentication scheme. The application decides when to call it. An MCP integration lets a host discover a catalog and gives a model enough descriptions and schemas to choose a tool and construct arguments. The host still enforces policy, but the model participates in selection. That is a different execution model, not a prettier HTTP client.

The field routinely blurs protocol standardization with semantic standardization. MCP standardizes how a client lists and calls a tool. It does not make create_customer, open_account, and provision_tenant mean the same thing across three servers. Tool names, descriptions, side effects, scopes, errors, and domain rules remain yours. A weak contract stays weak after you wrap it in MCP.

The latest Model Context Protocol specification, revision 2026-07-28, makes this boundary cleaner than earlier versions did. Each request carries its protocol version, client identity, and capabilities. The protocol retired the mandatory initialize exchange and the Mcp-Session-Id transport session. A client can call a tool directly or use server/discover when it wants capabilities first. That removes a chunk of connection ceremony, but it does not remove tool discovery, schema processing, model deliberation, or your downstream call.

Treat the MCP layer as replaceable. It should translate and constrain. If it starts owning pricing rules, permissions that the source system cannot verify, or transaction state that exists nowhere else, you have created a second backend with weaker visibility. I have watched adapter layers become accidental systems of record. The cleanup is never cheap.

Choose MCP when client independence pays for it

MCP earns its cost when a capability must work across multiple compatible AI hosts without building a custom adapter for every host. The useful unit of reuse is not one endpoint. It is a coherent set of model ready operations with descriptions, input schemas, safe results, and consistent authorization behavior.

Four conditions make the case strong:

• Several agent clients need the same capability, now or within a credible planning horizon.
• A model needs to discover which operations exist instead of following a fixed application path.
• The capability benefits from a shared tool contract, including descriptions and JSON Schema arguments.
• One team can own compatibility, authorization, observability, and releases for the server.

Local developer tools are an obvious fit. A host can launch an MCP server over standard input and output, pass credentials through the process environment, and expose a narrow tool set without opening a network port. The official transport specification tells stdio implementations to exchange newline delimited JSON-RPC and reserve standard output for protocol messages. That boring rule matters: one debug print to standard output can corrupt the stream. Send logs to standard error.

Remote capability catalogs can also justify MCP. Imagine an accelerator with several internal agents that need controlled access to portfolio metrics, support history, and infrastructure status. One remote server can present stable tools while the systems behind it change. The gain comes from keeping agent clients independent of those backend changes. If only one internal workflow calls one operation, the same server may be ceremony without reuse.

Count consumers before writing code. We may have agents later is not demand. Name the hosts, the owners, and the operations they need. If you cannot identify a second consumer or a discovery problem, start with the API you already have. You can add the adapter after the contract survives real use.

Keep REST for deterministic product paths

A direct API is usually the better choice when software, rather than a model, controls the workflow. Checkout, password reset, webhook ingestion, ledger posting, and health checks should not ask a model which operation looks appropriate. Their paths need predictable validation, retry, timeout, and error behavior.

REST also wins when external developers need a broad public surface. OpenAPI can describe hundreds of endpoints, generate typed clients, feed gateways, and support conventional versioning. Exposing that whole surface as hundreds of MCP tools makes the model sort through a large catalog and increases the chance of a poor selection. An agent normally needs a small task surface, not a copy of your API reference.

Do not build an MCP server merely to avoid writing one API client. You still have to implement transport handling, schema definitions, tool descriptions, error mapping, authentication, policy, telemetry, compatibility tests, and deployment. A generated REST client may be less glamorous, but it is often the shortest reliable path.

Direct APIs have a security advantage in fixed workflows: you can grant one workload the exact operation it needs and never expose a catalog to model selection. MCP can enforce equally narrow permissions, but only if the server maps identity, scopes, tool calls, and downstream authorization correctly. That mapping is work. Protocol support does not write the policy for you.

There is no shame in using both. Keep the REST API as the source contract. Put MCP in front of the subset that agents can use safely. Mobile apps, web services, batch jobs, and partners keep their deterministic interface. AI hosts get tools shaped around decisions they can reasonably make. This split also gives you a clean rollback path because removing the MCP adapter does not disturb the backend.

Latency belongs to the whole call path

MCP latency is the sum of transport, discovery, model, server, and downstream time. Measuring only the server handler produces a comforting number that users never experience. Measure from the host's decision to call through the final result entering the next model turn.

For a remote tool call, break the path into these spans:

1. Catalog load or cache lookup, including server/discover or tools/list when used.
2. Model selection and argument generation.
3. Network and protocol handling at the MCP endpoint.
4. Tool execution, including downstream API and database work.
5. Result serialization, transfer, and the model's next turn.

The 2026-07-28 specification helps with two parts. List responses can include cache hints, and deterministic ordering keeps catalogs stable for prompt caches. Streamable HTTP mirrors method and tool names into Mcp-Method and Mcp-Name headers, so a gateway can route or meter a request without parsing the JSON body. Those features reduce avoidable work. They cannot rescue a tool that returns 80 kilobytes when the model needs four fields.

Instrument the boundary with a trace identifier and record a compact timing object. This shape is enough to find the owner of a slowdown:

{
  "trace_id": "01J...",
  "tool": "triage_incidents",
  "catalog_ms": 0,
  "model_select_ms": 418,
  "mcp_transport_ms": 27,
  "downstream_ms": 183,
  "result_bytes": 2461,
  "total_ms": 711
}

Do not invent a latency budget by copying someone else's benchmark. Run the same user task through the direct integration and the MCP path, with warm and cold catalog states. Capture p50 and p95 for each span, error rate, retries, result bytes, and model tokens. The comparison must use the same model, region, backend operation, and result content. Otherwise you are benchmarking different systems.

Local stdio avoids network transit, but it still pays process startup if the host does not keep the server available. Remote HTTP avoids local installation but adds network and authorization work. For long operations, use the protocol's Tasks extension or a domain job handle when client support permits it. Do not hold an ordinary request open for several minutes and call that an integration strategy.

Remote authorization is a product surface

Authorization decides whether a remote MCP server is viable, because the user, client, server, authorization server, and downstream API may all carry different identities. A successful token check at the MCP endpoint does not prove the caller may perform the downstream action. The server must preserve that distinction deliberately.

For HTTP transports, the current MCP authorization specification builds on OAuth. The MCP server acts as a protected resource. It publishes protected resource metadata under RFC 9728, points clients to an authorization server, and challenges unauthorized requests with WWW-Authenticate. Clients use authorization server metadata or OpenID Connect discovery, request tokens for the MCP server through the RFC 8707 resource parameter, and use PKCE for authorization code protection. Revision 2026-07-28 also requires issuer validation based on RFC 9207.

That sounds like a familiar browser login because it is one, but interoperability has sharp edges. Desktop clients use loopback redirects. Some enterprise clients arrive with preregistered credentials. Client ID Metadata Documents are now the preferred registration mechanism, while Dynamic Client Registration remains for compatibility and is deprecated. Your identity provider may support only part of that path. Test the actual hosts you intend to support. A standards checklist cannot substitute for a completed sign in, refresh, revocation, and step up flow.

Never pass the client's MCP access token through to a downstream API. The MCP security guidance explicitly forbids token passthrough. Validate that the inbound token targets the MCP server, then obtain or select a separate downstream credential for the upstream resource. Passing one bearer token across both boundaries creates audience confusion and can turn the server into a confused deputy.

Local stdio follows a different model. The specification says stdio implementations should retrieve credentials from the environment rather than use the HTTP authorization flow. That is convenient for a single developer workstation, but environment access is broad and secret rotation is easy to neglect. Give the process a narrow credential, redact environment values from diagnostics, and decide whether the host may launch arbitrary server commands. Local does not mean harmless.

Service automation needs an explicit answer too. An interactive user grant does not fit an unattended nightly job. Use a supported machine identity flow, a dedicated internal transport policy, or keep that workload on the direct API. Do not smuggle a long lived personal refresh token into a container because the demo worked that way.

Tool contracts should express decisions, not endpoints

A useful MCP tool gives the model one bounded decision with enough context to call it correctly. Copying every REST path into a tool with the same parameters exposes implementation detail and makes the model assemble workflows your backend already understands better.

Suppose an incident API offers separate endpoints to search incidents, fetch timelines, list owners, assign an owner, and post a note. A literal wrapper creates five tools and asks the model to coordinate them. A better read tool might be triage_incidents, which accepts service, severity, age, and limit, then returns the facts required for assignment. Keep the write as a separate assign_incident tool so the host can require confirmation and the server can enforce a narrower scope.

Descriptions need operational facts, not marketing prose. State when to use the tool, what it will change, which identifiers it expects, and what important limit applies. Input schemas should reject ambiguous combinations. Outputs should give stable fields first and prose second. The current MCP tools specification supports structured content, which lets a client consume a typed result while the model sees a concise explanation.

Use errors that lead to a safe next action. Invalid request tells neither the host nor the model what to repair. Return a stable error code, a short message, and field details. Distinguish invalid arguments, denied authorization, conflicts, rate limits, downstream unavailability, and unknown outcomes. If a write times out after the downstream system may have accepted it, report an unknown outcome and include an idempotency reference. Do not invite an automatic retry that could duplicate the action.

Tool annotations and names are hints, not access control. A tool described as read only still needs server enforcement. A model can misunderstand text, a client can be buggy, and an attacker can call the endpoint without a model. Put every permission and invariant in executable code behind the protocol boundary.

A migration can preserve the working API

The safest MCP migration wraps one proven workflow and leaves the source API intact. Start with a read path that has real agent demand, then add a write only after identity, approval, idempotency, and audit behavior work end to end.

Assume an existing incident service exposes GET /v1/incidents and already enforces tenant access. The first MCP tool can map a narrow schema to that endpoint:

{
  "name": "triage_incidents",
  "description": "Find open incidents that need an owner. Returns facts for triage and changes nothing.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "service": {"type": "string", "minLength": 1},
      "severity": {"type": "array", "items": {"enum": ["sev1", "sev2", "sev3"]}, "maxItems": 3},
      "older_than_minutes": {"type": "integer", "minimum": 0},
      "limit": {"type": "integer", "minimum": 1, "maximum": 25}
    },
    "required": ["service"],
    "additionalProperties": false
  }
}

The handler should derive the tenant from validated identity, never from a model supplied argument. It maps allowed fields to the API request, applies a server side limit when the client omits one, and reduces the response to fields needed for triage. It also propagates a trace identifier without exposing the downstream credential.

validate MCP token audience and scopes
tenant = identity.tenant_id
query = allowlist(arguments, service, severity, older_than_minutes, limit)
response = incident_api.list(tenant, query, downstream_credential)
return compact(response, id, service, severity, opened_at, owner, summary)

Run the direct path and MCP wrapper in shadow comparison before letting the agent act on the result. Send the same approved query to both, normalize ordering, and compare identifiers and fields. Shadowing should not duplicate writes. For the later assignment tool, use a staging tenant or a dry run facility that the source API genuinely supports. If no safe simulation exists, test with controlled records and explicit approval.

Add the write as a separate contract:

{
  "name": "assign_incident",
  "description": "Assign one open incident to an eligible responder. This changes the incident and requires approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "incident_id": {"type": "string"},
      "responder_id": {"type": "string"},
      "reason": {"type": "string", "minLength": 10, "maxLength": 300},
      "idempotency_key": {"type": "string"}
    },
    "required": ["incident_id", "responder_id", "reason", "idempotency_key"],
    "additionalProperties": false
  }
}

Before launch, verify that a user from tenant A cannot name an incident or responder from tenant B, a repeated idempotency key returns the original result, a revoked grant fails, catalog descriptions match behavior, and every write records actor, client, tool, arguments after redaction, outcome, and downstream request ID. These are release conditions. They are not optional security polish.

One trace must cross both layers

Operations fail when the MCP team sees a successful tool call while the API team sees a failed backend request with no shared identifier. Carry one trace context from the host through the MCP server, gateway, API, and job runner. Record the protocol version, client identity, tool name, server release, downstream operation, outcome class, and timing without logging tokens or sensitive arguments.

Version the semantic contract even if the protocol stays compatible. Changing limit from optional to required, reinterpreting status, or removing a result field can break agent behavior without producing a transport error. Contract tests should list tools, validate schemas, run representative calls, and compare structured results against fixtures. Test every supported host because clients can render approvals, cache catalogs, and surface errors differently.

Own the adapter as production software. Set timeouts at the MCP boundary and shorter timeouts downstream so the server can return a controlled error. Bound concurrency. Apply rate limits by identity and tool, not only by IP. Cap result sizes. Redact secrets before logs leave the process. Publish a compatibility window for protocol revisions and tool changes.

The latest protocol's stateless request model makes ordinary load balancing easier, but application state still needs a home. If a workflow spans calls, return an explicit job or workflow handle that the model can pass back. Store durable state in the backend. Hidden in-memory state will disappear during a restart and behaves badly under horizontal scaling.

A small team can support this if ownership is clear. The trouble starts when one group owns tool descriptions, another owns OAuth, a third owns the API, and nobody owns the complete user action. Assign one service owner for the end to end contract, even when several teams maintain its parts.

Compatibility costs arrive after launch

Protocol support is a matrix, not a checkbox. A server, host, SDK, gateway, and identity provider can each support a different revision or a different subset of optional behavior. The happy path may work while cancellation, cache hints, structured results, or authorization recovery fails. Put the exact combinations you support in a test matrix and rerun it on every release.

The July 2026 revision is especially important because it removed the initialization handshake and protocol session used by prior revisions. Older clients may still expect initialize and Mcp-Session-Id. New clients send self describing requests and can discover capabilities only when needed. If you must support both eras, follow the specification's compatibility rules or use an SDK that does, then test both paths. Do not write a handler that guesses from a missing header and silently mixes semantics.

A common failure begins with an innocent tool rename. The team changes get_open_incidents to triage_incidents, deploys the server, and confirms that the new catalog looks correct. One host has cached the old list. Its model calls the old name, receives a method error, retries after another model turn, and tells the user the incident system is unavailable. The API never failed. The protocol stayed healthy. A semantic change plus stale discovery created the outage.

Prevent that failure with an overlap window. Keep the old tool as a thin alias, mark it deprecated in its description, emit a metric when clients call it, and remove it only after its usage falls to zero across the supported cache lifetime. Preserve argument and result behavior during the overlap. If the new tool changes semantics, give it a new name and do not route old calls into behavior they did not request.

Catalog size deserves the same operational attention. Every description and schema consumes context when a host loads the catalog, and every similar name gives the model another choice to confuse. Split servers by trust boundary or coherent domain when the catalog grows, not by arbitrary organization chart. A billing agent should not inspect deployment tools merely because the same platform team owns both services. Smaller catalogs reduce exposure and make evaluations easier to interpret.

Evaluate behavior with task fixtures, not only protocol conformance. A conformance suite can prove that tools/list returns valid JSON-RPC and that an input matches JSON Schema. It cannot prove the model chooses read_customer rather than search_customers, asks for approval before a write, or explains a partial result correctly. Build a set of representative prompts, expected tool choices, forbidden choices, argument constraints, and acceptable result interpretations. Run it against every model and host you claim to support.

Rollout needs independent controls for discovery and execution. First allow selected clients to list the tools. Then allow read calls for a small identity group. Add writes behind explicit approval and a server side allowlist. Keep a kill switch that disables one tool without taking down the server, and make its error say that an operator disabled the operation. A generic server failure will cause clients to retry or choose an unsafe substitute.

Rollback should be equally plain. You need the previous server release, the previous catalog contract, and a way to reject calls introduced by the newer version without corrupting state. Database migrations behind a tool must remain compatible with both releases during the rollback window. This is ordinary production discipline, but teams skip it when they treat an MCP server as a prompt file with a web endpoint.

Use a decision gate before building

An MCP server should pass a harder test than our agent framework supports it. Score the proposed capability against actual consumers, behavior, and operational constraints. If several answers remain vague, the project is not ready.

• Which named AI hosts need this, and which protocol revision does each support?
• Does a model need discovery, or does application code already know the operation?
• Can you expose a small task contract instead of mirroring the whole API?
• Can identity and least privilege survive both the MCP and downstream boundaries?
• Does the measured latency fit the user action, including model turns and result size?

Then identify the owner and exit path. One team must support authentication failures, schema changes, client differences, and downstream incidents. The backend API must remain callable without the MCP layer unless you have a strong reason to couple them. That keeps migration reversible and prevents a protocol choice from becoming a business rule.

For founders, the economic test is plain: count adapters removed, workflows enabled, and maintenance added. A shared server used by four real agent clients can cut repeated integration work. A server built for one fixed call adds a deployment, an auth boundary, and another pager. Both can be technically correct; only one may be worth owning.

Build the narrow read tool first, measure the complete call, and make the authorization flow work in every named host. If that slice does not produce reuse or a better agent contract, stop and keep the API. If it does, add tools one bounded decision at a time.