MCP vs a Custom HTTP API: When Each One Is the Right Call in 2026

The Model Context Protocol is the right answer for a specific kind of consumer: an AI agent that needs to discover available tools at runtime, call them through a uniform schema, and read resources without per-service glue code. For every other consumer (a browser app, a backend microservice, a mobile client, a CI pipeline, a cron job, a webhook receiver), a plain HTTP API is still the right answer in 2026. The teams that conflate the two end up with a protocol mismatch on one side and a wasted integration budget on the other.

This post is a decision framework. Four signals decide whether a given surface should be MCP, HTTP, or both. The cases where MCP is the wrong answer are not edge cases. They are the majority of integration surfaces inside any production service. The migration path between the two protocols is short enough to ship both without doubling the engineering bill, provided the team builds in the right order.

What MCP is, in one paragraph

MCP, the Model Context Protocol, is an open protocol Anthropic published in late 2024. It defines a stateful session between an AI agent runtime (the client) and a service (the server) that exposes tools (functions the agent can call), resources (data the agent can read), and prompts (parameterized prompt templates the agent can apply). The server advertises its tool and resource catalog at session start. The client uses that catalog to populate the agent's available actions at runtime. When the agent decides to call a tool, the client routes the call through MCP and returns the result to the agent. The protocol runs over stdio or HTTP+SSE. The schema for tools and resources is JSON Schema, the same schema language the underlying models already understand.

That is the whole protocol. Everything else is what the protocol enables: a single agent runtime can talk to dozens of unrelated services through a uniform interface, and a service can be exposed to any MCP-compatible agent runtime without writing per-runtime integration code.

The four signals

For a given service, four signals decide whether the surface should be MCP, HTTP, or both.

1. Who is the consumer. An AI agent runtime that loads tools dynamically (Claude Code, the Anthropic API with tool use, ChatGPT with Custom GPTs, Cursor, Continue, Cline) is an MCP-native consumer. Server-to-server integration code, browser frontends, mobile apps, CLIs, webhook receivers, and cron jobs are HTTP-native consumers. A service that has both kinds of consumers needs both surfaces.

2. Does the consumer need runtime discovery. An AI agent that does not know in advance which tools it will need benefits from MCP's tool-listing primitive. A backend service that calls a known set of three endpoints does not. The discovery benefit shows up only when the call set is large enough or dynamic enough that hard-coding it is impractical.

3. Does the call surface have side effects. MCP servers have a tool primitive (action with side effects) and a resource primitive (read-only). The distinction is enforced at the protocol level and the agent runtime exposes the distinction to the model. An HTTP API has GET, POST, PUT, DELETE, but the model behind a chat-style agent does not see those verbs natively. For an agent-facing surface, MCP's tool-versus-resource split is a genuine usability win because it lets the model reason about safety more naturally.

4. Does the consumer need streaming or long-running operations. MCP supports server-sent events for streaming tool output. An HTTP API supports streaming through SSE, WebSockets, or chunked encoding, depending on the framework. Both protocols handle streaming. Neither one is structurally better at it.

The combined verdict reads as follows.

The pattern that holds up: HTTP is the source of truth, MCP is a proxy onto the agent-relevant subset.

Why building MCP-first usually backfires

A common 2026 pattern looks like: a team has a service, AI agents are hot, the team builds an MCP server as the primary integration surface. Six months later the team realizes they also need browser integration, mobile integration, and webhook delivery, and they rebuild the same logic behind an HTTP API. The protocol cost gets paid twice.

The mistake is putting the protocol layer above the business logic. The correct shape is:

+----------------------+
|   AI agent runtime   |   <- MCP client
+----------------------+
           |
           v
+----------------------+
|    MCP server        |   <- thin proxy, no business logic
+----------------------+
           |
           v
+----------------------+
|   HTTP API           |   <- source of truth, all business logic
+----------------------+
           |
           v
+----------------------+
|   Application core   |
+----------------------+

The HTTP API holds the business logic, the validation, the authorization, the persistence. The MCP server is a wire-format adapter: it accepts MCP tool calls, translates them to HTTP requests against the API it sits in front of, and returns the result wrapped in MCP's response envelope. The MCP server is rarely more than a few hundred lines of code per service. The HTTP API is whatever size it would have been anyway. When a new consumer profile shows up (a browser app, a mobile client, a third-party integrator), the HTTP API already has them covered.

The reverse order does not work as cleanly. An MCP-first server pulls business logic into the MCP layer because the team is moving fast and there is no other layer to put it in. By the time the second consumer arrives, the business logic is married to the MCP transport and extracting it is a refactor, not a wrapper.

Auth and observability are not free in either protocol

A frequent assumption is that MCP servers inherit auth from the agent runtime. They do not. An MCP server that exposes side-effectful tools needs its own auth layer, its own audit logs, and its own rate limits. The agent runtime might pass a user token through, or it might pass nothing through; the server cannot assume.

The same goes for observability. An MCP server is a long-running process. It needs the same telemetry as any other long-running service: structured logs, request and tool-call traces, latency and error-rate metrics, health checks, dependency-health checks against whatever the MCP server proxies. A team that ships an MCP server without those is shipping the same operational gap they would ship if they put up an HTTP API with console.log for telemetry.

The cleanest pattern is for the HTTP API to own the audit log and the rate limit, and for the MCP server to be authenticated against the HTTP API the same way any other client would be. The MCP server adds its own session-level instrumentation (tool-call counts, session durations, error rates), but the canonical authorization decisions and the canonical audit trail live one layer down.

The cases where MCP is genuinely the wrong answer

Three patterns where reaching for MCP is the wrong call:

• A backend microservice talking to another backend microservice. The internal call is server-to-server. No agent in the loop. MCP's discovery primitive adds no value because the calling service knows exactly what tools it needs at compile time. Use gRPC, HTTP, or whatever the monorepo standard already is.
• A webhook receiver. Webhook delivery is push-style server-to-server with a known payload shape. No discovery, no session, no agent loop. A webhook receiver is an HTTP POST endpoint with HMAC verification. Wrapping it in MCP solves no problem and introduces a session lifecycle that webhooks do not have.
• A browser app that needs to call three endpoints. Browser apps want REST or GraphQL because the tooling for both is mature and the call surface is fixed at build time. An MCP client SDK in a browser app is a configuration burden with no payoff.

The unifying property: when the consumer is not an agent and the call surface is known at compile time, MCP's runtime-discovery benefit is value the consumer never realizes.

The migration path

A team that already has an HTTP API and wants to add MCP support follows a short path:

1. Inventory the HTTP endpoints. Sort them into the ones an AI agent would plausibly call (tools and resources) and the ones an AI agent would not (admin, internal, billing operations).
2. Write an MCP server that exposes the agent-relevant subset. Each MCP tool definition maps to one HTTP endpoint plus the JSON Schema of its request body. Each MCP resource definition maps to one HTTP GET endpoint plus the JSON Schema of its response.
3. Wire the MCP server to authenticate against the HTTP API as a service principal, with rate limits and audit logging at the HTTP layer.
4. Ship the MCP server as a separate process. Document the registration string the agent runtime needs (mcp install for Claude Code, mcpServers in Cline, similar for the others).

A team going the other direction (MCP-first to HTTP-second) follows a longer path because the business logic has to be lifted out of the MCP layer first. The order matters.

What to read next

Claude Code starter template guide: a 2026 guide to building production-grade Claude Code agents, including MCP server installation. What is data for AI: the data layer that sits behind any agent surface. AI analyst desks: an end-to-end example of an agent-driven publishing surface where MCP is one of several integration paths.