ZopNight’s MCP Server Enables Cloud Governance for AI Agents
An MCP server sits between a platform and every AI client that talks to it: Claude, Cursor, Codex, and anything else built against the Model Context Protocol spec. When that spec moves forward, the server maintaining it faces a real choice. Upgrade globally and every client still speaking the old revision fails on the same day. ZopNight already exposes 43 read-only MCP tools to clients like these. Don’t upgrade, and the server falls behind what newer clients expect to negotiate.
ZopNight’s MCP server now supports the latest protocol revision, dated 2026-07-28, with per-request version negotiation, server discovery, a cacheable tools list, and a real error code for a version it doesn’t support. None of that forced a migration deadline on anyone connected to it today. That stability matters because MCP is the layer autonomous cloud governance runs through: an AI ops workflow can only act reliably on a platform if the protocol underneath it doesn’t shift without warning.
The New Protocol Ships Dark, Behind a Flag Defaulting to the Old One
The whole feature is gated behind a version flag, and that flag defaults to the older 2024-11-05 revision. Nothing observable changes for a client that doesn’t ask for the new behavior. That’s what “additive” is supposed to mean in practice: a change that exists in the code and does nothing until something on the other end explicitly requests it. A flag that defaults to on would have the same code behind it and a completely different risk profile, because every existing integration would inherit new behavior it never asked for on whatever day the deploy happened to land.
Negotiation Happens Per Request, Not Once for the Whole Server
The mechanism that makes this safe is per-request negotiation. A client signals which protocol revision it wants through params._meta and a header, the server resolves that once per request, and the resolved version threads through everything that request touches. That’s a different design than a server-wide switch decided once at startup or once per deployment.
A client still on the older revision and a client that’s moved to the new one can hit the identical server, at the identical moment, and each gets the behavior its own request asked for. Neither one has to know the other exists, and neither one’s behavior depends on when the other client happens to upgrade. This works when a client negotiates correctly on every request it sends. It fails when a client caches a stale negotiated version across requests, since the server has no way to know the cached choice no longer reflects what that client actually wants.
What the New Revision Actually Adds
Four capabilities exist on the new revision that don’t exist on the old one. A server/discover method lets a client learn about the server before committing to a full session. A resultType of "complete" gives a client a clearer signal about response shape. The tools/list response becomes cacheable, with a configurable time-to-live and a private cache scope, so a client doesn’t have to re-fetch the same tool list on every connection. And the ping method, present in the older revision, is removed specifically in 2026-mode requests, since discovery replaces the need for it.
| Capability | What it’s for | Which mode gets it |
|---|---|---|
| server/discover | Learn about the server before a full session | 2026-07-28 only |
| resultType: complete | Clearer signal about response shape | 2026-07-28 only |
| Cacheable tools/list | Avoid re-fetching the same tool list every connection | 2026-07-28 only |
| ping | Basic liveness check | 2024-11-05 only, removed in 2026 mode |
Why an Additive Change Still Needs a Real Error Code
Shipping dark by default doesn’t mean every possible request succeeds quietly. A client that asks for a protocol version the server genuinely doesn’t support gets error code -32022 back, not a silent failure or a response that half-works. That distinction matters because “ships dark” is a claim about default behavior, not a claim that every edge case degrades gracefully on its own. An explicit, documented error keeps the opt-in default honest. A client that gets something wrong finds out immediately. It doesn’t discover it three requests later from behavior that doesn’t quite make sense.
This works for any client negotiating protocol versions built against a supported revision, old or new, correctly on each request. It doesn’t yet say when, if ever, the default will flip to the newer revision, so an integration that wants the new capabilities has to opt in deliberately rather than wait for them to arrive automatically. For a server sitting in the request path of every AI client a platform connects to, that’s the more defensible order to ship it in: prove the opt-in path is safe, decide on a default later.
