I've been slipping into the API design rabbit hole of MCP the last couple of weeks, as I work to refine the APIs.io MCP server, which is meant to index APIs, but also MCP servers (inception). MCP provides a new set of API design challenges and opportunities, just like GraphQL, and other patterns brought to the table. The news this week reflects the narrative I am investing in around API design in an MCP and AI client realm, alongside the expansion of API governance from a producer mindset to a consumer reality.
4,909 posts went out in the last seven days across the 2,607 API-bearing providers that I track on, and 3,478 of them carried an API-related signal in the title. Last week the headline was that MCP grew a control plane. This week the story moved one layer back, to the factory floor: the pipeline that produces MCP servers continue to be industrialized, and a sibling artifact called "Agent Skills" showed up next to MCP on everyone's release notes, and a single number from Microsoft — only 8.5% of deployed MCP servers use OAuth — quantified exactly how much corner-cutting the rush has bought us.
Let me walk through what I saw.
Only 8.5% of MCP Servers Use OAuth
If you read one statistic this week, read this one. The security debt the MCP gold rush has been quietly accruing finally got a number on it.
Microsoft published "Only 8.5% of MCP Servers Use OAuth — Here's How to Host One Securely on App Service." Ninety-one and a half percent of the MCP servers in the wild are running without a solid authorization story. That is the whole "MCP is just an API" argument in one data point — we spent fifteen years learning to put OAuth in front of APIs, and we're re-shipping the same servers in agent clothing with the auth ripped back out.
TrueFoundry published "Claude Code Security Best Practices for Enterprise Teams: SSO, AI Gateways, and MCP Governance" — the enterprise hardening checklist for the most popular agentic coding tool, and notably it puts SSO and MCP governance in the same breath.
Reform shipped "7 Tips for Storing OAuth Tokens Securely" — the unglamorous, load-bearing version of the same problem, aimed at the people actually holding the tokens.
Arcade's "Multi-User AI Agent Auth: OAuth & MCP Guide" kept circulating — the per-user authorization model that the 8.5% number says almost nobody has implemented yet.
The pattern is the one thing I will keep hammering: MCP is an API, and the auth question never went anywhere. The difference this week is that we finally have a measurement of how badly the industry is doing on it. If you ship an MCP server this quarter and it has real OAuth in front of it, you are already in the top tenth of the field. That is a low bar and an enormous opportunity.
Agent Skills Becoming a First-Class Artifact
For months "MCP server" was the only new thing on anyone's release notes. This week a second artifact showed up beside it, over and over, from serious vendors: the Agent Skill. It is becoming a packaging pattern in its own right.
Amazon MSK now offers AI Agent Skills to help developers operate MSK and accelerate migrations — and it landed across more than fifteen of the AWS repos I track at once, which is AWS's way of telling you something is now a platform primitive, not just an experiment.
Red Hat published "Empower your AI tools with new agent skills for Red Hat Enterprise Linux" — agent skills for the operating system itself.
Spree Commerce 5.5 shipped an "Admin API, AI Agent Skills, and Sales Channels" — a commerce platform listing Agent Skills as a headline feature right next to its API.
Confluent shipped its MCP Server and Agent Skills GA together, and RisingWave bundled "CLI, Agent Skills, and MCP" as one developer-tools release. The two artifacts are now shipping as a set.
Nango wrote "3 best API integration skills for Claude and Codex in 2026" — the skills-as-content genre arriving right on schedule behind the skills-as-product wave.
Here is what I think is happening: MCP answers "how does an agent call my API," and Agent Skills answer "how does an agent know how to use my product." They are complementary, and the providers who get it are shipping both. I expect Agent Skills to go through the exact same lifecycle MCP just did — first a feature, then a registry, then governance, then a security incident. We are at the "first a feature" stage. Watch this one.
The OpenAPI-to-MCP Pipeline Industrialized
The "your MCP server is generated from your OpenAPI" thread I have been tuned into all year stopped being an argument this week and started being standardized tooling — and the conversation has already moved past whether to generate it to how to govern what you generate.
Permit.io published "OpenAPI-to-MCP Turns Every API Into an Agent Tool. The Missing Piece Is Endpoint-Level Policy." This is the sharpest framing of the week: yes, you can mint an MCP tool from every endpoint automatically — and the moment you do, you need per-endpoint authorization, because "expose the whole API to the agent" is not a security model.
apilayer published "MCP vs. SDK vs. REST: Three Ways to Give Your AI App Data", reframing the same API surface as three generated delivery channels — which is exactly right.
GitBook shipped two posts on auto-generating API docs from an OpenAPI spec with AI — the docs corner of the same contract-driven pipeline.
Microsoft shipped a run of MCP build tooling: the Azure Functions MCP Extension updates from Build 2026, a "Fluent API for MCP Apps," and an MCP Test Console plus Git sync in Azure API Center. MCP is getting a real toolchain — build, test, version, register.
This is the thread with the least hype and the most leverage, and I will keep saying it: if your OpenAPI is good, your docs, your SDKs, and now your MCP server and its policies are mostly downstream of it. The contract is becoming the source of truth for four artifacts at once. Permit.io's point is the important refinement this week — generating the tools is the easy 80%; the endpoint-level policy is the 20% that decides whether the result is safe to turn on. This is the pipeline I argued for in Publishing a Public MCP Server, and it is good to watch it harden.
The MCP Server Became a Throwaway Package
While the enterprises industrialized the pipeline, the long tail did something interesting: it started publishing MCP servers like npm packages. My PyPI feed this week was a wall of one-off MCP modules. Think of MCP (APIs) as just an ephemeral interface now.
A single day surfaced carrot-mcp-serial, ccw-mcp, mcp-stargazing, fw-context-mcp, logodev-mcp, and carrot-mcp-nfc — and that is a fraction of them.
The vendor version of the same instinct: liblab on "How MCP Servers Simplify API Integration for AI," Kevel introducing its MCP server, and Google's Pay & Wallet Developer MCP server.
This is the commodity phase. An MCP server is now small enough and generated enough that anyone can publish one in an afternoon, and a lot of people did. It is healthy — this is how a protocol becomes infrastructure — but it is also exactly where the 8.5%-no-OAuth number comes from. The same low cost of publishing that makes the ecosystem vibrant makes it trivial to ship something insecure and unmaintained. The registry-and-governance machinery from last week exists precisely to deal with this week's flood. The two stories are the same story.
The Fundamentals Are Quietly Booming
For all the MCP gravity, the single most prolific genre this week was the plain old "API vs. the-other-thing" explainer — and it is booming for a reason. Everyone wiring up agents is suddenly re-learning where the boundaries are.
SigNoz published "OpenTelemetry API vs SDK," Sportmonks ran a clinic — "SDK vs API Wrapper," "REST vs GraphQL vs WebSockets," a JWT primer, and OAuth 2.0 in Sports APIs — and Wowza wrote "Video API vs Video SDK."
The operational fundamentals shipped too: Site24x7's "15 REST API monitoring rules every engineering team should follow," Nango's roundup of two-way data sync tools, and LambdaTest's "49+ Most Common REST API Interview Questions."
And the boring-but-real product work kept coming — Cashfree on what a payment gateway API actually is, Vantage moving its Temporal integration onto the Cloud Billing API, and AWS's "Build a Spring Boot REST API with Amazon Aurora DSQL."
This is the week's quiet argument and it is the one I trust most: the API/SDK/REST/OAuth/JWT fundamentals did not get less important because agents arrived — they got more important, because the agent is just one more demanding consumer of the same surface. The providers writing clear "here is the difference between an API and an SDK" explainers are doing more to prepare for the agent era than most of the MCP listicles are. If you cannot explain your surface to a junior developer, you cannot explain it to a model either.
A Few Other Threads Worth Noting
Higress shipped v2.2.3 with stronger AI Gateway capabilities and Gateway API inference extensions, and Solo.io detailed building an MCP Gateway on Apigee — the gateway layer kept absorbing MCP, right on the trajectory from last week.
Truto continued its run of MCP-engineering content — connecting an Auth API to Claude, Docs-MCP to stop hallucinated integrations, and hands-on transform-code guides. One vendor is quietly writing the MCP SDLC textbook a chapter a week.
Eden AI benchmarked Mistral OCR 4 against the top document-parsing APIs — the "API aggregator benchmarks the underlying APIs" pattern that is its own useful corner of the network.
And Qlik shipped a new REST API to retrieve Discovery Agent insight cards — a reminder that "agent" increasingly means a thing your REST API serves, not just a thing that calls it.
What I Am Watching Going Into Next Week…
Whether anyone moves the 8.5% number. Microsoft put a stake in the ground: the overwhelming majority of MCP servers have no real auth. The interesting question is whether the registry and gateway vendors start measuring and reporting it — an "OAuth coverage" badge in a registry, a gateway that refuses to proxy an unauthenticated MCP server, a security vendor publishing the number by ecosystem. Measurement is how this debt gets paid down. I am watching for the second data point.
Whether Agent Skills follow MCP's arc. Skills landed as a feature this week across AWS, Red Hat, Confluent, Spree, and RisingWave. If the pattern holds, the next moves are a skills registry, then skills governance, then the first "malicious agent skill" disclosure. I expect the registry conversation to start within a month or two, and I will be watching whether it converges with MCP's or forks into its own incompatible thing.
Whether endpoint-level policy becomes table stakes. Permit.io named the gap precisely: auto-generating MCP tools from OpenAPI without per-endpoint authorization is a footgun. If the OpenAPI-to-MCP generators (Stainless, Speakeasy, the cloud platforms) start emitting policy scaffolding alongside the tools — not just the tools — that is the pipeline maturing in the right direction. If they don't, the 8.5% number gets worse before it gets better.
This was the week the MCP factory floor came into focus — the assembly line, the commodity output, the product line, and the safety inspector showing up with a clipboard and a damning statistic. The fundamentals, as always, kept carrying the load underneath all of it, and the providers doing the unglamorous design and auth work are the ones who will be fine when the inspector gets to them.
I am fascinated with the relationship between MCP and Agent Skills. Equally interested in the relationship between class REST APIs and Agent Skills. I'm not convinced you need MCP in all situations, and that APIs can be more precise. I do think there is a pretty seismic shift happening in API design because of AI consumption via copilots and agents, but I think that many folks will also rediscover the benefits of a simple resourceful approach to integrating with the resources we need, and that request / response via HTTP is much more economical than streaming.
"It's funny how the nature of an object—let's say a strawberry or a pair of socks—is so changed by the way it has come into your hands, as a gift or as a commodity." - Robin Kimmerer
