Dora NodaSome time in early 2026, the Model Context Protocol crossed 10,000 active public servers, with SDK downloads running at 97 million a month — and governance of the whole thing moved out of any single company into the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI in December 2025. That is the moment a protocol stops being an integration fad and starts being infrastructure: every major AI provider now speaks it, 41 percent of senior software leaders report being in production with it, and the 2026 roadmap is no longer about getting connected but about surviving scale.
Here is the problem scale creates. Today, every one of those connections is hand-wired: a human edits a config file listing each server's command or URL, the client opens a stateful session pinned to one server instance, and the agent only learns what tools exist after a live connection is already up. That works for five servers. It does not work for ten thousand — and it especially does not work for the use case the roadmap is explicitly aiming at, where an orchestrating agent discovers infrastructure on its own and calls it without a human wiring the connection first.
The answer up front, with the receipts to follow: once agents find your tools instead of being pointed at them, your tool surface becomes your security boundary, so a deploy-capable MCP surface should ship in three tiers — read tools that agents may call freely, mutating tools like deploy and rollback that require an approval gate, and destructive tools that default to denied with per-environment policy. Discovery will amplify whatever you expose. Scope it before it scales.
How an agent connects to tools today: a human in the loop, holding a config file
The current connection flow has three properties, and all three assume a human did the setup:
1. Hand-written server lists. Each MCP server the agent may use is enumerated by a person in a configuration file — a local command to spawn for stdio servers, a URL for remote ones. No registry, no crawling, no discovery. If the server is not in the file, the agent cannot see it.
2. A stateful handshake per connection. The client performs an initialize handshake that negotiates versions and capabilities, and the resulting session is pinned to the specific server instance on the other end. Requests for the same session expect shared state on that instance — which is exactly why the Transports working group flags stateless scaling as the unsolved problem: today, requests for one session landing on different instances find no shared state.
3. Capabilities known only after connecting. The agent learns a server's tools by opening a live JSON-RPC session and calling tools/list (alongside separate prompts/list and resources/list probes). There is no way to ask "what are you?" without first connecting — no cacheable card, no metadata endpoint, nothing a registry can index.
For a developer pointing Claude Code at a local filesystem server, this is all fine. For an agent that is supposed to find a deploy tool in a fleet of thousands of servers and roll back a broken release at 3 a.m. without paging anyone, every one of these properties is a missing piece.
What stateless operation and self-description actually change
The 2026 roadmap and the July 2026 specification (version 2026-07-28) attack all three properties at once. Concretely, three mechanisms:
| Mechanism | What it is | What the agent no longer needs a human for |
|---|---|---|
server/discover | A mandatory request the client can send before any other: one call returns supported protocol versions, capabilities, identity, and plain-language usage instructions, cacheable for up to an hour (ttlMs, cacheScope: public) | Probing a live session to learn what a server does — identity and capabilities arrive in a single round trip |
| MCP Server Cards | Structured server metadata served from a .well-known URL, on the roadmap for 2026 delivery, so registries and crawlers can index capabilities without opening any session | Being told the server exists at all — discovery moves from config files to crawling |
| Stateless Streamable HTTP | Transport evolution so any server instance can serve any request, with session creation, resumption, and migration across instances during scale-out | Depending on one pinned instance staying alive — restarts and replicas become transparent |
Note the honest caveat the spec itself carries: serverInfo is self-reported and explicitly must not drive security decisions. Discovery tells the agent what a server claims to be. Trust is a separate layer — which is precisely why the scoping question matters more, not less, once discovery works.
Together, though, the direction is unambiguous: from a manually-configured list of single tool connections toward infrastructure an orchestrating agent discovers and calls on its own. The protocol is being rebuilt for a world where the human never touches the config file. So the question stops being "which servers do I wire up?" and becomes "what happens when an agent I have never met finds my tools?"
Why deploy and rollback tools are the sharp edge
Most of the 10,000 servers expose forgiving tools: query a database, check a weather API, search docs. A misfire costs a wrong answer. Deploy tooling is different in kind, not degree — it bridges model output directly to privileged action on production systems. Three facts make it the sharp edge of autonomous discovery:
Prompt injection becomes remote code execution with extra steps. OWASP's GenAI security guidance for MCP servers names the quartet — tool poisoning, prompt injection, memory poisoning, tool interference — and its mitigations read like a deploy pipeline's job description: authentication, least-privilege authorization, client sandboxing, secure server discovery, and human-in-the-loop governance. A poisoned tool description that tricks an agent into calling deploy with attacker-controlled parameters is not a chatbot hallucination; it is an unauthorized production change wearing a tool call as a disguise.
The credentials are already there. MCP-enabled workflows reach real systems through tokens, API keys, and service credentials, and reviewers keep flagging the same failure: overly-permissive OAuth scopes that hand every tool the keys to everything. A deploy server that also mints database credentials or rotates secrets concentrates more blast radius in one tool list than any other category of server.
The industry already gates these calls — when a human designs the flow. Real deployments show the pattern: per-agent tool approval requirements set independently of tool-level flags, PreToolUse hooks that intercept destructive calls while letting reads pass at full speed, approval-gated plans before any apply, cost estimates computed before deploy rather than surprise bills after. Agent-native hosting experiments even check deploy manifests and rollback anchors into the repo — a deploy.policy.json stating what agents may do per environment, and a rollback pointer recorded with every release. The ecosystem has converged on the answer. It just has not converged on making it the default.
So when discovery starts working — when any agent can find your deploy tool without a human introducing them — the servers that survive contact with autonomous callers will be the ones whose tool surface was designed as if every caller were untrusted. Which brings us to the blueprint.
The blueprint: a three-tier deploy surface built for strangers
If you run a platform with an MCP surface that can change production — deploy, rollback, scale, set secrets, delete apps — here is the concrete shape to advertise, sized for a world with Server Cards. Three tiers, no exceptions:
| Tier | Tools (typical) | Policy | Example |
|---|---|---|---|
| Observe | get-status, get-logs, list-apps, describe-release | Auto-allowed; read-only OAuth scope; logged | Agent checks whether the canary is healthy before deciding anything |
| Mutate | deploy, rollback, scale, set-env (names only, never values in manifests) | Approval-gated per call; human or policy approval required; dry-run first where possible | Agent stages a rollback to the recorded anchor and waits for approval |
| Destroy | delete-app, rotate-secrets, purge-data, transfer-ownership | Deny by default; per-environment policy file decides; production always requires a human | Agent may propose deletion in staging; in production the call does not exist for it |
Four load-bearing details sit underneath the table:
1. OAuth scopes per tool, not per server. The spec defines OAuth 2.1 as the authorization framework for remote servers — use it at tool granularity. An agent holding a read scope must physically lack the token that invokes deploy, not merely be asked nicely not to. Overly broad scopes are the most-reported MCP auth failure; per-tool scopes turn a compromised agent session from a fleet-wide incident into a read-only one.
2. Approval gates that match the blast radius. Gate delete_* and deploy_* while letting read_* pass without friction — the hook pattern already proven in production harnesses. Approvals should bind to the exact parameters (image digest, target environment, replica count), not to a blanket "yes, do deploys," or the gate becomes theater.
3. An immutable audit log per tool call. Every invocation and its result, attributable to the agent principal and the policy that authorized it. When something breaks at 3 a.m., the difference between "the agent did something" and "agent X called rollback with digest Y under approval Z" is the difference between a mystery and a postmortem.
4. Per-environment policy as data, not vibes. What agents may do in staging versus production belongs in a versioned policy file next to the app manifest — reviewable in a pull request, diffable, revertable. If the policy cannot be read in a PR, it is not a policy; it is a hope.
Notice what this blueprint does to the Server Card question: the card advertises the Observe tier loudly and the Mutate tier with its approval requirements attached. A self-describing server that hides its gating is worse than a hand-wired one — discovery without declared policy is just faster trust.
What to ship while Server Cards land
Cards are roadmap, not reality — the .well-known discovery standard is targeted across 2026 delivery, not sitting in your SDK today. Three things are worth doing before it arrives, because all three are good regardless:
1. Implement server/discover with honest instructions. The field exists in the current spec precisely to carry natural-language guidance for LLMs on how to use the server effectively. Write it like the stranger is already reading it: what each tier may do, what requires approval, what is denied. It is the cheapest version of a Server Card and it works now.
2. Build stateless-first. Serve every request from any replica with no pinned session state, so restarts are transparent and horizontal scaling needs no session migration heroics. Stateless operation is where the transport is going; servers built for it today inherit the scaling story for free.
3. Narrow the surface before discovery amplifies it. Audit every tool against the three tiers. Anything in Mutate without a gate, anything in Destroy without a deny-by-default, anything with a broader OAuth scope than its tier needs — fix it while your callers are still humans you know. Once crawlers index your card, the set of callers becomes everyone.
The config file is going away; the boundary is not
The arc of the 2026 MCP roadmap points one way: connections get discovered, sessions get stateless, and the human with the config file exits the loop. That is genuine progress — it is what turns ten thousand servers from a curiosity into infrastructure an agent can actually navigate.
But every connection the human stops vetting is a connection the tool surface has to survive on its own. Least privilege, per-tool scopes, approval gates on mutation, deny-by-default on destruction, and an audit trail that names names: none of this is new advice. What is new is that discovery makes it load-bearing. Build the surface for strangers, because strangers are exactly who is coming.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
