Is an MCP server like an API? What actually differs

Yes and no. An MCP server is an API in the broad sense — a networked interface with a schema, auth, and error codes — but it is not a REST API. It speaks JSON-RPC 2.0, advertises its own tools at runtime, and keeps session state, because its consumer is a language model rather than a developer.

The short answer: same plumbing, different consumer

Strip away the branding and an MCP server is a process that receives structured requests and returns structured responses. That is an API. The reason people argue about it is that "API" in everyday engineering conversation means "REST endpoint documented in an OpenAPI spec that a human reads before writing a client". Measured against that, MCP is a different animal: the contract is discovered by the caller at runtime instead of compiled in ahead of time.

The most useful framing is by consumer. A REST API is written for a developer who reads documentation, decides which of the 90 endpoints matters, hard-codes the path, and ships. An MCP server is written for a model that will read a short tool list mid-conversation and decide, in one shot, which tool to invoke and with what arguments. Everything that differs — message format, discovery, statefulness, error phrasing — follows from that one change of audience.

And the two live in the same stack. Most MCP servers in production are thin adapters over an existing HTTP API: the tool handler validates arguments, calls POST /v1/something, and reformats the result into text or JSON the model can use. Merge makes this point bluntly — MCP does not replace APIs, it wraps them, and without an API underneath you are back to brittle scripts (Merge). Our own web scraping MCP server is exactly that: the same eight capabilities the REST API exposes, re-shaped for tool calling.

What an MCP server actually looks like on the wire

If you have never opened the traffic, here is the honest version. MCP messages are JSON-RPC 2.0. Transport is either stdio (the server is a local subprocess, messages go over stdin/stdout) or Streamable HTTP for remote servers, with Server-Sent Events for server-to-client streaming. The specification also defines an authorization profile based on OAuth 2.1 for HTTP transports, which is newer than most people's mental model of MCP as "an unauthenticated local script" (MCP specification).

The session lifecycle

A connection is not a single request. It is a handshake, then a discovery step, then any number of calls that share state:

1. initialize — client and server exchange protocol version and capabilities.
2. tools/list — the server returns tool names, descriptions, and JSON Schema for inputs. This is the documentation, delivered as data.
3. tools/call — the model picks a tool; the server executes and returns content plus an isError flag.
4. Notifications — the server can push notifications/tools/list_changed or progress events without being asked, which REST cannot do without webhooks or polling.

That state is the second real difference. REST is stateless by convention: every request carries everything it needs. An MCP session accumulates context, which is what makes multi-step work cheap to express — the client does not resend the whole world on turn seven.

MCP vs API: the differences that matter

Dimension	REST API	MCP server
Primary consumer	Developer writing code	LLM choosing a tool at runtime
Contract discovery	Read docs / OpenAPI, then hard-code	tools/list returns names, descriptions, JSON Schema
Message format	HTTP verbs + JSON or XML, varies per vendor	JSON-RPC 2.0, uniform across servers
Transport	HTTP(S)	stdio or Streamable HTTP + SSE
State	Stateless per request	Stateful session after initialize
Surface size	Often 50-100+ endpoints, all equal	A handful of curated, task-shaped tools
Change management	Client redeploy when paths change	Update the schema; clients rediscover
Errors	HTTP status codes, vendor-specific bodies	Protocol errors plus tool errors written for a model to read
Auth	API keys, OAuth 2.0, per-vendor	No universal default; OAuth 2.1 profile for HTTP transports
Debugging	curl, Postman, access logs	MCP inspectors, transcript inspection

Two facts worth keeping from the wider literature. Auth0 notes that enterprise APIs commonly expose 75-100 endpoints and that models get measurably worse at choosing when handed long, similar-looking option lists — so curating a small tool surface is a performance decision, not aesthetics (Auth0). Codecademy frames the structural gain as turning M×N bespoke integrations into M+N standardised ones, with the crossover point around three to five integrations (Codecademy). Below that, a direct API call is less machinery for the same result.

MCP vs API example: one scrape, two shapes

The clearest way to settle "is an MCP server like an API" is to run the same job both ways. Direct HTTP first — one page to Markdown through the Web Scraping API:

curl https://api.quanticdata.io/v1/scrape \
  -H "Authorization: Bearer $QD_API_KEY" \
  -d '{ "url": "https://example.com" }'

{ "success": true,
  "data": { "markdown": "# Example Domain\n…" },
  "usage": { "cost_usd": 0.0002 } }

Deterministic: you chose the endpoint, you knew the field names, you can diff the response in CI. Now the same capability as a tool call, which is what the agent's client emits after reading tools/list:

{ "jsonrpc": "2.0", "id": 7,
  "method": "tools/call",
  "params": {
    "name": "scrape",
    "arguments": { "url": "https://example.com", "format": "markdown" }
  } }

Same backend, same proxies, same envelope underneath. What changed is who decided to call it and when. Wiring the server into a host takes one command:

