Week of July 18 – July 25, 2026
MCP Starts Breaking Things, and the Gateways Move In
The brittleness of the MCP expansion continued to reveal itself this last week. Something that gateway providers are looking to take advanatage 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.
MCP Starts Breaking Things
The new spec revision landed, and the people closest to it spent the week writing about what it costs.
- Arcade: session IDs are going away in the new MCP release — a change to how state is carried between a host and a server, which is exactly the kind of thing that silently invalidates working integrations.
- Arcade again, closing the refresh token gap in the new MCP spec — the unglamorous auth plumbing that every long-lived agent connection needs and the first draft did not fully specify.
- Glama: MCP hosts are an identity blind spot, and the spec knows it — the honest one. When an agent calls your tool, you can authenticate the server and you can authenticate the user, but the host in between is a gap the specification itself acknowledges.
- Salt Security on why MCP security matters and Endor Labs on the security playbook for coding agents beyond MCP — the security vendors have stopped writing explainers and started writing playbooks.
“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.
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.
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.
GraphQL Gets a Second Act
I did not expect to write a GraphQL section in 2026. The agent wave handed it one.
- Hygraph argued GraphQL’s third wave is an API of intent for AI — self-serving from a GraphQL vendor, and also not wrong. An agent that can ask for exactly the shape it needs wastes fewer tokens than one hitting six REST endpoints and discarding most of the payload.
- Hashnode shipped a GQL Agent Skill so coding agents can use its GraphQL API from Claude Code, Cursor, and Copilot.
- The Guild published how Buffer built a public GraphQL API on top of its internal schema — the public/internal boundary problem, which is the same one I spent the week writing about from the OpenAPI side.
- Bruno documented testing GraphQL APIs with queries, mutations, and assertions, and Solo.io covered GraphQL supergraphs via schema stitching in Gloo Gateway.
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.
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.
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 →
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.
See you next week.
