MCP vs API: What's the Difference?

Home › MCP vs API

An HTTP API is a set of routes your own code calls. MCP is a session between a client and a server, with JSON-RPC messages and a required initialize handshake. Both can travel over HTTP. That overlap is why the two get compared, and it is also why a URL alone does not tell you which one you are looking at. This page uses the MCP lifecycle spec and the transport spec for the MCP side, and ordinary HTTP API practice for the other side. Where a vendor on this directory is the example, the sentence links to that fact sheet.

Who calls what

Your application calls an HTTP API. You pick the route, the method, and the body. The documentation lists those routes. There is no standard handshake that discovers them at runtime, unless that particular API added one.

An MCP client calls the server on behalf of a model, after you approve the config. The client speaks the protocol. The model does not open a socket itself. During the operation phase the client can ask the server for tools, and later invoke one, only if the server negotiated the tools capability. The host is supposed to keep the person in the loop for tool calls. That approval step is a client product behavior. The lifecycle spec requires the initialize order; it does not specify a user-interface for approval.

Discovery

An HTTP API documents its routes in a reference, an OpenAPI file, or both. If the docs and the server disagree, you are debugging that vendor's API. Nothing in HTTP itself makes the server return a machine-readable list of routes.

An MCP server returns its tool list from tools/list when it offers tools. The list can change during the session if the server negotiated listChanged. Resources and prompts are separate capabilities, negotiated on their own. A client that never received the tools capability has no reason to call tools/list. The read-only tester sends initialize and, only if that succeeds, tools/list. It does not send tools/call, so it cannot be used as a general API client.

Message shape

MCP messages are JSON-RPC. A request has an id and a method. A notification has a method and no id. The initialize response is a result object with protocolVersion, capabilities, and serverInfo. Errors use a JSON-RPC error object. The lifecycle chapter's example of a version mismatch uses error code -32602 and a data object with the supported and requested versions.

An HTTP API does not have to be JSON-RPC. It might be JSON over REST, form posts, or something else. Status codes are HTTP status codes. There is no standard protocolVersion field. Versioning, when it exists, is that API's own header, path prefix, or query parameter. MCP's HTTP transport adds its own rule on top of HTTP: after initialization, the client must send MCP-Protocol-Version. A missing header falls back, on the server side, to assuming 2025-03-26 only when the server has no other way to know the version. That fallback is part of MCP, not part of HTTP in general.

Transport

APIs are HTTP (or another application protocol the vendor chose). MCP servers are often HTTP too, and often a local stdio process. stdio has no URL. The client starts a program and writes to its stdin. Comparing "the API" to "the MCP server" is incomplete if one of them is a local process and the other is a hosted route.

Streamable HTTP still is not "a REST API that happens to mention tools." The client POSTs one JSON-RPC message at a time to a single endpoint. The response is either one JSON object or an SSE stream. GET on that endpoint is for server-initiated messages, and 405 means the server does not offer that stream. Session state, if the server wants it, is the Mcp-Session-Id header, not a cookie this directory tells you to set.

The older HTTP+SSE transport from revision 2024-11-05 is deprecated in the 2025-06-18 transport chapter. A fact sheet says SSE only when the registry remote's type is SSE. It does not relabel a Streamable HTTP URL as SSE.

Authentication

Both kinds of service can require a token. The resemblance stops at the word. On MCPwell, the Auth line means only what the registry entry declares: a secret HTTP header, a secret environment variable, or neither. A hosted server with no declared secret often expects you to sign in with the vendor account. The fact sheet says that when it is the case, and it does not invent a header name.

An HTTP API's auth guide might describe OAuth scopes, API keys, or signed requests in more detail than the registry entry does. This directory does not copy that guide onto the MCP page. If you need the vendor's API auth, use the vendor's API docs. If you need the MCP entry's declared credential, use the fact sheet.

A vendor can offer both

Stripe's fact sheet is the registry record com.stripe/mcp. The entry publishes an MCP endpoint. Stripe also documents an HTTP API for the same company at docs.stripe.com/api. Those are different fronts. The fact sheet does not claim the MCP endpoint covers every API route, and this page does not claim it either. The same split shows up for other vendors in the directory: the page you want is the one whose source link you can open.

GitHub is another case where a company publishes a developer API and, separately, an MCP server under its registry namespace. The fact sheet cites the registry or the repository. It does not treat the REST reference as if it were the MCP tool list.

Errors and timeouts

HTTP APIs use status codes and their own error bodies. MCP over HTTP uses both. A transport failure can be an HTTP 400, 404, or 405, as the transport chapter describes for bad protocol versions, dead sessions, and servers that do not offer a GET stream. A protocol failure can be a JSON-RPC error with the HTTP status still 200, depending on the server. The lifecycle chapter tells implementers to time out requests and to cancel work that does not finish. None of that is a promise about a particular vendor's latency. This site does not publish response-time numbers.

How to choose on this site

If you are writing application code that calls a vendor, you want that vendor's API reference. If you are connecting an editor or desktop client so a model can use the vendor's tools, you want the MCP server, and you want the transport and credential the registry actually declared. MCPwell is the second of those. The comparisons put two MCP servers side by side. They do not compare an MCP server with a REST API, and they do not pick a winner from traffic we do not have.

Selection of what is listed is the same rule as the rest of the directory: vendor namespace in the official registry, or a reference server from the MCP servers repository or MarkItDown. A third-party wrapper that uses a vendor's name in the repository title is not listed as that vendor. That is why a search of the registry for Slack, which returns servers published by other namespaces, does not become a Slack fact sheet here.

FAQ