MCP in Production · Chapter 12
An early MCP server I shipped to production logged a stack trace I didn't recognize, on a host I'd never heard of, talking to a tool I'd renamed three weeks earlier. The user was in Sydney. The model was deciding, in real time, whether to retry. I was asleep.
That's the version of the protocol we have now -- one that works in production, talks to real users through real clients, and behaves well enough that the failures look like ordinary distributed-systems failures rather than "MCP is broken." Eleven chapters ago, I told you that was the goal. We're here.
This chapter is about what's next: where the protocol is going, what's still moving under your feet, and how to keep your skills sharp as the surface evolves. It's also the chapter where I get to be a little reflective. You earned it -- you read the other eleven.
The protocol is stable in the ways that matter and still moving in the ways that don't break you.
What's stable: the JSON-RPC envelope, the tools/list and tools/call shape, the resource and prompt primitives, the lifecycle handshake, and the two transports that have won -- stdio for local subprocess servers, streamable HTTP for remote ones. If you wrote a server against the spec eighteen months ago and you've been keeping up with minor revisions, your server still works. The breaking-change rate is low and the deprecation windows are generous.
What's still moving: auth (closing in on done), sampling and recursion (server-initiated model calls -- exists in the spec, uneven in the field), discovery at scale (no real answer yet), cross-server tool composition (no first-class concept), and streaming responses for long-running tools (works, but the patterns are still being figured out). I'll go through each of these in turn.
The cadence is roughly quarterly. The spec repo cuts a versioned revision every three to four months, almost always additive. Each revision lands new optional capabilities, clarifies an ambiguous edge case from the previous round, and occasionally formalizes something the SDKs have been doing in practice. The MCP working group has been disciplined about backwards compatibility -- when something has to break, it gets a deprecation flag for at least one revision before the old shape goes away, and the SDKs tend to handle the transition for you.
Practical implication: if you're shipping an MCP server in production right now, the right reading cadence is "skim the spec changelog when a new revision drops, deep-read only the sections that touch capabilities you actually use." You do not need to read every PR on the spec repo. You do need to know when auth lands, when streaming gets a normative pattern, and when discovery gets a real answer.
Five things are unfinished in mid-2026. I'll cover each, what the current state is, and what to expect.
This is the closest to done. The OAuth 2.1 capability is settling -- the discovery endpoints, the metadata document, the token exchange flows for both confidential and public clients have all stabilized in the last two revisions. The remaining work is mostly about the long tail: refresh token rotation patterns, dynamic client registration for ephemeral hosts, and the operational story for token scopes when a host wants per-tool permissions instead of per-server permissions.
If you're building a remote MCP server today, you should be implementing the OAuth 2.1 capability rather than rolling a custom bearer-token scheme. The protocol-blessed path is no longer hypothetical; it's what the major hosts expect. The custom-bearer approach still works for internal servers behind a VPN, but anything you'd put on the public internet should be on OAuth 2.1.
The thing that's not settled is the consent UX across hosts. Each client renders the OAuth consent screen differently, and the level of detail shown to the user varies wildly. A server author has very little control over what the user sees. This is going to take another year of host-side work to harmonize, and the right move as a server author is to write your scope strings as if a non-technical user is reading them out loud, because in some hosts they will be.
This is the unsolved one I think about most. There's no first-class concept of one MCP server composing tools from another MCP server. If you want a "search the docs, then file a ticket" workflow today, you write that orchestration in your application code, with the model doing the composition step by step.
There are workarounds. Some teams ship a "meta server" that connects out to other MCP servers as a client, exposes a flattened tool surface, and handles the composition internally. It works, and I've shipped a couple, but it's a pattern, not a primitive. The flattening loses information -- the user can no longer tell which underlying server a given tool belongs to, scopes get blurred, and observability becomes harder.
There are two camps on what the answer should be. Camp one wants a formal "linked server" capability where one server can declare a dependency on another and forward calls with provenance preserved. Camp two thinks the host should mediate -- if you have N servers connected, the host should let one server's tool result feed into another server's tool call, with the host enforcing the boundary.
I lean toward camp two. Server-to-server linking sounds clean until you think about auth scoping (whose token goes through?), error handling (which server's failure mode wins?), and the observability story (where do the logs land?). The host is already the authority on which servers are connected and which scopes they have; making the host the composition point keeps the model honest.
But neither approach has shipped. If you need composition today, do it in application code or in a meta server, and accept the pattern is going to change.
The current tools/list shape works fine for a host with one or two servers connected and a couple dozen tools total. It does not work when an enterprise host has fifty MCP servers connected, each exposing twenty tools, for a thousand-tool surface. The model can't reason over that many tool names in a single context, the host can't display them in a meaningful UI, and the tool descriptions blur together.
The problem isn't with the tools/list RPC itself -- the wire format is fine. The problem is that there's no notion of "tool relevance" or "tool category" or "tool availability for this task." Every tool is equally listed every time.
Several proposals are in flight:
database for this turn." Simple, but offloads the categorization decision to server authors who don't know what taxonomy the host wants.tools/list returning everything, it returns categories, and tools/list?category=foo returns the tools in that category. RPC-shaped, but has chicken-and-egg problems with cold context.My guess is the protocol lands on tool tagging plus some form of just-in-time discovery, with semantic retrieval staying as a host implementation detail. But I would not be surprised if it takes another four to six revisions to stabilize.
If you're a server author with more than ten or twelve tools, start thinking about how you'd expose categories now. The mental model of "my server is one flat list" is going to age.
Sampling is the capability that lets a server initiate a model call -- the server, mid-tool-execution, asks the host to run an LLM completion on its behalf. It's been in the spec for a while, but the support across hosts is uneven, and the patterns for using it well are still being figured out.
The use cases are real. A "summarize this document" tool wants to call the model. A "decide between these three approaches" tool wants the model's judgment without round-tripping through the calling agent. A long-running data-processing tool wants to ask the model to interpret an intermediate result.
The unresolved questions are:
If you're thinking about using sampling in a server, my advice is: don't, yet. Wait until your target hosts have first-class support and the cost story is clear. The pattern is right, the implementation is early.
Long-running tools work today -- the streamable HTTP transport supports it, and the SDKs handle the chunk-streaming for you. What's not standardized is the pattern of streaming. How do you signal "intermediate result, not final"? How do you express progress (10% done, 50% done)? How do you let the host show a meaningful loading state?
The protocol has a notification channel that servers can use to send progress updates during a tool call, and that's the right mechanism. What's missing is the convention layer -- the equivalent of HTTP's Content-Type agreed-upon vocabulary for "this is a progress update," "this is a partial result," "this is the final result, you can stop listening."
The spec gives you notifications/progress today, and that's what you should reach for:
// Server-side, mid tool execution
await sendNotification({
method: "notifications/progress",
params: { progressToken, progress: 40, total: 100 },
});
The progressToken comes from the request's _meta.progressToken -- Chapter 2 has the full pattern. What's not normative is the convention layer on top: many authors (me included) wrap a human-readable message field alongside progress/total so the host can render "indexed 2,400 of 6,000 documents" instead of a bare percentage, and others reach for label, stage, or a structured status object. None of it is agreed-upon. I expect a future revision to land richer progress semantics with a stable schema, at which point everyone migrates and the in-the-wild patterns get deprecated.
Don't over-invest in your own streaming convention. Use the SDK's notification primitive, keep your payload shapes small, and be ready to migrate the field names when the spec lands.
Eighteen months ago, the host landscape was Claude Desktop and a few experiments. Today, every major coding agent ships MCP support, every IDE either has it or is shipping it next quarter, and the consumer chat apps are starting to land it. The good news is the protocol won. The interesting news is that capability support is diverging.
Not every host implements every capability. Some hosts support resources but not prompts. Some support tools/list change notifications but not progress updates. Some implement OAuth 2.1 fully, some implement a subset, some still expect bearer tokens. This is normal for a young protocol -- it's how HTTP was for the first decade. But it changes how you ship a server.
The pragmatic move: pick a target host (or three) and make sure your server's surface works there. Document which capabilities your server uses, so a host operator can check compatibility. Don't assume "MCP-compliant host" means "all capabilities supported." Test against the actual hosts your users have.
I keep a watch list of about seven clients. Two are coding agents I use daily. Two are IDE plugins I care about because my users use them. Two are consumer chat apps where MCP support is rolling out. One is a research-grade host I keep tabs on because new capabilities tend to land there first. Every quarter, I check the changelog of each. It takes about an hour. It's the cheapest insurance policy I run.
The server-side market has split into three lanes, and I think this is the shape it stays in for the next several years.
Lane one: free OSS. Independent developers and companies ship open-source MCP servers as a way to expose their product or a third-party API. These are the "I wrote a wrapper around X's API and put it on GitHub" servers. They're great for adoption -- if you want users to discover your product through the agent ecosystem, ship one of these. They're not great for sustained maintenance, because nobody is paid to keep them current with API changes.
Lane two: commercial. A vendor ships an official, supported, first-party MCP server for their product. Stripe has one. Cloudflare has one. Linear has one. GitHub has one. The list is growing fast and I expect it to keep accelerating -- by the end of 2026 every B2B SaaS company with an API will have an official MCP server, the way they all have an official Slack app today. The economics are simple: agentic workflows are now a primary integration surface, and shipping a first-party server is the table-stakes way to support that surface.
Lane three: hosted-managed. Several platforms now run MCP servers as a service -- glama.ai, Yaw MCP (disclosure: I run this one), Smithery, and a handful of smaller players. The youngest of the three lanes, and the one most actively shaped by the protocol's evolution. The pitch is the same one infrastructure-as-a-service made in 2010: you don't want to operate twelve MCP servers yourself, deal with their auth, watch their logs, and patch their dependencies. You want them running, secured, observable, and out of your way.
The competitive landscape is interesting. The handful of us in the space are competing on different vectors -- some on coverage (how many servers you have one-click access to), some on enterprise features (audit logs, SSO, regional deployment), some on developer experience. Pick whichever fits your shape best. The category is real, the demand is real, and the consolidation pattern that hits every infrastructure category will eventually hit this one too.
A few predictions, with my confidence rating.
More vendors shipping first-party servers (high confidence). This is already happening; the question is rate. I think we go from "most major SaaS vendors have one" to "having one is table stakes, and the absence is notable" within twelve months. The same dynamic that made having a Slack app or a Zapier integration mandatory in the 2015-2018 window is happening for MCP servers right now.
Protocol consolidation around streamable HTTP for remote, stdio for local (high confidence). This has effectively already happened in the SDKs and the major hosts. The older SSE-based transport is in deprecation. By mid-2027, the dual-transport story is "stdio for local subprocess, streamable HTTP for everything else," full stop. If you're maintaining a server that still supports the older transports for backwards compatibility, plan the deprecation now.
First "mature" certifications and compliance frameworks (medium confidence). I expect to see the first SOC 2 Type II report for an MCP server in the second half of 2026, the first formal "MCP Server Security Profile" document from a security vendor, and the first procurement-friendly checklist that enterprises use to evaluate which servers are safe to deploy. The shape of these is going to get debated, and the early ones may be premature, but the demand is there. When your largest customer's procurement team starts asking for a third-party security audit of your MCP server, you'll know we've crossed the line.
Enterprise adoption hitting an inflection point (medium confidence). The FedRAMP-shaped questions are going to arrive. Not literally FedRAMP for most of you -- but the same class of question. Where is the data going? What's logged? Who can see the tool calls? What happens in a breach? What's the data residency story? Right now most MCP deployments are in dev tools and individual productivity, where these questions are deferred. When MCP shows up in regulated workflows -- legal, healthcare, finance -- the questions arrive, and the servers (and hosts) that can answer them cleanly win the deals.
A model-side reckoning around reliability (lower confidence, but I'd watch for it). As models get better at tool use, the failure modes shift. The early failure mode was "model picks the wrong tool" or "model hallucinates parameters." The new failure mode is "model picks the right tool but the tool's contract is poorly specified, so the model interprets it wrong." This puts pressure back on server authors to write better schemas and clearer descriptions. The skill of writing tool descriptions that are unambiguous to a model is becoming a real, hireable skill, and I expect tooling to emerge for it.
You don't need to read every spec PR. You do need a small, sustainable set of inputs.
Subscribe to the spec repo. The modelcontextprotocol/specification repo on GitHub. Watch it for releases, not for issues. When a new revision tag drops, read the changelog. Twenty minutes a quarter.
Follow the SDK release notes. Whichever SDK your servers use -- TypeScript, Python, Go, Rust -- the maintainers ship release notes that translate spec changes into code-level changes. This is usually where you'll first hear "this capability is now stable" or "this is the new way to do X." Subscribe to the GitHub releases; let the email do the work.
Keep a watch list of clients. Five to ten hosts your users actually use. Check their changelogs quarterly. The ones to prioritize are: any host you ship a server for, any host your largest customers use, and any host that historically gets new capabilities first.
Follow practitioners, not influencers. The signal-to-noise ratio in the AI ecosystem is genuinely brutal. The accounts and newsletters worth following are the ones written by people shipping production code. They'll talk about specific bugs, specific failure modes, specific patches. Avoid the accounts whose entire timeline is "MCP changes everything" with no concrete details. They're not lying, but they're not helping you either.
Read post-mortems. When someone publishes a post-mortem about an MCP-related production incident, read it. They are rare and they are gold. The shape of the failures teaches you more about the protocol than any explainer.
Actually ship. This is the one most people miss. The fastest way to stay current with MCP is to ship MCP. The cadence below is what I recommend.
Pick two or three MCP servers you maintain, and treat them as your testbed. Ship a release per quarter, even if the release is small. Watch what breaks. Watch what gets noisy in your error logs. Watch what your users complain about.
This is the single most useful piece of practical advice I can give you in this chapter, and it's the one I follow myself. I have fourteen MCP servers under the @yawlabs scope, and three of them are my designated testbeds. They get a release every six to eight weeks, whether the release adds a feature or just bumps deps. The act of shipping forces me to:
If you don't have a server you maintain, write one. The bar is low. A server that wraps an API you already use, exposes five or six tools, and has a npx your-server invocation is enough. It will teach you more in two weekends than any reading list.
The release-per-quarter pattern, in five steps: bump deps, run the test suite, check the spec changelog for anything relevant, ship, watch the logs for a week. If nothing went wrong, the server is healthy and you're current. If something went wrong, you found a bug while it was small.
The MCP ecosystem has a community that's still small enough to actually know each other. A few places worth being:
The @modelcontextprotocol GitHub org. The spec, the SDKs, and the reference servers all live there. Even just watching the issue tracker is useful -- you'll see capability discussions before they land.
The Discord. There's an active Discord where spec questions, host bugs, and server author chatter all happen in real time. Linked from the spec repo. The signal-to-noise is good and the maintainers are present.
The AI Engineer events. The AI Engineer conference and meetup network has become the de facto in-person venue for MCP folks. If you can get to one, the hallway track is worth more than the talks.
Newsletters. A few people in the MCP space publish regularly enough to be worth following: Latent Space and AI Engineer cover the broader agentic-systems landscape with MCP as a recurring topic; my own newsletter, Token Limit News at tokenlimit.news, leans more directly into the MCP server-author beat. Subscribe to none, one, or all, depending on your tolerance for yet-another-newsletter.
If I had to bet on which skills compound for an MCP-focused engineer over the next five years, I'd bet on these four.
The shape of your tool's input and output schema is the contract between your code and an unknowable number of models. A good schema is precise, narrow, and unambiguous. It uses constrained types (enums, regex patterns, format hints) over freeform strings. It rejects the model's incorrect inputs early with clear error messages, so the model can recover.
I expect this to become a specialty. The engineer who can look at a tool API and say "this priority field needs to be an enum, not a string, and the description needs to enumerate the valid values, and the error message needs to suggest the closest valid value when the model gets it wrong" -- that engineer is increasingly hireable. It's not flashy. It's worth a lot.
What happens when a tool fails matters more in agentic systems than in regular APIs, because the model is going to read your error message and decide what to do next. A bad error message produces bad recovery behavior. A good one produces self-healing.
The pattern: every error your tool returns should answer three questions in plain language. What went wrong? What would the user (or the model) need to do differently? Is this transient or permanent? An error that just says "FAILED" with a stack trace is hostile. An error that says "The repository name my repo contains a space, which is not allowed. Try my-repo or my_repo." -- that's an error that lets the model recover without a human in the loop.
You cannot debug a tool-calling agent without good telemetry. The single most underinvested-in skill in the ecosystem right now is "what do you instrument, where do you send it, and how do you query it when something goes wrong at 2 AM."
The traces you want capture: every tool call, with arguments and result, scoped to a session. Every model call, with the tool calls it triggered. Every error, with the chain of tool calls that led to it. The ability to filter by user, by session, by tool, by error class. This is not exotic technology -- it's standard distributed tracing, applied to a system where the orchestrator happens to be a language model.
Engineers who can stand up this layer cleanly are going to be in demand. If you're already strong on observability for backend systems, you have a head start. The thing to add is the agent-specific instrumentation: tool-call decisions, model reasoning summaries (when available), capability-level events.
The threat model for an MCP server is unlike a regular API's threat model. The caller is a language model whose inputs come from a user prompt that may contain adversarial content. Prompt injection is a real attack vector against tool-calling systems, and it bypasses every classical authentication boundary because the auth is correct -- the legitimate user is asking; the model is just being tricked into asking for the wrong thing.
The mitigations are still being figured out, but the broad strokes are: scope tools as narrowly as possible, treat tool descriptions as part of your security surface (a poisoned description can manipulate the model), require explicit confirmation for destructive operations, audit log every tool call with the prompting context, and don't trust the model to enforce policy that should be enforced server-side.
This is a specialty that didn't exist three years ago and is going to be a hiring category within twelve months. If you're security-minded, this is fertile ground.
I want to land on three things.
The protocol is the bet that won. Eighteen months ago, the open question was whether agentic tool use would standardize on a single protocol or fragment into a dozen vendor-specific shapes. MCP won. Not because it was the most elegant design (the spec has compromises, and we've talked about several of them in this book) but because it was good enough, shipped at the right time, and had the right backing. The lesson, for me, is that protocol design is product design -- and the right protocol is the one that solves the immediate pain well enough to get adopted. Perfect is the enemy of shipped.
Tools-as-servers is the right shape. I had doubts about this early. I wondered whether the "every tool is a network endpoint" shape was overkill -- whether tools should just be functions in the same process as the model. Eighteen months in, I'm convinced the network boundary is the right one. It enforces serialization, which forces clean schemas. It enforces explicit auth, which makes the trust model legible. It allows independent versioning, which lets the tool author and the model author iterate on different cadences. It makes observability natural, because the boundary is already a logged event. The design has a cost (latency, operational complexity) but the benefits are structural and the costs are tractable.
The work has just started. Eleven chapters of this book, and we've barely scratched the operational surface. The patterns for agent-native observability are nascent. The patterns for cross-server composition don't exist. The patterns for safe tool use under adversarial inputs are early. The patterns for enterprise governance of MCP deployments are unwritten. If you're an engineer who likes being early on a category that's about to mature, MCP is one of the best ones I can point you at right now.
You finished the book. That's a real thing. Most people don't.
What I hope you got out of it: a clear mental model of what MCP is, why it works, what it costs, and how to ship it without rediscovering every footgun the rest of us hit on the way through. If three years from now you're debugging a flaky tool call at 3 AM and a thing I wrote in here saves you twenty minutes, that's the shape of value I was aiming for. Not transformative -- just useful, reliably, in the moment you need it.
If you want to keep in touch:
Build good servers. Ship the boring releases. Watch the logs.
-- Jeff