MCP vs REST: your API needs a second door, not a rewrite
MCP vs REST isn't a migration decision. It's a second consumer with a different cost model, and the cheap way to build it is the expensive one. Here's the trap.
MCP vs REST gets framed as a migration question, and that framing is wrong. WorkOS published a breakdown of this in MCP vs. REST: The Right Way to Connect Agents to Your API, and the point I want to build on is the one most teams skip: MCP isn't a replacement layer, it's a second consumer of the same backend, with a completely different cost model.
That difference in cost model is where small teams lose money. Not in the protocol.
🧱 Two consumers, one backend
Your REST API was written for a developer who reads docs once, then hard-codes the call. An agent reads your API on every single run, at inference time, and pays for the reading.
| REST consumer | MCP consumer | |
|---|---|---|
| Who reads the docs | A human, once | A model, every session |
| Discovery | Static docs / OpenAPI file | Runtime, via a tools/list call |
| State between calls | The client app holds it | The MCP session holds it |
| Auth | Whatever you shipped (API keys, bearer tokens) | OAuth 2.1 with PKCE |
| Cost of a bad interface | Developer complains once | You pay tokens for it forever |
The WorkOS piece makes the structural point cleanly: most MCP servers just call your REST endpoints internally. Your web app, your mobile client and your integration partners keep hitting the same API they always did.
Key takeaway: An MCP server is not a rewrite of your API. It's a translation layer whose entire job is to make your existing REST endpoints cheap and unambiguous for a model to use.
💸 The token tax is the real design constraint
Here's the trap. The fastest way to ship an MCP server is to loop over your OpenAPI spec and emit one tool per endpoint. It compiles, it works in a demo, and it's the wrong build.
Every tool definition you expose gets injected into the model's context on every turn. Forty endpoints becomes forty schemas the agent re-reads before it does anything useful. WorkOS calls this the token tax, and the fix they point at is designing outcome-oriented tools: model what the agent is trying to accomplish, not how your controllers happen to be split.
Concretely, for a hypothetical booking API:
| Approach | What you expose | What the agent has to do |
|---|---|---|
| Endpoint-per-tool | list_customers, get_customer, list_slots, create_booking, send_confirmation |
Five calls, five chances to pick wrong, five round trips of context |
| Outcome-oriented | book_appointment |
One call. Your server does the five REST calls internally |
The second version is also safer, because the ordering logic lives in your code instead of in a model's guess about your business rules.
If you want to see what those definitions actually cost before you ship them, we built a tool-use token cost calculator that prices function-calling overhead per request, and a function-calling schema generator for drafting the schemas themselves.
🔐 Shipping MCP means shipping OAuth 2.1
This is the part that quietly eats a two-person team's month. MCP took an opinionated stance on authorization: OAuth 2.1 with PKCE. Not an API key in a header. Not basic auth. The spec's authorization section has been revised repeatedly since the protocol was published by Anthropic in November 2024:
| Milestone | What it means for you |
|---|---|
| Nov 2024 | MCP published by Anthropic |
| Mar 2025 | Authorization spec revision |
| Jun 2025 | Authorization spec revision |
| Nov 2025 | Authorization spec revision |
Three revisions to the auth story in under a year. If you hand-roll an authorization server, you are signing up to track that.
The scoped-token part genuinely matters though, and it's not bureaucracy. An agent acting on a user's behalf should not hold a token that can do everything the user can do. Your MCP server should check that the presented token's scopes actually cover the tool being invoked, per call.
# sketch, not a spec quote
tool: cancel_subscription
required scope: billing:write
token scopes: [calendar:read, billing:read]
→ reject. The agent has read access, not cancel access.
Warning: If your current API auth is "one long-lived key per customer," that model does not survive contact with agents. A leaked agent key is a leaked everything key. Scopes are the mitigation.
WorkOS's own pitch here is AuthKit, since it already speaks the spec. That's the sponsor angle and you should read it as one. The underlying advice stands regardless of vendor: don't write your own OAuth server for this. Use something that already implements 2.1 with PKCE, whether that's a hosted provider or a maintained open-source one.
🇱🇰 Why this matters more for a small team here
If you're building from Colombo for overseas clients, agent-accessible APIs are a real competitive line, and one you can cross cheaply.
- The integration tax drops. Historically, getting your product into someone else's workflow meant they wrote a client against your REST API. An MCP server means their agent discovers your capabilities at runtime.
- The work is additive. You are not migrating anything. Your REST API keeps serving what it already serves.
- The cost is bounded and measurable. Tool schemas are tokens, tokens have a price, and you can compute it before you ship.
- Auth is the buy decision, tool design is the build decision. Buy the OAuth 2.1 provider. Build the tool surface yourself, because only you know which five REST calls make up one real user outcome.
For freelancers, there's a nearer-term version of the same skill: writing MCP servers for internal client tooling. It's a small, well-scoped, currently-scarce specialisation. If you're just wiring up local servers to a client, our MCP config generator handles the claude_desktop_config.json and mcp.json boilerplate.
🛠️ The build order I'd follow
- Write down the five things an agent would actually want to accomplish with your product. Plain sentences, no endpoint names.
- Map each to the REST calls it already takes. That mapping is your tool list.
- Define scopes per tool before writing any handler code.
- Pick an OAuth 2.1 provider. Do not build one.
- Measure the schema cost of your tool definitions, then cut until the list is boring.
- Only then write the server.
Step 1 is the one people skip, and skipping it is exactly how you end up auto-generating forty tools.
What this means for you
The headline question, MCP or REST, has a boring answer: both, and they're not in competition. The interesting question is the one underneath it. You are now writing an interface for a consumer that pays per token to read it, guesses when it's ambiguous, and holds credentials on someone else's behalf.
None of those three properties applied to your REST API. All three change what "good design" means.
If you take one thing away: your MCP server's quality is decided by the tool list, not the transport. A thin, outcome-shaped tool list over a properly scoped OAuth 2.1 flow beats a complete one every time. Completeness is what your REST API is for.