MCP Six Months After GA: What's Actually Working in Production

Shannon Lowder

18 Mar 2026 — 2 min read

A dense panel of blue network patch cables — one server, many clients connected — Photo: “Switch!” by andrewfhart, licensed under CC BY-SA 2.0.

Model Context Protocol went GA at Microsoft Build in May. Six months in, I have enough production experience with it to give you a more honest take than the launch-day excitement warranted.

The short version: MCP is the right abstraction and the ecosystem is growing fast, but there are friction points in the production deployment story that nobody talks about at conferences.

What's Working Well

Tool portability is exactly as advertised. An MCP server I wrote to expose Unity Catalog table metadata works with Claude.ai, LangGraph, Copilot Studio, and the OpenAI Agents SDK without any modification. Write the server once, connect it to any client. That's a genuine win for teams that don't want to maintain multiple tool integration implementations.

One MCP server connecting unchanged to Claude.ai, LangGraph, Copilot Studio and the OpenAI Agents SDK — Write the tool server once; every MCP client connects to it unchanged — the portability win that holds up in production.

The inspector tooling for debugging MCP servers is solid. You can run an MCP server locally, point the MCP inspector at it, and interactively test tool calls without a full agent workflow. That's a much faster development loop than "spin up an agent, run it, check the logs."

The Friction Points

Authentication is underspecified in the current protocol. Each MCP client implements auth differently, which means your server needs to handle the lowest common denominator or maintain client-specific auth logic. For internal tools where everything is in the same network this is fine; for external-facing MCP servers it's a real problem.

Error handling semantics are inconsistent across clients. When a tool call fails, different clients treat the error differently — some retry, some surface to the model, some raise an exception. Design your error responses defensively.

The production deployment story (running an MCP server in a container, managing lifecycle, handling restarts) is still mostly DIY. The ecosystem around this is immature compared to typical API service deployment. Worth it for the portability; just go in with realistic expectations about the ops overhead. I'm here to help work through the implementation.

The Context Problem Neither Agent Mesh Nor OpenSharing Solves

I wrote recently about Azure Agent Mesh and OpenSharing — two infrastructure layers that between them cover how enterprises register, discover, share, and execute agents. Between them, they address a lot of the plumbing that has been missing from the enterprise agent stack. But there's a gap neither of

Unity AI Gateway and What a Governed Model Access Layer Actually Buys You

Unity AI Gateway, announced at DAIS this week, is the feature I've been waiting for since Agent Bricks shipped last year. It's a centralized governance layer for model access in Databricks — you configure which models are approved for use in your environment, who can call them,

You Don't Need Fable. You Need a Router.

The performance gap between open-weight models and closed frontier models has spent the last year collapsing faster than anyone predicted. Epoch AI's tracking puts open weights at roughly a three-to-four-month lag behind state-of-the-art closed models on average. For coding tasks, the gap has effectively closed — DeepSeek V3.2

DAIS 2026: Genie One and the Context Problem Databricks Is Solving

The central message from DAIS this week, delivered by Ali Ghodsi in the opening keynote, was direct: AI doesn't have an intelligence problem, it has a context problem. If your CFO can't get an AI system to explain why margins changed, that's not a