MCP Server vs REST API for AI Agents: When to Build Which

Your engineering team spent three weeks building a custom Model Context Protocol (MCP) server. You translated every REST endpoint into an MCP tool definition, set up a server process, and loaded it into Cursor.

The first test ran. Half the context window vanished into JSON schemas before the user typed a prompt.

Why developers reached for MCP servers first#

Model Context Protocol solved a genuine mess: every AI tool runner had its own plugin format, its own configuration syntax, and its own execution engine. Standardizing tool discovery and structured prompt injection across Claude Code, Cursor, and Windsurf was necessary.

If your service needs to expose local files, stream real-time IDE diagnostics, or provide complex interactive prompts, an MCP tool is the natural primitive. The protocol earned its place.

The costs of turning every API into an MCP server#

Turning an existing cloud API into a private MCP server changes the economics of every conversation:

Context window depletion. Every tool definition in an MCP server lives inside the model's system prompt on every single turn. Five tools with detailed schemas consume thousands of tokens before a user asks a single question. In a 200,000-token window, holding twenty tools across three servers burns up to 30% of your usable context on tools the current task never touches.

Tool selection degradation. Language models struggle when presented with large menus of similar tools. Benchmark tests demonstrate that tool-selection accuracy drops sharply as tool counts grow beyond twenty. Giving an agent forty custom MCP tools often leads to hallucinations, parameter errors, or wrong tool selection.

Hosting overhead. An MCP server requires a running process, WebSocket connection, or persistent SSE transport. For an API that already handles millions of standard HTTP requests per day, maintaining parallel stateful MCP servers introduces extra infrastructure to monitor, deploy, and scale.

The alternative: REST APIs with autonomous discovery#

Your existing REST endpoints already have rate limiting, database connections, permission checks, and monitoring. An AI agent running in Claude Code or Cursor already has tools to fetch URLs and execute curl commands.

What the agent lacked was not another protocol. It lacked two simple things:

1. Discovery: Knowing where your endpoints live and what parameters they accept.
2. Identity: Proving who authorized the request without leaking raw API keys into chat logs.

[ Agent ] ──> reads https://notes.com/auth.md (Discovery)
    │
    ├──> calls get_token tool via Remote MCP (Identity)
    │
    └──> calls POST https://notes.com/api/notes (Standard REST)
              Header: Authorization: Bearer <5-minute-jwt>

A static file at the root of your domain (auth.md) handles discovery in a few hundred tokens. A lightweight token verification check (@agentonboard/sdk) inside your existing route handler handles identity in three lines of code.

When to build an MCP server vs keep your REST API#

What this changes in practice#

Instead of maintaining a bespoke MCP server for your app, you publish an auth.md file in your public/ directory and add token verification to your existing routes.

When an agent needs to perform an action, it reads auth.md, requests a 5-minute scoped token for your domain, and sends a standard HTTP request to your API. When the task is done, the token expires. Your API served the request through your existing database layer, and the user's context window remained clear.

The docs show how to verify tokens in Next.js, Express, Hono, and FastAPI.