|
The brittleness of the MCP expansion continued to reveal
itself this last week. Something that gateway providers
are looking to take advantage of by moving in to
centralize and stabilize things. It is clear, even with
the brittleness and sprawl of MCP, the expansion
continues. I was surprised to see GraphQL also poking
it's head out of the toolbox this week, continuing to
show its relevant in the landscape dominated by the MCP
bullhorn. I predict somewhere after a long winter, I make
a similar proclamation for MCP.
9,429 posts went out in the last seven days across the
5,109 API-bearing providers I track, and 6,695 of them
carried an API-related signal in the title. That provider
count is noticeably higher than the one I printed last
week, as I doubled the number of API providers in the API
Evanagelist and APIs.io catalog. I spent some budget
focusing on the portfolios of top VCs, and this week began
diving into the top industries across US, UK, Australia,
and Canada.
|
|
A vast neon protocol-causeway on the dark grid where
a section of glowing roadway has been cut away and
is being re-laid with new angular light-segments,
while streams of travelling light halt at the seam
and reroute — a road rebuilt while traffic is still
on it.
|
MCP Starts Breaking Things
The new spec revision landed, and the people closest to it
spent the week writing about what it costs.
"Who is calling?" is not a new question. It is
the oldest question in API management, and we answered it
for HTTP with keys, then OAuth, then mTLS, then a decade
of arguing about scopes. MCP is now re-deriving that whole
ladder in compressed time, in public, with production
traffic already on it. If you shipped an MCP server in the
last year and have not read a migration note yet, you
will. Plan for the protocol to move under you — because it
is going to keep moving until identity is settled, and
identity is not close to settled.
|
|
A colossal neon gateway-arch on the dark grid that
has grown a second smaller arch directly out of its
own flank, both spans carrying streams of travelling
light through the same illuminated checkpoint
structure — one piece of infrastructure sprouting a
new limb.
|
The Gateway Grows a New Limb
While the spec churned, the API management vendors arrived
in force — and they did not build something new. They
extended what they already sell.
-
Kong: MCP governance as the foundation of your
agentic AI strategy — governance language applied to MCP wholesale, from
a company with fifteen years of it lying around.
-
Port: MCP registry explained, why you need one and
who should own it — the ownership question, which is always the real
question. A registry nobody owns is a wiki page that
rots.
-
Microsoft: MCP in Azure, using API Management for
authentication, access, logging, and governance — the least surprising and most telling post of the
week. Put the gateway in front of it. That is the
entire recommendation.
-
Tyk asks whether we still care about traditional
APIs if agents only use MCP, having already argued that the MCP gateway is just the API gateway growing a
new limb.
-
Sierra published the engineering iceberg under its
MCP gateway — the honest accounting of everything below the
waterline once you actually run one.
-
Cloudflare's Agents SDK cut MCP schema
conversion and added exposure controls — exposure controls. Deciding which tools
an agent is allowed to see is authorization by another
name.
-
MuleSoft laid out Developer Hub vs. MCP Server vs.
IDE Skills — which AI surface you actually need, from a vendor
that now sells three of them.
-
And Redis compared MCP against Agent2Agent with five agent architecture scenarios to help you
choose — protocol comparison shopping, which only exists
once there is something to shop for.
Tyk's question deserves a straight answer, so here is
mine: yes, obviously, because MCP is not a replacement for
your API — it is a second front door onto the same
building. Every one of these posts proves it. Kong is not
governing MCP, it is governing the APIs underneath. Azure
is not authenticating MCP, it is putting API Management in
the path. The gateway grew a limb; it did not grow a new
body. If your API is a mess, wrapping it in MCP produces a
mess an agent can reach faster.
|
|
Many small angular light-craft descending in steady
formation onto a vast dark neon grid, each settling
into its own glowing docking-socket among hundreds
of identical sockets stretching to the horizon —
arrivals becoming routine.
|
And the Servers Keep Landing
None of the above slowed the launches down. This is now
the steady background rate of my pull, week over week.
-
Contentful made Remote MCP generally available — GA, not beta, framed at enterprise scale.
-
Neo4j introduced MCP for Aura, hosted and built
into every instance — note "built into every instance." Not a
thing you install. A thing that is already on.
-
Hygraph introduced its MCP server, GoCardless introduced its MCP for connecting AI to
payments, Axonius announced an MCP server and AI agent for
security and IT, and Spike introduced its MCP for incident response.
-
Alpaca launched MCP servers in public beta for
broker partners — regulated brokerage infrastructure, exposed to
agents, in public beta. Sit with that one.
-
Zyte shipped Agent Skills, Codex, and GitHub
add-ons, and Proxyman documented using its MCP with Codex and
Claude Code.
-
SmartBear went at AI testing from the definition
side — using the Swagger and OpenAPI specs you already
have as the source of truth for AI-driven tests, which
is the correct instinct.
The pattern worth naming: hosted and default is beating
installable. Neo4j putting MCP in every Aura instance and
Contentful going GA on remote MCP are the same move — take
the setup step away. The install friction I keep writing
about disappears when the provider decides you never had
to install anything.
|
|
A dormant angular structure on the dark neon grid,
long dimmed and half-buried, re-illuminating from
within as a single precise beam threads into it and
branches through its interior lattice — an old
machine waking to a new purpose.
|
GraphQL Gets a Second Act
I did not expect to write a GraphQL section in 2026. The
agent wave handed it one.
Every technology that survives gets a second act it did
not plan for. GraphQL spent years being sold as a better
REST and losing that argument on operational grounds.
Being a better agent interface is a different
pitch, on different merits, and it might land — precisely
because the thing agents are worst at is asking for too
much and paying for it by the token.
|
|
A long open rack on the dark neon grid holding many
distinct angular hand-tools upright in individual
glowing sockets, each a different silhouette,
receding toward the horizon under a single bright
overhead light-beam.
|
From My Desk: Eighteen Tools, One a Day
Last week I said there is no platform for API governance
and started shipping the pieces instead. This week I
finished counting them and committed to explaining them
properly.
-
The thesis and the plan: there is no platform for API governance, and eighteen tools for open API governance, one a
day — a daily drip so each tool gets its own argument
instead of drowning in a list.
-
Governance you can call: a federated API governance rule registry, tamper-evident certificates for API governance, and conversational API governance your agent can
call.
-
Agents as a governed audience: giving agents the rules before they author, not
after and governing what agents are allowed to consume. Both are the same idea from opposite ends — the
rules have to reach the agent at authoring time and at
consumption time, or they are decoration.
-
Showing my own work: how I actually use MCP across API Evangelist, how I actually use Agent Skills across API
Evangelist, and a universal install interface for MCP servers.
-
OpenAPI Overlays, continued: splitting public and internal documentation and visual authoring without hand-writing JSONPath.
-
API sprawl: the technical roots of API sprawl and shadow, rogue, and zombie APIs — naming the three kinds of API you did not know you
were running.
-
Onboarding, still nobody's favorite
subject: Zuplo has the onboarding API and points it at the
wrong door, Gloo Platform Portal has the endpoints but
self-serve lives or dies on the platform team, Okta has the endpoint and hides the door, and the standards-side answer: API onboarding without a ticket, via dynamic
registration and software statements.
-
Scores and landscapes: four countries, one rubric — the state of banking
APIs in Australia, the UK, the US, and Canada, VCs bet the fund on agents — do their portfolios
have the foundation?, and how the API Evangelist rating system differs from
other agent-readiness scores.
-
Also: profile, don't invent — how Germany chose
OAuth 2.1 and FAPI 2.0, on the need for artifacts that describe API
products, and investing in your internal capacity when it comes
to AI.
The week's two halves rhyme harder than I expected
when I started reading. The vendors spent it discovering
that governing agent access is just API governance with a
new client type, and I spent it building tools that assume
exactly that. Kong's MCP governance post and my
"governing what agents are allowed to consume"
post are the same argument written from opposite sides of
the invoice.
And the Germany piece is the quiet one I would keep if I
could only keep one. Faced with a national-scale API
authorization problem, they did not invent a German
protocol. They profiled OAuth 2.1 and FAPI 2.0 and wrote
down the constraints. Meanwhile MCP is re-deriving session
handling and refresh tokens from scratch, in public, at
speed. One of those two approaches produces a migration
note every quarter. It is not the one that started from a
profile.
A Conversation: Patrick Kelly on Context Engineering and
Code Mode
I sat down with Patrick Kelly, cofounder and CEO of Sideko, for eighteen minutes on what happens to an SDK company
when the consumer of your API stops being a human
developer. Sideko has spent a couple of years turning API
specs into SDKs, docs, mock servers, and CLIs. Patrick is
now pointing that same code-generation engine at context
engineering through Port of Context — and the thing that
makes it work is code mode: hand an agent a
generated SDK instead of a wall of tools, and it uses the
API the way a developer would.
Three things from it that belong in this week's
argument:
-
Code mode is a codegen problem wearing an agent
costume. The tool-per-endpoint MCP server is the wall of
tools nobody can reason about. Collapsing many
upstream tools into a few is the same discipline as
designing a good SDK.
-
Evals are the genuinely hard part. Not "did the agent respond," but did it
call the right API, in the right order, with the right
arguments. Patrick built a state-control proxy to
measure what actually happened upstream, which is the
accountability layer MCP does not have yet — and it
rhymes exactly with the identity gap the spec admitted
to this week.
-
Messy specs make messy MCP. You
cannot generate a clean agent surface from an OpenAPI
nobody governs. He is rallying behind open tooling
like libopenapi and vacuum to clean them up first.
Watch or listen to the full conversation →
See you next week.
|