claude mcp add quantumproxies \
  -e QUANTUMPROXIES_API_KEY=qp_live_your_key_here \
  -- npx -y quantumproxies-mcp

# eight tools appear: search, scrape, map, crawl,
# crawl_status, batch, batch_status, seo_audit

Note the shape of those eight. They are not one tool per HTTP parameter; they are jobs an agent actually wants — find sources, read a page, list a site, walk a site, re-check a known list, compare rendered versus unrendered HTML. Full parameter reference lives in the API documentation, and both paths share one key and one allowance.

Is an MCP server like an API gateway?

People reach for the gateway analogy because both sit in front of other services, and it half fits. A gateway does policy for many upstream APIs: routing, authentication, rate limits, quotas, logging. An MCP server does translation for one logical capability set: schema advertisement, argument validation, response formatting for a model.

The overlap becomes real at scale, which is why "MCP gateway" products exist. Once an organisation runs a dozen MCP servers, you want exactly the gateway concerns — which agent may call which tool, on whose behalf, how often, with what audit trail. Two things gateways handle that plain MCP does not give you for free: identity binding (the agent acts for a specific user with delegated, scoped permission) and tool filtering so a model is not handed 200 tools it will fumble. Treat MCP as the protocol layer and the gateway as the control plane; they stack, they do not compete.

When to use MCP vs API

A decision rule that has held up for us:

1. Fixed, scheduled, high-volume work: call the API. A nightly price refresh over 40,000 known URLs has no decisions in it. Put it in a POST /v1/batch job and keep the cost and the failure mode boring.
2. Unbounded, exploratory work: give the agent MCP. "Find every dental clinic in Lyon with a website and pull their opening hours" needs search, then mapping, then scraping, with branching at each step. That is dynamic tool selection, and it is what the web data API for AI is shaped for.
3. Fewer than about three integrations and no model in the loop: skip MCP. The protocol earns its keep when the number of client-to-service pairs grows.
4. Retrieval into a store you control: API. Filling a vector index or a warehouse table is a pipeline, not a conversation.
5. Writes and side effects inside third-party systems: MCP, behind a gateway. Runtime discovery plus per-tool authorisation beats hard-coding twelve mutation endpoints into an agent prompt.
6. Both, usually. Build the HTTP API first because it is testable, then expose a curated subset as tools. That order also means your agent path inherits the retries and proxy rotation you already debugged.

If you are still deciding whether you need a managed data endpoint at all, our primer on what a web scraper API is covers the non-agent half of this question.

The cost math nobody puts in the comparison table

MCP moves work into the context window, and context is billed. Every turn where the model can see your tool list, it pays for that list in input tokens. Eight tools with tight descriptions and small schemas is a few hundred to a couple of thousand tokens per turn; a naive OpenAPI-to-MCP dump of ninety endpoints can be an order of magnitude worse, and it degrades selection accuracy at the same time. Tool curation is the cheapest optimisation available to you.

The second cost is failure. Agents explore, which means they call tools that return nothing useful — a blocked page, a dead URL, a bad selector. On per-request billing you pay for all of it. That is why our metering is pay per success: a response with success: false costs $0.00, and async jobs charged up front on requested volume auto-refund the unfetched share when they settle. Concretely, a crawl priced at $0.0003 per page that only fetches 180 of 500 requested pages refunds the difference rather than billing intent.

Then the unit prices, so you can model an agent run instead of guessing: $0.0002 per scraped page ($0.001 with JS rendering), from $0.0005 per search on the SERP API, $0.0005 to map a whole site's URLs, $0.0012 per SEO audit. An agent task that runs three searches, maps one site, and scrapes sixty pages lands around two cents of data cost — almost always less than the tokens spent reasoning about it. That ratio is the argument for keeping the tool surface small and the per-call outcome cheap.

What the arguments on Reddit and GitHub keep circling

Three recurring positions, and what we think each gets right.

"It is just REST with extra steps"

Right about the transport, wrong about the target. You cannot hand a model an OpenAPI document and get reliable behaviour, because the document assumes a reader who can infer, search, and retry with judgement. MCP's contribution is a machine-negotiated contract plus the discipline of writing descriptions for a non-human reader.

"MCP servers are not APIs"

A definitional stance rather than a technical one. An MCP server is a service with a typed interface; it is usually a wrapper over one or more APIs. Calling it "not an API" is only useful as shorthand for "do not expect REST semantics".

"The security story is immature"

Fair, and worth taking seriously. MCP has no universal built-in auth or secret management — each server implements its own, and the risks specific to tool ecosystems (prompt-injected tool descriptions, servers that change behaviour after install, session hijacking) do not have decades of hardening behind them the way OAuth flows do. Pin server versions, review tool descriptions as untrusted input, scope credentials per tool, and log every call. This is engineering guidance, not legal or compliance advice.

So: is an MCP server like an API? It is an API whose documentation is executable and whose caller is a model. Build the HTTP layer for determinism, expose a small tool surface for autonomy, and let the same billing and retry logic sit under both.