These three get compared constantly, usually with the implication that they're competitors. They're not — each answers a different question, and a single resource commonly uses all three layered together. This guide is about untangling which does what.
The three questions
| Protocol | Answers |
|---|---|
| REST API | "Here is a fixed set of endpoints, each with a defined request/response shape." |
| MCP | "How does a client discover what tools a server offers, and their schemas, at runtime?" |
| x402 | "How does a caller pay for a specific request, per call, with no account?" |
REST is the baseline: an interface convention, not a discovery or payment mechanism. MCP adds runtime discovery on top of an interface (REST or otherwise). x402 adds payment on top of an interface (REST or otherwise). None of the three requires the others.
Why "REST vs. MCP" is a category error
A REST API is a contract; MCP is a way of describing and discovering a contract at runtime instead of via static documentation a human read once. In practice, most MCP tools are thin wrappers around a REST endpoint — the MCP server's tools/call handler often just makes an HTTP request and returns the result. The real comparison isn't "REST or MCP," it's "does the caller already know your API's shape (call REST directly) or does it need to discover that shape at runtime (go through MCP)." Agent Bazaar does both simultaneously: a plain REST endpoint and an MCP server that wraps the same underlying function.
Why "REST vs. x402" is also a category error
x402 isn't an alternative interface style to REST — it's a status code and response convention (402 plus an accepts[] body) that sits on top of whatever interface you already have, REST or otherwise. An x402-priced endpoint is still, mechanically, a REST endpoint; it just returns 402 instead of the resource when payment hasn't been provided yet. See What Is x402? for the mechanics.
How all three stack on one real resource
Take Solana Token Security Intelligence as a concrete example:
- REST:
GET /api/security/{mint}is a normal HTTP endpoint with a defined request shape. - x402: calling it without payment returns
402withaccepts[]; calling it with a valid payment proof returns the report. - MCP: the same data is reachable through Agent Bazaar's MCP server via
get_resource, which returns the resource's full record including itsaccepts[]— an agent that already speaks MCP doesn't need to know the raw REST shape at all.
One resource, one underlying implementation, three protocols each solving the piece they're actually good at.
Where A2A fits in relative to all three
A2A operates one level up from all of this — it describes an agent (a general-purpose actor), not a specific endpoint or tool. An agent's A2A card might list "skills" that are themselves backed by MCP tools or plain REST endpoints, some of which might be x402-priced. See How Do Agents Discover Other Agents? for where that boundary actually sits.
Decision guide
| If you need... | Reach for |
|---|---|
| A caller that already knows your API's shape to call it directly | Plain REST — no extra protocol needed |
| A caller to discover your tools' shape at runtime, with no prior integration | MCP, layered on top of your REST implementation |
| Per-request payment with no account system | x402, layered on top of your REST implementation |
| To describe an autonomous agent as a whole, not a single endpoint | A2A, describing the agent that may use any/all of the above underneath |