Dora NodaEighteen months ago, the Model Context Protocol was one lab's side project for plugging tools into a chatbot. Today it drives 97 million SDK downloads a month across an ecosystem of more than 10,000 public servers, and answers to a neutral foundation backed by every major model lab and cloud. The protocol your deploy bot speaks just got a neutral landlord — and that changes the build-or-wait math for any team considering an MCP server that actually ships infrastructure.
The verdict, up front: ship now. Build the deploy server against the stable MCP core — the stateless 2026-07-28 spec, tools/resources/prompts over HTTP, the Tasks extension for long-running deploys, hardened OAuth — with scoped credentials and human approval on every mutating call. Design the server to be discovery-ready for Server Cards, but do not block on them: the discovery layer is still experimental, while everything you need to take a deploy from chat to production is already stable. The rest of this post is the evidence for that call.
What vendor-neutral governance actually buys a builder
On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, alongside Block's goose agent framework and OpenAI's AGENTS.md. Anthropic, Block, and OpenAI co-founded the effort, with Google, Microsoft, AWS, Cloudflare, and Bloomberg signed on in support. Then, in August 2026, Google's agent-to-agent protocol A2A joined the same foundation, putting the two big agent-interoperability standards — MCP for agent-to-tool, A2A for agent-to-agent — under one roof.
That sequence matters less as press-release trivia than as a risk ledger. Before the donation, shipping production infrastructure automation on MCP meant betting a deploy pipeline on a protocol one vendor could relicense, deprioritize, or steer toward its own cloud. After it, three concrete protections exist that did not before:
- No single-vendor rug-pull. The spec, SDKs, and registry now live under multi-stakeholder governance. A roadmap decision needs consensus across competing labs and clouds, which is exactly the dynamic that kept Kubernetes and OpenTelemetry boring in the good way.
- A versioned extension framework. The current spec formalizes how capabilities like Tasks and MCP Apps graduate from experiment to stable extension, so builders can adopt new surface area with a documented lifecycle instead of tracking one company's changelog.
- A twelve-month deprecation floor. The 2026-07-28 specification guarantees at least a year of notice before a breaking removal. For a deploy server — the kind of component that pages someone at 3 a.m. when it breaks — a contractual migration window is worth more than any feature.
The adoption numbers back up the governance story. The MCP Registry launched in September 2025 and indexed roughly 2,000 servers within months. By March 2026 the Python and TypeScript SDKs were pulling a combined 97 million downloads a month — up from about 100,000 in the first month, a roughly 970x climb in sixteen months — and the public server count has since passed 10,000.
SDKs now span Python, TypeScript, C#, Java, Go, Kotlin, and Swift, and first-class client support ships in ChatGPT, Claude, Gemini, Copilot, VS Code, and Cursor. Building a deploy server on MCP today means meeting agents where they already are, not evangelizing a new client.
Server Cards: the discovery piece you should track, not block on
The biggest thing MCP still lacks is domain-level discovery. Today a human pre-configures every server an agent may use: paste the endpoint, wire the credentials, hope the config drifts nowhere. There is no standard way for an agent to ask a domain "what MCP servers do you run, what can they do, and how do I authenticate?" — the equivalent of /.well-known/oauth-authorization-server for OAuth or /.well-known/openid-configuration for OpenID Connect.
Server Cards are the proposed answer. The work started as SEP-1649 ("MCP Server Cards: HTTP Server Discovery via .well-known"), authored by Anthropic's spec team, and continues as PR #2127 with an official Server Card Working Group (leads from Anthropic and GitHub, chartered March 2026). The shape under discussion is a .well-known JSON document advertising a server's capabilities, transports, and auth requirements, so crawlers, IDEs, and agents can auto-discover servers instead of reading human-written setup docs.
For a deploy-from-chat server, that is the difference between a demo and a distribution channel. Imagine an agent that encounters your platform's domain, reads its server card, learns it exposes an authenticated deploy tool with OAuth requirements stated up front, and offers the user a one-click "connect and ship" flow. No YAML snippet copied from docs, no stale endpoint in a dotfile.
But — and this is the half of the verdict that counsels patience on this one piece — Server Cards are still experimental. The reference work lives in modelcontextprotocol/experimental-ext-server-card, whose own README warns it is not an accepted or official extension, and the SEP itself remains under review. Here is the honest status table:
| Question | Status |
|---|---|
| Problem agreed (no domain-level discovery in core spec) | Yes |
.well-known card shape proposed | Yes (SEP-1649 → PR #2127) |
| Working group chartered | Yes (March 2026) |
| Final field set clients can rely on | Not yet |
| Client auto-discovery shipped in major hosts | Not yet |
So: design your server so a card can describe it later — stable HTTPS endpoint, standard OAuth, a deterministic tool list — but ship the human-configured connection path now. Discovery will upgrade your distribution; it is not a prerequisite for your first user.
The 2026-07-28 spec: the stateless core to build on
While discovery settles, the protocol core just had its biggest revision since launch. The finalized 2026-07-28 specification makes MCP stateless at the protocol layer: the initialize/initialized handshake is gone, Mcp-Session-Id sessions are gone, and each call carries its own metadata. Server-initiated interactions move to the Multi Round-Trip Requests pattern, Tasks and MCP Apps graduate into the versioned extensions framework, OAuth authorization is hardened, and tool definitions adopt JSON Schema 2020-12.
For a deploy server, three of those changes are directly load-bearing:
- Stateless HTTP is the transport to target. No session affinity means your MCP endpoint scales on ordinary HTTP infrastructure — the same load balancer and autoscaling you already run for your API. Server-Sent Events streaming is being phased out, so new servers should not be built on it.
- The Tasks extension fits deploy jobs natively. A deployment is the canonical long-running operation: queue, build, push, health-check, done-or-rollback. Tasks give you progress reporting and cancellation as protocol primitives instead of polling a resource or inventing your own job handle.
- Deterministic tool lists are now a contract. The spec requires
tools/listto be stable per server rather than varying per connection, with cache hints on list results. That is what makes future Server Cards describable — and what makes today's clients cache your surface sanely.
One caution: 2026-07-28 is a breaking change from the 2025-11-25 revision. If you prototyped a server against the older spec, budget the migration — sessions out, per-request metadata in — and lean on the twelve-month deprecation window rather than rushing it. New servers should simply start on the new core.
The decision: build now vs. wait, as a table
With the evidence in hand, here is the verdict from the top of the post expanded into the matrix a platform team can argue over:
| Factor | Stable (build on it) | Still settling (design around it) |
|---|---|---|
| Protocol core | tools/resources/prompts over stateless HTTP | — |
| Long-running work | Tasks extension | — |
| Auth | Hardened OAuth flow | Per-ecosystem credential UX norms |
| SDKs | 7 languages, 97M monthly downloads | — |
| Clients | ChatGPT, Claude, Gemini, Copilot, VS Code, Cursor | Auto-discovery of new servers |
| Discovery | Human-configured connections | Server Cards final shape (SEP/PR #2127) |
| Agent-to-agent | MCP vertical (agent→tool) | A2A interplay patterns post-AAIF merger |
The "wait" column is real but narrow: it contains discovery ergonomics and cross-protocol patterns, not the ability to take a deploy from chat to production. Nothing in it invalidates a server you ship today, provided you keep the endpoint, auth, and tool list conventional enough for a future card to describe. The "build" column, meanwhile, is everything a deploy server needs — and every month you wait is a month your competitors' deploy tools are the ones agents already know.
Sketch: what a deploy-infrastructure MCP server actually exposes
Concretely, what does the ship-it-now server look like? The shape is already precedented: Vercel's MCP adapter exposes deployment and log tools to agents, Cloudflare's MCP servers manage Workers, D1, KV, and R2, Lens ships a Kubernetes-connected MCP server inside its IDE, and StackGen offers infrastructure-lifecycle management over MCP. A PaaS deploy server follows the same grammar:
Tools (the verbs):
deploy— take a repo/branch (or image) plus environment, return a Task handle for the rolloutget_deployment— status, URL, commit, and health of a deploymentget_build_logs/get_runtime_logs— the two log streams an agent needs to debug a failed shiprollback— point the environment at the previous healthy deploymentlist_projects/list_environments— the read-only inventory agents need before they act
Resources (the nouns): project configs, environment variables metadata (never secret values), and deployment history, exposed read-only so agents can reason about state without side effects.
Guardrails (the non-negotiables for anything that mutates production):
- Human approval on every mutating call —
deployandrollbackpropose, a person disposes, at least until your audit log earns tighter autonomy. - Scoped, short-lived credentials per server connection — the OAuth hardening in the new spec exists precisely so a chat tool never holds a god-mode API key.
- An audit trail that records which agent, which user approval, and which tool call produced each deployment. When the 3 a.m. page comes, "the agent did it" is not a root cause.
Note what this sketch does not include: a custom client, a new transport, or any bet on an unsettled spec piece. It is the stable core plus operational discipline — which is exactly why the verdict is "now."
The window is open
MCP's story in 2026 is a standards story playing out at unusual speed: neutral governance in December, a stateless core spec in July, the sibling agent protocol under the same foundation in August, and a discovery mechanism visibly converging but not yet landed. For infrastructure builders, that sequence is unusually legible. The foundation era removes the governance risk that used to justify waiting; the stateless spec gives you a scaling story your existing HTTP stack already satisfies; the only thing still cooking is how agents will find you — and "agents find you slightly less automatically for a few quarters" has never been a reason to keep a working deploy tool off the shelf.
Build the server. Keep the surface conventional. Be first in line when the cards arrive.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators here: a deploy-from-chat MCP server is on the roadmap, and the neutral-governance era is exactly why. Star the repo on GitHub or deploy your first app today.
