I am finding the rhythm to the blog roundup for this newsletter each week. I can tell there is a lot of AI generated blog posts, but I still consider these as valid signals. I'm not reading everything, and I am using AI to sort through the noise to find the signal. I suspect I will continue to get better at this balance, but I also anticipate more noise down the road that will force me to fine tune my approach.
Regardless, this week's signal is wider and cleaner than it has been in a while. There were 4,155 posts across the network in the last seven days, 3,162 of them carrying some kind of API-related title signal. When I sift through them, the story is not really directly about APIs at all anymore. It is about the layer the agents are reaching the APIs through, who gets to own that layer, and what we are calling the new artifacts as they show up. I want to walk the integration, MCP, and skills beat this week, because that is where almost all of the movement is. But really, this is all about APIs and integration.
Everyone Is an MCP Gateway Now
I am borrowing that header straight from Tyk, who published Everyone's an MCP gateway now this week, and followed it with AI agents need API gateways. The thing that struck me reading across the network is that MCP has crossed over from announcement to general availability infrastructure. Google Cloud shipped the fully-managed Remote MCP Server for AlloyDB as Generally Available. AWS added VPC connectivity for MCP connections in Amazon Quick. Salesforce introduced the Data 360 MCP Server. Matomo made Matomo MCP available, Zoho shipped Zoho MCP where payments meet conversations, Assembled put out the Assembled MCP, and Aha! introduced the Aha! software MCP server. Kevel framed their version as a journey in AI at Kevel: From APIs to Agents, and Temporal told a real operational story in how Coinbase debugs Workflows with MCP.
When everyone is a gateway, nobody is — which is exactly why the gateway and runtime vendors are circling the kill. Arcade published Build vs. Buy MCP Runtime: 2026 Decision Guide, and Jitterbit went straight at the category with How MCP Will Redefine iPaaS for the Agentic AI Era. The technology here feels useful. The politics are the part worth watching. MCP started as a way to let any model talk to any tool, and it is rapidly becoming the new place vendors plant a flag and try to own the control point — the gateway, the runtime, the registry. We have watched this movie before with the API gateway itself. The protocol stays open; the control point gets captured. I have learned to not be cynical about it, but I am paying attention to who is positioning to sit in the middle.
The Integration Vendors Saw This Coming
One interesting repositioning this week came from the integration and unified-API crowd, because they have the most to gain and the most to lose. Nango wrote How to build a Gmail API integration with Nango and Claude, which is a small, practical post that quietly redraws what "an integration" even is when an agent is the consumer. Zapier ran a cluster — How to build multi-agent systems with MCP, and two customer stories, how one operations builder rebuilt his Zapier workflow with Zapier MCP in a weekend and how NoPlex uses Zapier MCP and Claude inside Google Workspace. Cyclr published 10 Key Patterns for Calling Integration Workflows via MCP and, more tellingly, How to Sell MCP and AI to Skeptical SaaS Users — because the sales motion is the real tell about where a category thinks it is going.
And then there is Truto, who published more this week than most companies publish in a quarter (AI is truly magic) — a hands-on engineering guide for MCP examples, a SaaS API integration audit runbook covering retention, tokens, logging, and SLAs, how to publish a dedicated MCP integration reference for enterprises, and a guide to building MCP servers for AI agents, among others. You can argue about the volume, but the shape of it is clear — the integration layer is rebuilding its entire documentation and trust surface around MCP and agent consumption.
This is the producer-versus-consumer story I keep coming back to. For some time now the integration vendors optimized for a human developer wiring two SaaS apps together. The consumer changed. It is now an agent, and the agent does not read your marketing page or your getting-started tutorial — it reads your schema, your tool definitions, and your error messages. The vendors who understand that the consumer changed are rewriting their surface area for a reader that has no patience for smoke and mirrors. The ones who do not are about to find out their beautifully designed developer portal is invisible to the only consumer that is growing.
Skills Are Quietly Becoming a First-Class Artifact
The word I am watching most thoughtfully is "skills," because it is starting to show up right next to MCP as if it were a settled, co-equal building block — and I do not feel it is settled yet. Confluent shipped their MCP Server and Agent Skills as GA in a single launch. Anyscale published two — Reimagining ML Operations with Agent Skills: a new maturity model for on-call and the Anyscale Agent Skill for LLM Post-Training. And Document360 put its finger on exactly the tension in MCP Servers vs. Skills: Why Technical Documentation Needs Both. It is worth remembering that Twilio set this pattern a few weeks back when they bundled their MCP Server and Skills together for 1,800+ APIs.
I want to slow down here, because we are naming a thing while it is still forming. An MCP server is a connection — it gives an agent the ability to call your tools. A skill is closer to packaged know-how — the procedure, the context, the guardrails for doing a particular job well with those tools. The two are related but they are not the same, and the fact that vendors keep shipping them in the same breath tells me the industry has not drawn the line yet. That is fine. That is how this always goes. But I have a deep wariness, earned over a decade of watching specifications, about the moment a useful idea gets a name before it gets a shared definition. If "skill" comes to mean fifteen different things across fifteen vendors, we will spend the next five years untangling it, the same way we spent years untangling what people meant when they said "API."
The Layer Underneath Is Still Identity and Governance
I flagged agent identity as the quiet next layer a few weeks ago, and it has not gotten quieter. WorkOS ran a whole series out of MCP Night 4 — a recap on agent auth, auth.md, and the rise of agentic registration, AgentMail framing email as an identity layer for agents, and AgentCard, one-time cards for agent payments. Microsoft announced the Agent Governance Toolkit MCP Extensions for .NET. Acronis wrote about governing apps, agents, and MCP servers through central policy. And Tigera made the sharpest argument of the week in The AI Agent Accountability Gap: Why Network Policies, API Gateways, And RBAC Are Not Enough.
Every MCP server that went GA this week just handed some agent the ability to act inside a system that was designed for humans holding human credentials. The governance work is the bill that comes due for all of that convenience, and it is coming due faster than the convenience is being celebrated. I keep saying governance is guidance, not gatekeeping, and I mean it — but guidance requires that you can answer a simple question, which is whose credentials that agent is holding and on whose behalf it is acting. "auth.md" and agentic registration are early, scrappy attempts to give that question a machine-readable answer. The vendors publishing useful work on the identity and policy layer right now are doing the unglamorous part that determines whether any of the MCP gold rush above survives contact with an auditor.
From API to MCP (It Is All API), and the Discovery Problem Nobody Has Solved
The part of this beat I care about most personally is the generation pipeline — the work of turning the API you already have into the MCP surface an agent can consume. Stainless published both Generate MCP Servers from OpenAPI Specs and API to MCP: a step-by-step guide for developers. The apilayer crew wrote How to Turn Any REST API Into an MCP Server for Claude, liblab covered How MCP Servers Simplify API Integration for AI, and WunderGraph did the most schema-grounded thing of the bunch with Per-Tool OAuth Scopes for MCP, Derived from Your Schema. This is the right instinct — your MCP surface should be derived from your contract, not hand-bolted on as an afterthought, because the afterthought version is how we get the next ten years of fragmented agent tooling.
But generation is the easy half. The hard half is discovery, and almost nobody is working on it. We are about to have tens of thousands of MCP servers, and there is no real registry, no apis.json-style index, no shared way for an agent to find the right capability surface for the job it is doing. I wrote a small piece this month cataloging every API provider in my network that ships an MCP server, grouped by tag, and even that modest exercise made the gap obvious. You cannot reuse what you cannot discover, and you cannot govern what you cannot reuse. The whole industry is busy generating MCP servers this week. The thing that is going to matter next is finding them.
What I Am Watching Going Into Next Week
The MCP launch wave is going to keep cresting — there is no sign of it slowing, and I will keep cataloging it. But the two threads I am going to be reading most closely are the ones underneath the launches. The first is the word "skills," and whether the industry draws a clean line between a connection and packaged know-how before the term gets diluted into meaninglessness. The second is discovery — whether anyone steps up to build the registry and the index that an agent population this size is going to need, or whether we let the gateway vendors quietly become the directory by default. Both of those are governance questions wearing a technical costume, and both of them get decided in the next few quarters.
The question I will sit with this week is the one I keep handing people — when an agent calls your newly shipped MCP server, can you say, in a way a machine could verify, who it is and what it is allowed to do? If the answer is still "whoever is logged in," you have built a very fast road to a place you did not mean to go. I am still working this out myself, in public, the same as always, and I will keep reporting on what I am seeing across the network. I'm going to do some deep dive research into what people are calling MCP and skills governance, do a diff with what we know as API governance, and publish some stories around what the reality on the ground looks like.
"It is not the strongest of the species that survives, nor the most intelligent. It is the one most adaptable to change." — often attributed to Darwin, almost certainly not his words, which is its own small lesson about provenance and the things we name.
