Everyone’s an MCP gateway now
When “digital” became a thing, every ad agency became a digital agency.
Overnight.
Same people. Same offices. Same billings.
Just a new word on the door.
The clients couldn’t tell the difference. Not immediately.
They found out later. Usually expensively*
The same thing is happening right now in API management.
MCP — the Model Context Protocol — has gone from emerging spec to enterprise default in under two years. Gartner says 75% of API gateway vendors will have MCP features by 2026.
So every API gateway vendor is now an MCP gateway vendor.
Overnight.
Same architecture. Same plugin system. Same codebase.
Just a new page on the website.
Here’s what most of them actually mean.
They’ve built a plugin.
The plugin sits on top of the existing gateway. MCP traffic comes in, the plugin handles it, life goes on.
It works. In a demo it’s indistinguishable from the real thing.
One competitor launched their “enterprise MCP gateway” last month.
It’s a plugin.
Native is different.
Native means MCP isn’t something you added. It’s something you built for.
Authentication built for agent identity, not just user identity.
Rate limiting built for agent behaviour. Agents retry fast when they hit a wall. A limiter designed for humans will either block legitimate traffic or miss actual abuse.
Observability built for conversation context. Not just “a request arrived.” More like: which agent, which model, which tool call, what it returned, in what sequence.
Audit trails at the tool-call level. Not route-level. Tool-level.
That’s what regulated industries need. That’s what the MCP 2026 roadmap explicitly calls out as the gaps in the raw protocol.
A plugin doesn’t fill those gaps. It papers over them.
The difference doesn’t show up immediately.
That’s the problem.
In normal conditions, a bolt-on airbag and an engineered safety system both technically protect you.
You find out which is which in the crash.
For MCP, the crash is: certificate rotation that kills your gateway. An agent retry storm that looks like a DDoS. A security audit asking for tool-call logs you don’t have. A production incident you can’t debug because your observability stops at the HTTP layer.
These aren’t hypothetical. They’re the things our support team deals with.
So here’s what to actually ask a vendor.
Not “do you support MCP?” Everyone says yes.
Ask: is MCP native to your architecture or is it a plugin?
Ask: show me a real audit log from an agent tool call. Not a diagram. The actual log output.
Ask: what happens when an agent gets a 429 and retries at 100ms intervals? Walk me through the rate limiting behaviour.
The quality of the answers will tell you most of what you need to know.
We produce a lot of content about MCP gateways. Our learning centre covers architecture, enterprise considerations, regulated industries. It’s useful content. It’s also partly there because “MCP gateway” is a high-intent search term and we want to rank for it.
Every vendor is doing the same thing right now.
Which means the content can’t tell you who’s done the engineering.
Only the evaluation can do that.
The land grab is real.
170 people signed up for our MCP gateway webinar before we’d even finished the positioning.
Every serious vendor is moving fast.
But fast and native are different things.
The differentiation won’t be visible for another twelve to eighteen months. That’s when the teams who chose a bolt-on hit the ceiling. Incomplete audit trails. Auth inconsistencies at scale. Observability that stops at the edge of what the plugin can see.
By then, migration is expensive.
Choose the thing that was built for this. Not the thing that was renamed for it.
*Before Tyk.io, Hirsty led a couple of native digital agencies. The madness of pitches against Saatchi and Deloitte ‘Digital’ teams are etched into his memory.
Further reading:
