API Evangelist Weekly — MCP Grows an Economy: AWS Adds OAuth, Virtual MCP Manages the Bill, and Governance Moves to the Consumer

← All newsletters

The MCP drum is still beating, but the sound changed this week. For the last year the headline was always arrival — another provider shipped a server, another platform showed up. This week the headline was operations: what it costs to run these things, how you authorize them, how you design their tools so they don’t waste tokens, and what happens at 2am when the auth handshake fails. That is the sound of a technology settling into the plumbing. And it lines up almost too neatly with what I spent my own week writing about — governance moving off the builder’s desk and onto the consumer’s — because those are the two halves of the same maturation.

6,215 posts went out in the last seven days across the 3,656 API-bearing providers I track, and 4,371 of them carried an API-related signal in the title. I’m going to do something a little different this week: alongside what the network published, I’m going to weave in what I actually posted on API Evangelist, because for once the feeds and my own notebook were arguing the exact same point from opposite ends.

Let me walk through what I saw.

A great neon toll-gate structure straddling a light-causeway, agent-forms pausing to present glowing credential-keys before passing — authorization becoming the load-bearing gate on the MCP grid.

AWS Puts OAuth on the MCP Server, and the Network Reprints It

The single most-repeated story of the week was AWS adding OAuth support to its MCP Server — it landed in my pull across more than fifteen provider repos at once, which is how you know a launch touched a nerve.

AWS announced OAuth support for the AWS MCP Server in its what’s-new feed, and walked through it in depth on the security blog — the highest-traffic surface AWS has, telling everyone to stop bolting static credentials onto their agents.
Contrast Security introduced its own Contrast-hosted MCP server — a security vendor putting its runtime data behind a hosted, authenticated MCP endpoint rather than a DIY one.
The Claude status page logged “Issues authorizing to MCP Servers” — an actual incident about the auth path, which is the least glamorous and most telling artifact of all. You don’t get incident reports for things nobody depends on.

This is the direct continuation of the thread I flagged two weeks ago — the 8.5%-of-MCP-servers-use-OAuth number. AWS shipping OAuth as a first-class feature of its own server, and the platforms throwing auth errors under load, is the 91.5% starting to get closed one provider at a time. Authorization stopped being the asterisk on MCP and became the headline.

A luminous ledger-monolith at the center of the grid, light-conduits flowing in and metered streams of energy flowing out through glowing counters — MCP as a metered economy with a real cost of running it.

MCP Grows an Economy — Cost, Tool Design, and the Operational Bill

Once you’re running a fleet of these servers, the questions stop being “does it work” and start being “what does it cost and how do I design it well.” That genre showed up in force this week.

Solo.io argued for the role of Virtual MCP in managing LLM costs — framing an MCP gateway not as plumbing but as a cost-control layer, because every tool you expose to an agent is tokens you pay for.
AWS published “MCP tool design: Practical approaches and tradeoffs” — the design-discipline post, admitting out loud that how you shape your tools determines whether the agent is efficient or expensive.
Arcade described building 10 MCP servers in a weekend with agents — the supply side industrializing, agents building the servers other agents will consume.
SnapLogic made the case for an iPaaS with native MCP support — the integration platforms absorbing MCP as a standard feature rather than a bolt-on.
ibanforge’s “Running an MCP server in production: what actually breaks” kept circulating from the week prior — the honest field report that started this whole operations turn.

Here’s the throughline: MCP now has an economy. It has a supply chain (agents building servers), a cost model (tokens per exposed tool), a design discipline (tradeoffs, not just wrappers), and an ops reality (incidents, gateways, what-breaks posts). Providers who treat their MCP server like a product with a P&L are pulling away from the ones who treat it like a checkbox.

Dozens of small glowing product-monoliths across the grid, each sprouting an identical angular MCP antenna that pulses in sync — every product growing the same new interface at once.

Every Product Grows an MCP Surface

Underneath the economics, the long tail kept doing what it does — every category of product sprouting an MCP interface over the capabilities it already had.

Hedera shipped Hedera MCP & Agent Skills — a distributed ledger handing agents both the call surface and the how-to-use-it packaging in one post.
Aiven put Apache Kafka behind an MCP server and followed with the Aiven MCP in practice, dev environment to deploy — data infrastructure becoming conversationally operable.
Geoapify launched an MCP server for geocoding and maps, SigNoz used its MCP for log and trace investigation, and Zoho introduced an Inventory MCP for operations that work through conversation — maps, observability, and ERP, all the same week.
The PyPI firehose confirms the pattern from the package side: spec2openapi turning specs into OpenAPI, and a steady drip of narrow servers like stratum-mcp and itu-mcp — the tail assembling itself one pip install at a time.

My read hasn’t changed, but the evidence keeps thickening: MCP is becoming the default second interface on every product, the way an SDK or a webhook did before it. The interesting question is no longer whether you have one — it’s whether yours is governed, authorized, and affordable, which is exactly where my own week went.

A figure at the consuming edge of the grid holding up a small glowing lens to inspect an incoming light-causeway before connecting — governance as a tool in the consumer's hand, not just the producer's.

From My Desk: Governing APIs for the Consumer

