AI & MCP
We were wrong about the hard problem
Sagar Batchu
March 4, 2026 - 7 min read
We built a platform to help teams build MCP servers faster. Then we learned that building was already the easy part. The real obstacle to MCP in production — the one nobody was solving — was everything that comes after: auth, versioning, observability, governance. This is the story of how we updated our bet, and what Speakeasy MCP looks like on the other side.
Isn’t MCP dead?
Let’s first address the elephant in the X thread… If you follow the dev discourse on X and Hacker News, you’ve seen a popular narrative: MCP is over-engineered tech in search of a problem. CLIs are a superior form factor.
The criticisms of MCP have merit — tool definitions can bloat context windows, there’s no composability compared to CLIs, and you’re adding operational overhead to maintain running servers. For an individual developer piping together shell commands, MCP can genuinely feel like a step backward.
But that debate is mostly happening among hobbyists and solo devs. In enterprises, adoption of MCP has been rapid, and for good reasons. MCP solves a specific problem at scale: it gives users and AI agents a standardized way to discover and call tools across an organization’s services without bespoke integrations for each one.
When you have hundreds of internal APIs and you want agents to operate across them with consistent auth, permissions, and discoverability, MCP is the protocol that makes that tractable. It’s not competing with CLIs. It’s solving a different problem at a different layer.
For those teams, the question isn’t “should we use MCP?” It’s “how do we run it at scale in production?”
What we got wrong, and what we learned
We launched Gram with a clear conviction: the obstacle to MCP adoption was building servers to cover existing services. Scaffolding a server, and enumerating the tools would be slow, fragmented, and require too much manual plumbing. If we could collapse that to minutes, teams would ship.
That conviction wasn’t wrong — but the problem, it turned out, was already solved.
The reality is that a developer with Cursor and a free afternoon can have a working server deployed before dinner, then have it running on a Cloudflare worker before logging off for the night. The frameworks are good. Tooling is good. Sure, there are benefits to using a platform like Speakeasy to build: out-of-the-box code mode, versioning, one-click installs — but not enough to be compelling to thousands of companies when the alternative is already pretty easy.
So if building wasn’t the hard problem, what was? Months of design partner work gave us the answer. Teams kept coming in to talk about building, and within twenty minutes the conversation had shifted somewhere else entirely. Once a server was running in production and usage started spreading across teams, the real problems emerged:
Who is allowed to use which tools, and how do you enforce that? OAuth kept coming up. Not as a nice-to-have — as a blocker. Security reviews were stopping MCP deployments entirely. Teams were building MCP servers and then watching them sit unapproved for months while auth got sorted out.
What’s actually happening in production? Teams told us they were flying blind. They could see that tool calls were happening; they couldn’t see why calls were failing, which version of a server had handled a request, or whether the LLM was using their tools the way they’d intended.
How do you actually get a server into people’s hands? Building is one thing. Distribution is another. Teams were finishing servers and then hitting a wall: there was no clean way to roll them out across the company, provision them into the tools people were already using, or make them discoverable to other teams. You can’t just send a Slack message with a URL and call it distribution.
Three signals that crystallized the shift
Auth and observability are blocking production usage
Not a single customer segment was exempt from this. Startups, mid-market, enterprise — everyone identified the same two gaps: they needed RBAC and scoped access controls before they could deploy anything meaningful, and they needed enough observability to understand what was happening once they did. These weren’t items on a wishlist. They were deployment blockers.
Enterprises want governance across all their MCP servers
Multiple enterprise prospects said a version of the same thing: they didn’t just need a platform to build new servers. They needed visibility into their entire MCP footprint — including servers built on other tools, servers their vendors were running, servers deployed by other teams within the same org. The product they were describing wasn’t a build tool with governance on top. It was a control plane.
Distribution is the gap nobody is talking about
Teams could build a server in a day. Getting it distributed across the company took weeks — if it happened at all. There was no standard path to package a server, roll it out to the right people, or provision it as a plugin in tools like Claude. Every team was reinventing this from scratch. The ones who figured it out had adoption. The ones who didn’t had a server sitting in a repo that nobody used.
What this means for what we’re building
The original bet was: teams need help building MCP servers fast.
The updated bet: the hardest part of MCP in production isn’t building servers — it’s managing them.
Building is still the entry point. But it’s table stakes, not a moat. Governance is the moat — both the product moat and, for engineering teams, the actual blocker standing between “we have an MCP server” and “we have MCP in production.”
Speakeasy MCP is our answer to both sides of that problem. A platform where you build MCP servers and govern them — in the same place, with production infrastructure included from the start. Not a framework you deploy yourself. Not a gateway you bolt on after the fact. A foundation.
The three pillars are Build, Secure, and Observe. They’re not aspirational. They map directly to what customers told us was missing:
Build solves the creation layer we originally focused on — fast path from idea to deployed server, with full control over business logic and data. Catalog for common SaaS integrations. But more importantly, distribution: one-click rollout across your org, pre-provisioned Claude plugins, and a path from “server exists” to “people are actually using it.”
Secure addresses the number one blocker teams described. OAuth 2.1 with Dynamic Client Registration and PKCE, RBAC for both producers and consumers, scoped permissions per server and per tool. It’s not a configuration step — it’s active from the first deploy. This is just how the platform works.
Observe gives teams the visibility they told us they were missing. Real-time telemetry across hosted and proxied servers. Version-aware analytics that correlate performance with server versions. Actionable failure insights — not just dashboards that tell you something broke, but context that helps you understand why and fix it.
What’s next
Speakeasy MCP already handles the governance, distribution, and observability that enterprises need to run MCP at scale. Auth, pre-provisioned Claude plugins, org-wide visibility — these aren’t on the roadmap. They’re in the product. The next layer is the proxy: a single control plane for your entire MCP estate, including servers we didn’t build.
We’re not building the fastest way to create a server. We’re building the platform that makes enterprise MCP usage actually work.
If you’re at that inflection point — you have MCP servers and you’re realizing that the build problem is solved but the production problem isn’t — we’d like to talk .
Speakeasy MCP is the platform for building, securing, and observing AI agent tools — with production governance included from the start. speakeasy.com/mcp