1 July 2026 · The Agent Examiner Editorial
MCP-native vs bolt-on: what it means for agent platforms
The short answer
An MCP-native platform treats the Model Context Protocol as a first-class way to add capabilities: any compliant server works, configuration is built in, and tool support keeps pace with the standard. A bolt-on platform supports MCP partially or through a workaround, so tool breadth is narrower and behaviour can lag. Native support means less glue and less lock-in.
Two platforms can both claim "MCP support" and mean very different things. One treats the Model Context Protocol as a first-class citizen; the other bolts on a partial adapter. That gap shows up in how many servers you can use, how reliably they work, and how locked in you become. This guide explains the difference so you can read a platform's MCP claim critically.
If you are new to the protocol itself, start with What is MCP?.
What "MCP-native" means
A platform is native when MCP is a primary, supported path to adding capabilities:
- Any spec-compliant MCP server works, not just a curated allow-list.
- Configuring a server is a built-in flow, not a hack.
- Both common transports (stdio and HTTP/SSE) are handled.
- Support tracks the evolving standard rather than freezing at one snapshot.
The practical payoff: the whole MCP ecosystem — everything in our directory — is available to you, and swapping platforms later doesn't strand your integrations.
What "bolt-on" looks like
A bolt-on implementation supports MCP partially or through a workaround:
- Only certain servers or transports work.
- MCP is mapped onto an older, platform-specific tool system, so some behaviour is lost in translation.
- New protocol features arrive late, if at all.
It can be perfectly usable for a narrow set of blessed servers — but you inherit the platform's limits, and you may be doing extra glue work to make a given server behave.
How to tell them apart
| Signal | Native | Bolt-on |
|---|---|---|
| Server support | Any compliant server | Curated / limited list |
| Transports | stdio and HTTP/SSE | Often one only |
| Configuration | Built-in, first-class | Manual or workaround |
| Keeping up | Tracks the standard | Lags the standard |
| Lock-in risk | Lower | Higher |
We capture this as a single MCP support fact on every platform dossier — native, partial, none, or unknown — sourced from the vendor's own materials. It is not a marketing label; it is a recorded, cited claim.
Why it matters for your choice
MCP is where agent tooling is consolidating, so a platform's stance on it is a bet on your future flexibility:
- Native keeps the whole ecosystem open to you and lowers switching costs.
- Bolt-on can be fine today but narrows your options and risks lag as the standard moves.
We rank the best MCP-native platforms by our MCP-nativeness score, and MCP-nativeness is one of the six dimensions in every scorecard. For agents whose whole value is tool access — like research assistants — native support is close to a requirement.
Read the claim critically
When a platform says it "supports MCP", ask: which servers, which transports, and how current? The platforms directory records the answer we found for each, with a source link — and where we couldn't verify it, the fact is marked unverified rather than assumed.
Next steps
- See the recorded facts: AI agent platforms, compared.
- Put a server to work: How to connect an MCP server.
By The Agent Examiner Editorial · last updated 2026-07-01. See our methodology and disclosure.