While the network spent the week putting auth and cost controls around MCP, I spent mine arguing the same point from the governance side — that we built API governance for the people producing APIs, and now we have to build it for the people consuming them. This was the busiest writing week I’ve had in a while, and it hangs together as one argument.

I opened with the thesis: we governed APIs for the builders — now govern them for the consumers, then spent the week building the tooling for consumer API governance to back it up.
I shipped browser-first tools you can run without a pipeline: a governance validator for your API specs, a registry for the API artifacts you depend on, and a way of turning Spectral output into a report people actually read.
I said the quiet part out loud twice: most teams just turned Spectral on and stopped there, and API governance is 75% people work — the rules are the easy 25%.
And I connected it to the agent wave the rest of this newsletter is about: put governance where the agent can reach it, plus scoring the reusability of your API estate, standalone API documentation generated from APIs.json, and API reviews and provenance as accountability over enforcement.

The network was closing the auth gap and metering the token bill; I was arguing that governance itself has to move to the consumer — because the person integrating your API (or the agent doing it on their behalf) needs to check your contract against their expectations, in the browser, without asking permission. IBM API Connect governing the whole lifecycle with Spectral is the producer end of the same tool; the consumer end is what I’ve been building. Same Spectral, both directions.

One central glowing master-spec monolith projecting several differently-tinted light-copies outward to distinct audience-platforms across the grid — a single canonical contract overlaid into many consumer-shaped views.

Overlays and Agent Skills — One Spec, Many Consumers

The overlay pattern is the mechanical version of that same consumer argument, and it got a real workout this week — from me and from the tooling vendors.

I wrote up OpenAPI Overlays twice: for filtering one spec into public, partner, and internal audiences, and for translating and localizing one canonical spec — one source of truth, reshaped per consumer without forking it.
Redocly shipped @redocly/openapi-docs 3.23.0 and @redocly/asyncapi-docs 1.12.0 — the docs toolchain keeping pace on both the sync and async sides of the contract.
StackHawk published “An Eval Harness for Agent Skills: How We Change Behavior on Purpose” — the maturity signal for Agent Skills: not just shipping them, but testing that they change agent behavior the way you intended.
AsyncAPI held its 2026 Governance Board elections — governance as literal civic process inside a spec community, which I find quietly encouraging.

Overlays, eval harnesses, and governance boards are all the same instinct: one canonical thing, many audiences, kept honest by tooling and process rather than by copy-paste. Filtering a spec per audience is consumer governance — you’re deciding what each consumer is allowed to see and depend on, at the contract level.

Ancient weathered stone glyph-tablets at the grid's edge being traced by beams of neon light and re-emerging as clean glowing angular workflow-conduits — old standards rewritten as modern API workflows without erasing their origin.

Legacy Standards Keep Becoming API Workflows

The other thread running through my own week was older than any of this: dragging decades-old standards into the modern API age, especially in healthcare and EDI, where the workflows are the product.

I set the frame with bringing legacy standards into the modern API age, then walked provider by provider: Medplum and FHIR as a developer backend, DrChrono and the clinical day as workflows, and Ribbon Health and the provider directory workflow.
On the EDI side: Availity and the X12 administrative workflows and Stedi and EDI as modern API workflows — X12 and EDI, the standards everyone swears they’ll replace and never do, wrapped as clean modern APIs.

There’s a reason I keep coming back to healthcare and EDI: they’re the proof that “legacy” and “API-native” aren’t opposites. The workflow is the unit of value — the eligibility check, the clinical encounter, the provider lookup — and the modern job is to expose that workflow cleanly over an API (and soon, an MCP server) without pretending the underlying X12 or FHIR reality went away.

A monumental neon doorway on the grid sealed with a single oversized manual lever only a human hand can reach, while agent-forms queue outside unable to pull it — onboarding still gated behind a button an agent cannot press.

The Onboarding Bill Comes Due

I also ran my provider-review lens across the big management platforms this week, and the recurring finding was the same one I never stop harping on: onboarding is still where good APIs go to disappoint.

AWS API Gateway and the self-serve onboarding it refuses to offer — a platform that can provision the world, but won’t let a developer onboard themselves.
What programmatic onboarding looks like when the app is really a subscription inside Azure API Management, and what it looks like inside MuleSoft Anypoint — two very different answers to the same automation question.
And the one that stung to write: Postman sells API tooling but still makes you click Generate API Key — the company whose whole business is API workflows, still gating its own onboarding behind a manual button.

The connective tissue back to the top of this newsletter is direct: an agent cannot click “Generate API Key.” Every manual onboarding step you leave in place is a wall between your API and the agent-driven consumption everyone’s racing to enable. You can ship the fanciest MCP server in the world, but if a human has to click a button to get the credential that feeds it, you’ve built a beautiful door with a lock only a person can open.

That’s the week. MCP grew an economy — auth, cost, tool design, incidents — while I spent seven days arguing the mirror image: that governance and onboarding have to move to the consumer, and building the browser-first tooling to make that real. Next week I’ll be watching whether the OAuth-on-MCP momentum turns into an actual pattern providers copy, or stays an AWS-shaped one-off.

If you want this analysis applied to your own API operations, that’s what I do.