Week of September 20 – September 26, 2026
Everyone Rebuilt the Front Door, and Nobody Rebuilt the Org Chart
On Monday I published a post saying the gateway is a tired concept, because gateways are about power. I will own that the headline was link bait. It did its job, and the best replies in the thread said what I meant better than I did — enough that I wrote a follow-up on centralized decisions, distributed enforcement, and the org chart behind the gateway.
Then I spent the rest of the week watching the industry build gateways.
Not the old kind. Every one of them this week was a front door for agents — a single place an agent walks up to, authenticates through, and gets handed the tools it is allowed to use. Cloudflare, Kong, DigitalOcean, AWS, Databricks and, landing on Sunday, Google. Six vendors, one shape, one week.
I do not think that contradicts what I wrote. I think it proves it. The gateway keeps coming back because the organizational problem underneath it keeps coming back, and agents have made that problem urgent again: somebody has to decide which agent gets which credential, and the gateway is where that decision lands in the architecture diagram. The technology is new. The org chart is the same one we had in 2012.
Everyone Rebuilt the Front Door This Week
- Cloudflare took MCP server portals to general availability — one endpoint for your approved MCP servers, with Access logging every tool, prompt and resource call. Two days earlier they added private MCP server support, so the portal can reach servers that never touch the public internet. That is a gateway. It is just not called one.
- Kong introduced a Portal MCP Server for every developer portal, which I wrote up separately because it closes a gap I put on the record in June. The access model is the part to copy: an anonymous agent sees what an anonymous developer sees, and an authenticated agent inherits the permissions of the human it acts for. The same week, Kong Gateway 3.16 went from debugging to billing to compliance.
- DigitalOcean laid out the problems with agentic tooling and its Action Gateway answer, and their tutorial title is the whole pitch: connect your AI agents to SaaS tools without sharing your credentials. The gateway holds the GitHub, Jira and Postgres credentials so the agent never sees them.
- AWS showed how to build a multi-account agent with AgentCore Gateway and MCP — a central platform account runs the agent, and each line of business exposes its data as its own MCP server. Read that architecture next to Rob Meyer’s point in my follow-up, because it is exactly the org chart drawn as infrastructure. Databricks has the same pattern at another layer, with Unity Gateway governing clinical AI at a trillion-token scale and a CLI for deploying coding agents through it.
- The one I would read first landed a day after the window closed: Google Cloud API Gateway now turns your REST APIs into MCP tools, driven by an
x-google-api-management.mcpannotation in your existing OpenAPI. Your authentication, quotas and logging carry over to agent traffic. I wrote on Tuesday that Zuplo declares a whole MCP server inside its OpenAPI. That is two gateways in five days deciding that the OpenAPI is where the agent surface gets defined — each with its own vendor extension, spelled its own way.
So the gateway is back, and it is carrying the MCP server now. Of everything in this section, the question worth asking is not which one is best. It is who in your organization gets to toggle the switch that exposes a system to agents — because every one of these products puts that switch in exactly one place.
The Case Against MCP Is Quiet About Authorization
The best-titled post of the week belongs to WorkOS: delete the MCP servers and the agent is back to a long-lived key in a shell. Their argument is that the case against MCP — the one I have been partly making, and the one the cost numbers from last week support — is right about ergonomics and quiet about authorization. Take the protocol away and you have not removed the agent’s access. You have just removed the part that was scoping it.
That is a fair hit, and the rest of the week backed it up.
- WorkOS again, with four ways MCP authorization breaks in production — the 2026-07-28 specification says what to do, and these are the code shapes that ignore it — and four agent credential architectures compared across Google, NVIDIA, Rubrik, Microsoft and Opal, including the gap they all share.
- The attack side was busy. Mitiga walked through an MCP token-theft attack chain in Claude Code that sidesteps SSO and MFA. GitGuardian mapped where coding agents leave credentials — config files, logs, shell history — that repository and CI scanners never look at. Imperva found remote code execution in Microsoft DevLabs’ DebugMCP.
- And the builders answered. Zalando open-sourced its Agentic Identity Broker for user-to-agent delegation, consent and token exchange, so agents act on behalf of users without ever holding the provider tokens. Netflix wrote up trading a cloud identity for your own with workload attestation. Solo asked whether SPIFFE can work for agents. Lumos launched MCP Governance to enforce policy at runtime.
- Cequence followed last week’s argument with Agent Trust, managing agents on identity plus behavior, opening with a breach caused by an agent acting entirely within its authenticated permissions. That is the sentence that should worry you. The credential was fine. The sequence was the problem.
- And the honest summary came from a conference hallway: FusionAuth’s notes from LDX3 NYC — nobody has a good answer for agentic identity yet.
Put this section next to the first one and you can see why the gateway is winning. DigitalOcean holds the credential so the agent does not. Zalando brokers the token so the agent does not. Kong binds the agent to the human’s permissions. They are all the same move — keep the secret out of the agent’s hands by putting something in the middle — and the thing in the middle is a gateway, whatever it says on the box.
📄 Publishing an API Portal — Kong just gave every developer portal an MCP server, and Cloudflare just gave every organization an MCP portal. The portal was always the human-readable front door to your API, and it now has a second audience that does not read. This paper walks through the three portal archetypes, the full anatomy of a portal generated from one source of truth, the anti-patterns, and the agentic turn, with a self-assessment you can run against your own. $25
The Bill, Week Two: Fifty-Eight Tools Became Two
Last week the agent conversation got settled by arithmetic. This week the arithmetic turned into shipped features.
- The most concrete post of the week: Arize replaced the 58 tools their assistant used to drive the Phoenix UI with two tools and a JavaScript sandbox that runs in your browser tab, and wrote up why, how, and what it cost. Fifty-eight to two is the Redocly argument made into a product decision.
- Datadog added Code Execution to its MCP server specifically to cut agent cost and improve accuracy with fewer tool calls and less model context. And Northflank compared code execution APIs for agents — Northflank, E2B, Modal, Vercel Sandbox, Blaxel. When a capability gets a buyer’s guide, it has become a category.
- The cost numbers kept coming: Alteryx says testing shows it cuts AI token costs by up to 95%, Kong on why AI spend gets out of control, Finout on allocating token costs across teams and products, and Flexera’s practical guide to FinOps for AI.
- On the protocol side, Quarkus says MCP went stateless and it already implements it, and Nexla made the case for task-specific MCP servers over connecting every system into one LLM. Both are about a smaller surface.
- The post I would hand to every provider is Apify’s: what the MCP server does to your Actor before an AI agent ever sees it. The author had a popular scraper with dozens of users that was completely unusable by an agent, and did not know until they checked. That is the description layer, and it is the cheapest fix in this whole issue.
I made the same argument about my own work this week in optimizing my AI spend with an open model, a commercial model, and deterministic scripts. When I sorted every step of my profiling pipeline into piles, most of what I had been paying a model to do was never judgement. It was arithmetic, done expensively and slightly differently every time.
MCP Held Its Share While Everything Else Got Quieter
Last week I corrected the MCP count for one company’s documentation sprint. This week I have to correct my own counting, so here it is, done the same way for both weeks.
Matching MCP in titles across the deduplicated third-party pool, I count 61 posts this week out of 6,061. Recomputed with the identical filter, last week was 96 out of 7,553 — or 73 once you take out Botify’s twenty-three help pages. So the raw count fell by about a sixth. But the whole pool fell by a fifth, and as a share MCP sat at roughly one post in a hundred both weeks. This week there was no single-company dump to subtract: the largest cluster was five AWS posts.
This was a quiet week for provider blogs overall, not a quiet week for MCP.
- The launches were real products, not experiments. Databricks took Genie One MCP to general availability. DeepL shipped into Microsoft Copilot, ChatGPT and Claude via MCP. Zyte launched Scrapy MCP to debug your crawl while it runs. Bynder connected its DAM. NETSCOUT built one into Omnis Streamer. LiteLLM introduced LiteAdmin MCP.
- Skills are now shipping alongside the servers. AWS End User Messaging and Amazon SES published agent skills for the AWS MCP Server. Appwrite’s Codex plugin bundles its hosted MCP server with thirteen agent skills. Vercel published a state of agent skills. I wrote that Skills over MCP is final, and now it needs servers — these are the first of them.
- The help-centre pattern from last week kept going — WISK published four setup pages in a day, and Elementor and Instrumentl documented theirs. And the “when to use which” genre matured: Mitiga on MCP vs API and why you need both, Retool on MCP vs CLI, and MuleSoft bridging Agentforce agents over A2A with Agent Fabric.
From My Desk: The Walls, the Cards, and the Contract
Across 6,061 third-party posts, OpenAPI was named in two titles — Buf on generating JSON Schema and OpenAPI from Protobuf and Fumadocs OpenAPI v12. That is up from one, and it is still nothing, in a week when two gateways decided the OpenAPI is where the agent surface lives.
- The walls. I ran the profiling pipeline hard against the backlog and tallied what actually stands between an agent and an API: the walls companies put up in front of agents. The honest part is that 59% of the time there is simply no API. The interesting part is the 17% that put a credential in front of any description at all — customer-only docs, “contact sales”, partner logins. Each one has the same effect on an agent as a 404. Read it next to Amazon opening Seller Central to agents and keeping the storefront closed and Amazon wanting agents to ask permission when there is no form to fill in.
- The agent cards. A2A adoption is 421 of 27,840, and most of them arrived with the card. 427 agent cards: how they talk and what they do. And the one with the sharpest number: 97 say x402, and eight answer a 402.
- The contract as the place for agent behavior. Constant Contact is putting prompt engineering in its OpenAPI. MoEngage decides who is allowed to see a tool. Secureframe is teaching agents a multi-step workflow. Algolia is the other half of the x-mcp-tool collision. Put the LLM on a JSON Schema leash, and give Markdown a vocabulary. And the thing I have been building toward: overlays that speak — conversational phrasing for every operation.
- Arazzo, three ways. Arazzo needs conformance testing — two runners should agree, and nobody has checked. Arazzo functions are still a proposal, and that is the point. The Arazzo GraphQL pull request is waiting for its first reviewer — if you have opinions about GraphQL workflows, that is a place to put them.
- Capabilities before strategy. Before you buy an agent strategy, map your capabilities, which grew out of balancing determinism against non-determinism, and build against buy, by doing the work to understand my own capabilities. And the one I enjoyed writing most: the “we are all in on agentic” shame game.
- Elsewhere: LLM SEO — how do you nudge an LLM?, the kids who have come up in the age of AI will approach things very differently, and APIs.io provides discovery-grade artifacts.
I want to end on the tension this week made visible. My walls post counts the companies that put a sales call in front of their documentation, and calls that a gateway with a human in it. Every product in the first section of this issue is a gateway with a policy engine in it. Both decide who gets in. The difference is that one of them can be read by a machine, audited, and changed with a pull request, and the other one is a calendar invite.
If you are going to put a door in front of your API — and the whole industry just told you that you are — make it the kind an agent can read.
See you next week.
🔌 APIs.io — 6,714 MCP servers, free to read, and now pay-per-call for the rest — This issue is about front doors, so here is ours, described honestly.
The catalog holds 6,714 MCP server profiles, and reading them is free — no key, no tier. Anything about one provider stays open.
curl "https://apis.io/api/v1/mcp?limit=50"
The security and scopes profiles — which auth schemes a provider declares, which OAuth scopes it defines — sit behind a paywall. Last week I told you the per-call Access plan was a preview. It is live now: $0.01 per call for single-provider synthesis, with a card, or paid with x402 in USDC with no account at all. Call https://apis.io/api/v1/security without a key and the 402 response tells an agent exactly how to pay for that one request, which is the kind of door I spent the last section of this issue asking for. Cross-catalog work — leaderboards, cohorts, the scored dataset — is Understanding, $199/mo.
