If you already know what MCP is, the next question is the one vendors are vaguest about: is this MCP server part of the product, or a translation layer built on top of its public API? On day one you often can't tell. Both advertise a tool list, both work in the demo, and the difference shows up two weeks later, off the happy path.
What is an MCP wrapper, and what is a native MCP server?
An MCP wrapper is a separate process that translates MCP tool calls into calls against a product's public API. It runs beside the product, holds credentials for it, and can only do what that API already permits.
A native MCP server is part of the product itself. It shares the product's data model, permission system and internals, the same code paths the product's own UI uses. (We've written a deep dive on MCP servers if you want the architecture in more detail.)
Both implement the same protocol, so any agent connects to either. What differs is what sits behind the tool definitions: a public contract seen from outside, or the product from inside.
Where does a wrapper hit its capability ceiling?
A wrapper can expose two things and no more: what its author thought to expose, and what the public API can already express. Anything the API can't say, the wrapper can't do. Not "harder", can't.
The agent never sees the ceiling. The model doesn't report a missing capability. It reads the tool list, concludes the thing is impossible, and improvises around it.
In CMS terms: if the API creates pages but has no endpoint that validates a component's markup before saving, the wrapper has no validation tool to offer. If image scaling lives in the rendering pipeline rather than behind an endpoint, the agent can only upload files and hope. None of that is the author's fault, since they build against the surface they were given.
What happens to permissions when an agent goes through a wrapper?
Wrappers typically authenticate as a single API token, which flattens whatever role model the product has. Anything that token can do, the model can do, for every user of that wrapper. It's least visible in a demo, because demos are run by whoever owns the token.
Picture a CMS with four roles (Neleto has Admin, Developer, Editor and Author) and a wrapper holding an admin token because that was fastest. An Author asks the agent to "clean up the old campaign pages." The role model says they may edit their own drafts. The token says they may delete anything. The token wins.
A native MCP server can enforce the product's own roles, because it sits inside the product and knows who is connected. That's how Neleto's server works: the agent gets the permissions its human has, and a refusal arrives as the CMS's own authorization error rather than a surprise deletion.
Why does a wrapper drift behind the product?
A wrapper lags the product by however long it takes someone to update the wrapper. Ship a feature, and the agent can't use it until three things happen: the feature exists, the API exposes it, and the wrapper author wraps it. Only the first is on the vendor's roadmap.
Community wrappers drift furthest, because the maintainer's interest isn't tied to the release cycle. Vendor-built wrappers drift less but still drift. A wrapper is a second codebase, and second codebases get updated second.
It fails quietly, too. Nothing errors. The agent works from a stale picture of the CMS, and you get a competent solution to last year's problem.
Why do thin wrapper tools cost more tokens and fail more often?
A wrapper composed of thin, endpoint-shaped tools turns one intent into many round-trips, and every round-trip costs tokens, latency and a chance of failing.
One instruction, "publish this post with a hero image scaled to the standard sizes", plausibly becomes: list content types, fetch the post schema, create a draft, upload the asset, request the derivatives, poll until they exist, patch the post with the asset ID, publish. Eight calls, each dropping a full JSON payload into the model's context, each a place where a timeout leaves a half-created draft pointing at an image that doesn't exist yet.
Something native can expose a coarser, task-shaped tool that does the job in one call, inside a code path the product already treats as a unit, so a failure fails cleanly instead of stranding state halfway. We've measured what this is worth on our own server: reshaping image ingest around the task instead of the endpoints took the same AI build from 30 minutes to 4.
That's about tool granularity rather than nativeness. A wrapper can be written with coarse tools, and good ones are. It's just harder when you compose endpoints instead of calling internals.
What does the extra dependency actually cost you?
A wrapper is a third process to deploy, secure, update and debug between your agent and your content. When something breaks, you have three things in the chain instead of two.
A credential for your CMS now lives in another process's environment. And "failed to update page" now has four possible causes: the CMS rejected it, the API rejected it, the wrapper mistranslated it, or the wrapper runs against an older schema. Finding out which one needs logs from a process you probably didn't instrument.
Native MCP vs MCP wrapper, side by side
| MCP wrapper | Native MCP server | |
|---|---|---|
| Capability ceiling | Bounded by the public API and the author's coverage | Bounded by the product itself |
| Permissions | Usually one API token; role model flattens | Can enforce the product's own roles per user |
| Drift on product updates | Lags until someone updates the wrapper | Ships with the feature |
| Round-trips per intent | Often many, endpoint-shaped | Can be one, task-shaped |
| Links in the chain | Three: agent, wrapper, product | Two: agent, product |
| Best for | Read-heavy and simple write work; products whose vendor ships no MCP server | Multi-role teams, deep write workflows, anything where partial failure matters |
When is a wrapper the right answer?
Often. Wrappers are how most products get MCP support at all, many are excellent, and a good wrapper beats a bad native implementation every time.
Take that literally. A native server covering 20% of a product is worse than a wrapper covering 80%, and "native" guarantees nothing about tool design. A vendor can ship a first-party MCP server that's just its REST endpoints with a new coat of paint.
Prefer a wrapper, or be happy with one, when the work is read-heavy: analysis, drafting and migration audits rarely touch the ceiling or the permission problem. When the vendor ships nothing, a community wrapper is the difference between a product having MCP and not having it. When it's one person and one token, a solo operator who's already the admin loses nothing to a flattened role model. When you need it this week, a wrapper can be built in a weekend against a documented API. And when it's actively maintained, a wrapper with a responsive author beats a native server the vendor forgot.
How should you evaluate any MCP integration before you build on it?
Ask the same questions of a wrapper and of a native server. The answers matter more than the label.
- Who maintains it, and when did it last ship? "Official" with a nine-month-old last commit is a wrapper by another name.
- What happens to permissions? Does it act as me, or as one token? If a low-privilege user asks for a destructive operation, what refuses it?
- How does it handle partial failures? If step six of eight fails, what state is left behind, and can the agent recover?
- What happens on a product update? Does the tool surface move with the release, or wait for one of its own? For a wrapper, ask what the gap was on the last three features.
- Task-shaped or endpoint-shaped? If the tool list maps one-to-one onto REST endpoints, expect chattiness and token cost, whoever wrote it.
- How much of the product does it cover? Not "does it have MCP" but "what share of my daily work can it reach." This catches thin native servers.
Where Neleto sits
Neleto's MCP server is part of the CMS, not a separate process translating calls into its own REST API. Agents operate on pages, posts, events, components and files as first-class tools, with the full CMS behind them. That's the claim, and the argument above is why it matters.
Other CMSes have MCP support, natively and through wrappers, and some of those wrappers are very good. We're not claiming a category of one. We're saying that if you're handing an agent write access to your content, the six questions above are the ones to ask, of us as much as anyone else.
Try it yourself: Connect Claude Code or Cursor to a free Neleto project, ask it to list its tools, then give it the most tedious content task on your list this week. If the tool surface disappoints you, you'll know in ten minutes and it cost nothing.
Top comments (0)