MCP vs REST API: What Changes When an Agent Talks to Your CMS Directly

If you already know REST well, most MCP explainers will annoy you. They either sell it as a magic layer that makes integration disappear, or they walk through the JSON-RPC wire format without ever saying why you'd care. Only one thing actually changes between the two, and everything else follows from it.

What is a REST API, and what is MCP?

A REST API is an interface you write a client against. You read the docs, decide which endpoints match your intent, and write code that maps one to the other: auth, pagination, schema, retries and all.

MCP (Model Context Protocol) is a protocol a system uses to describe its own capabilities to an agent. The model discovers the available tools and calls them at runtime, so you don't write bespoke integration code for each one.

People frame this as old way versus new way, which misses it. The question is who maps intent to calls, and when. With REST, you do it at development time, in code you then maintain. With MCP, the model does it at runtime against a described tool surface. Every benefit and every trade-off below comes out of that one shift.

With REST, the integration is the work

The endpoints are usually the easy part. The work is everything around them: getting and refreshing a token, working out which of forty endpoints you need, handling pagination that differs between collections, mapping field names onto your own model, deciding what to do on a 429, and writing tests that catch it when the vendor changes a response shape. Then the API version moves, and the client you wrote is now the thing you maintain: a small, permanent piece of software with its own upgrade path.

That's not a knock on REST. It's a stable, cacheable, inspectable contract that has survived twenty years because it's genuinely good. The problem shows up in one place: for one-off or low-volume work, the ratio of integration effort to actual task is terrible.

MCP doesn't remove that work, it moves it. The server author writes the tool definitions once (names, input and output schemas, descriptions), and every agent that connects gets that surface.

The same task, two ways: 40 events from a spreadsheet

Say you need to publish 40 event entries from a spreadsheet, resize the images, and fix the slugs.

As REST integration work, that's a script. You read the sheet, authenticate, find the create-event endpoint and its required fields, discover that dates want a specific format, upload each image through a separate media endpoint, wire the returned asset ID back into the event record, write a slugify function matching the CMS's own rules and get it slightly wrong, add rate limiting when the twelfth request fails, and re-run it against staging a few times. At the end you own a script for exactly this shape of spreadsheet.

As a prompt against an MCP server, it's a sentence and a file path, run in Claude Code or Cursor: "Read events.csv, create an event entry for each row, scale the images to the standard sizes, and make the slugs consistent with the existing ones." The agent lists the available tools, sees that event creation, file upload and image scaling exist, reads a couple of existing events to infer the slug convention, and executes.

The asterisks are real. The agent may pick a different call sequence than you would have, it costs actual tokens, and 40 entries means a lot of round trips. Run it against staging and diff the result. And if this turns into a nightly job for 4,000 rows instead of a one-off for 40, go write the REST script after all. That's the decision boundary, and it has very little to do with which protocol is more modern.

MCP vs REST API: where each one wins

When you should write a REST client instead

Write the client by hand whenever you can't tolerate a model choosing the call:

• High-volume automated pipelines. A nightly sync of 10,000 records shouldn't pay per-call token cost or re-derive its plan every night.
• Strict contracts. If a regulator, an SLA or a downstream system depends on exactly which fields get written, you want code you can read, not a plan reconstructed from logs.
• Anything where a wrong call is expensive: bulk deletes, permission changes, anything irreversible. Give the agent read access and a human the write button.
• Pulling content into another system. A search index, a mobile app or a static build wants a cacheable, predictable HTTP response, not a conversation.

MCP doesn't replace any of that. It's a protocol layered over capabilities that still have to exist: if the CMS can't scale an image, no amount of tool description makes it possible.

Native MCP server vs a wrapper someone built around the REST API

A native MCP server is implemented inside the system itself. A wrapper is a separate process translating MCP tool calls into REST requests against a public API. Both speak the same protocol, and they behave differently in production for four reasons:

1. Coverage is capped by the author's imagination. A wrapper exposes the endpoints its author happened to think about. Anything not wrapped is invisible to the agent. Not documented-but-hard, invisible.
2. Auth is bolted on. The wrapper holds an API token and acts as one user, so per-role permissions tend to flatten.
3. It lags. New features arrive in the product, then in the API, then in the wrapper. You feel the gap exactly when you want the new thing.
4. It's another dependency: a third process to deploy, monitor and upgrade, sitting between your agent and your content.

Wrappers are genuinely useful. They're how most systems get MCP support at all, and a good one beats no support. Just know which kind you're running before you build a workflow on it. We went through this in more depth in native MCP vs an MCP wrapper.

What the 2026 spec changed, in one paragraph

The 2026-07-28 revision made MCP stateless. The initialize handshake and the Mcp-Session-Id header are gone, each request carries its own protocol version and client capabilities, and a new server/discover RPC advertises what a server supports. Tool, prompt and resource listings became cacheable via ttlMs and cacheScope, and server-initiated requests were replaced by Multi Round-Trip Requests, where a tool returns input_required and the client retries with the answers. If you looked at MCP in 2025 and found the session handling awkward to operate, that specific complaint is dealt with: servers can now sit behind an ordinary load balancer.

Where Neleto sits

Neleto is a complete CMS with an MCP server built into the product itself rather than a wrapper around its own REST API, so the tools an agent sees are the CMS's own capabilities: pages, blog posts, events, files, components, layouts, image scaling. The agent acts with the role of the person who connected it, not a shared admin token. It works with Claude Code, Cursor and Windsurf.

There's also a REST API, for pulling content into a search index, an app or another system where you want a predictable HTTP response and not a model deciding anything. We're not going to pretend the MCP server is the right tool for a nightly 10,000-record sync.

Other CMSes offer MCP support too, natively and through wrappers, and the space is moving fast. The question worth asking any vendor isn't whether they have MCP. It's whether it's native, how much of the product it actually covers, and whether it respects your role permissions.

Try it yourself: Point Claude Code or Cursor at a Neleto instance on the free plan and ask it to list the available tools. That ten-minute test tells you more about any MCP server than a comparison table will.