MCP Cloud Validated the Category. Your Agent's Tool Layer Is the New Lock-In.

Manufact, fresh out of YC's latest batch, just shipped MCP Cloud. On its own that's a footnote. But pair it with the beta SDKs that dropped for the July 2026 MCP release and it means something else: MCP infrastructure has graduated from protocol experiment to actual category.

The broker is the new critical dependency

The non-obvious part isn't which model wins or which orchestrator catches on. The thing quietly accumulating switching costs in your agent stack is the MCP broker, the layer mediating every tool call your agents make.

Every database query, every API hit, every filesystem read your agent does passes through here. Permissions, schemas, connector definitions, all of it lives there. The spec is still beta, so it will change. Every integration you've built needs migration when it does. Run through a hosted broker and you're on their timeline. They deprecate a feature, your agents lose a capability. They change pricing, your unit economics shift overnight.

This is the new lock-in surface. Swapping models gets easier every month. Rewriting an orchestrator is your code, your problem. But the MCP broker is where all your tool integrations pile up, and that's where switching costs compound. Moving between brokers means re-establishing every connector, every permission boundary, every data path your agents rely on.

Why self-hosting isn't just about compliance

For Nordic and European companies the data sovereignty argument is straightforward. Tool-call metadata carries query payloads, schema information, access patterns. You can't route that through a US-hosted broker if your data residency requirements mean anything. That alone makes self-hosted MCP brokers a hard requirement for much of the work we do at Kerber AI.

But the operational argument cuts sharper than compliance. A self-hosted broker means you control when spec migrations happen. You pick which beta features to adopt. You control the blast radius when a connector breaks. You're not waiting on a vendor to patch a spec change that broke your production agents at 2 AM.

The beta SDKs landing now make this concrete. There will be breaking changes. There will be deprecations. The question isn't whether your MCP integrations will need migration. It's whether you'll do it on your schedule or someone else's.

What to actually do

If you're building agent systems with more than a handful of tool integrations, run your own MCP broker. Treat it like your API gateway or your database: infrastructure you own, not a SaaS feature you rent. Hosted options are fine for prototyping, or for teams that haven't yet felt the pain of a forced migration. They're dangerous for production agents touching your core business data.

Three moves before the July 28 release candidate lands:

• Audit now. Run every MCP integration against the beta SDKs — some will rely on behavior the spec team dropped, and finding out in August is the expensive way.
• Broker, not point-to-point. Route tool access through one broker so auth, rate limits and audit logging live in one place.
• Pin after the RC. Once the spec settles, pin SDK versions and upgrade deliberately. The era of chasing HEAD is ending.

The MCP Cloud launch is good news for the ecosystem. The protocol has momentum, tooling will mature, the integration surface will standardize. Treat it the way you treated the first hosted Kubernetes platforms: great for getting started, not where production workloads should live long-term.

At Kerber AI we're already building self-hosted MCP broker infrastructure for ventures and client projects that need full control over their agent tool layer. The pattern is consistent across companies: they want the flexibility of MCP without handing the nervous system of their agent stack to a third party. That's not paranoia. That's architecture.