Dora NodaSix months after a Fortune 500 bank gave every developer an AI coding assistant, usage was declining, completion rates were poor, and there was no measured productivity gain to show for the licenses. Three months later, the same company was running more than 100 MCP servers in production, serving 500-plus employees a week, against 6,000 GitHub repositories and a 160-petabyte BigQuery table — and developers were shipping faster with lower error rates. The turnaround is documented in Stacklok's Fortune 500 financial-services case study, and it is the most detailed public account we have of what operating the Model Context Protocol at real scale actually requires: a containerized runtime on Kubernetes in an air-gapped private cloud, an OAuth-gated gateway, a curated registry of trusted servers, and a virtual-server layer that consolidates tools from many servers into one endpoint.
The headline numbers are the scoreboard. The interesting part is the playbook — and which pages of it a team running one self-hosted MCP server should steal on day one instead of rediscovering at server number twenty. Here is the whole checklist up front; the rest of the post unpacks each line with the bank's evidence behind it.
| # | Practice | What the bank built | Your day-one version | Upgrade when… |
|---|---|---|---|---|
| 1 | Registry gate | Central team validates every server; unapproved servers blocked | A pinned server list in git; install only from it | A second team starts adding servers |
| 2 | Gateway auth | OAuth 2.0 + PKCE, federated token exchange, network isolation | Remote MCP over HTTPS behind one auth point; no tokens in client configs | Multiple identity providers or tenants |
| 3 | Tool consolidation | Virtual MCP server: granular tool selection, one endpoint | Expose minimal toolsets per agent; prune descriptions | Agents juggle five or more servers |
| 4 | Token budget | MCP Optimizer filtering metadata; token use cut by half | Strip verbose metadata; measure tokens per call | Context pressure starts degrading answers |
| 5 | Gateway observability | Reliability, usage, and accepted-vs-rejected metrics in New Relic | Log every tool call — allow/deny, latency — from day one | You need retention policies and dashboards |
Why the assistants failed first
The bank's story starts in the fall of 2024, when it licensed Cursor and Claude Code for its developers. Six months later the verdict was bleak: completion rates were poor, usage was declining, and developer productivity had not budged. The diagnosis was straightforward — the assistants had been trained on public information, not on the company's systems. The bank had coding assistants built for any enterprise when it needed assistants that understood its own repositories, artifacts, and data warehouse.
The team considered building custom integrations and rejected them as unsustainable and unscalable: every new data source would mean another bespoke connector to maintain. The Model Context Protocol was the answer to the integration problem, but the team also recognized that the protocol spec alone lacked the security guardrails and centralized controls a regulated bank requires. So they built the missing layer themselves, on top of Stacklok's open-source ToolHive runtime — containerizing every MCP server and running the fleet on Kubernetes inside their air-gapped private cloud. That decision, more than any other, is what makes this case study useful to self-hosters: the bank's constraints (own the machines, trust no outside SaaS with the data path) are your constraints, at 100x the server count.
Lesson 1: Registry before sprawl
The bank's third step was curating a registry of trusted MCP servers: a tightly scoped set covering business-critical systems, plus a wider set for non-technical roles. Every server must be validated by a central team before inclusion, employees are blocked from using unapproved servers, and each approved server is preconfigured so it installs with a single click. Discovery and governance are the same motion — you find servers by browsing the registry, which means you can only find servers someone has vetted.
This matters because MCP servers multiply silently. In a related account of this deployment, Stacklok reports that a new-server alert fired on three previously unknown servers in its first week — shadow MCP, already entrenched before governance arrived. And the supply side keeps growing: the official MCP registry at registry.modelcontextprotocol.io has had its v0.1 API frozen since October 2025 as the discovery surface MCP clients browse natively, and public directories listed on the order of ten thousand servers by early 2026.
Your day-one version is a pinned server list in git: every MCP server your agents may use is named, versioned, and installed only from that list. No npx of whatever looked good on a directory page. The day a second team starts adding servers, promote the list to a real approval workflow — but the muscle (nothing runs unlisted) should exist from the first server.
Lesson 2: Gateway auth, not per-server secrets
Authentication was the bank's first gateway problem, solved with OAuth 2.0 plus PKCE per the MCP spec, then hardened with request routing, authorization, session management, federated token exchange, and network isolation of the servers themselves. The accompanying discipline reads like a checklist worth stealing verbatim: approved base images only, enforced token expiry, no hardcoded secrets, least privilege, and configuration reviews on a defined cadence.
Contrast that with the default failure mode of small deployments: local stdio servers, each with its own credentials in a client config file, invisible to any identity system. Microsoft's MCP-on-Azure guidance calls this out explicitly — stdio servers create credential sprawl, bypass enterprise identity and policy controls, and provide zero visibility, which is why its default production pattern is remote MCP servers over HTTP behind centralized auth. The stakes are not theoretical: early 2026 saw roughly 30 CVEs filed against MCP infrastructure in about sixty days, plus tool-poisoning exploits (CVE-2025-54136, CVE-2026-26118) and even a February npm worm whose McpInject module planted a rogue MCP server to harvest SSH keys and cloud credentials from developer machines.
Your day-one version is one rule: remote MCP over HTTPS behind a single auth point, no tokens in client configs. Federated token exchange can wait until you have multiple identity providers — but the shape (the agent authenticates to the gateway, the gateway authenticates to everything else) should be there from the start, because retrofitting it means touching every server.
Lesson 3: Consolidate tools behind a virtual server — this is the discovery answer
The MCP spec defines a one-to-one relationship between a client and a server, and the bank hit that wall early: real tasks need multiple tools from multiple servers. Its answer is the case study's most forward-looking piece — a virtual MCP server that groups tools from many servers behind a single endpoint, with granular tool selection instead of exposing entire catalogs. Two properties make it a security feature, not just ergonomics: developers stop managing per-server connections and custom configurations, and API keys get substituted for environment variables so they are never injected into LLM context.
Note what this solves for capability discovery — the third item on the scale-requirements list. At one server, discovery is trivial: connect and list tools. At one hundred, no agent should see one hundred tool catalogs; the virtual server is the discovery layer, presenting each developer with the tools for their task and nothing else. The bank is co-developing this capability with Stacklok as open-source ToolHive functionality, with templates per environment and consistent naming schemas.
Your day-one version is the poor man's virtual server: expose minimal toolsets per agent and prune every tool description to what the model needs. When your agents start juggling five or more servers — or when the same credential starts appearing in prompts — graduate to real aggregation.
Lesson 4: Budget the tokens
Here is the number that should end every "MCP context overhead" debate: after enabling ToolHive's MCP Optimizer functionality, which filters out useless tool metadata, the bank cut its token use by more than half — and model performance improved. Half the tokens, better answers. Bloated tool schemas were not just expensive; they were noise the model had to reason around.
This lands in the middle of an industry-wide argument. MCP adoption is undeniable — roughly 97 million monthly SDK downloads by March 2026, up from about 2 million at launch — but 2026 also hosted a loud public debate over whether MCP's context-window overhead makes it a dead end, with prominent critics pointing at the token cost of big tool catalogs. The bank's result reframes that debate: overhead is a property of ungoverned deployments, not of the protocol. Measure tokens per tool call the way you measure latency, and the "overhead" turns out to be mostly metadata nobody needed.
Your day-one version is measurement plus hygiene: strip verbose descriptions and unused schema fields before you ship a server, and track tokens per call from the first week. An optimizer pipeline can come later; the habit of treating context as a budget cannot.
Lesson 5: Observe the gateway, not just the model
The bank invested early in monitoring, tracking four things: MCP gateway reliability, MCP server usage and performance, infrastructure health, and accepted-versus-rejected codebase additions. ToolHive feeds this into the bank's existing New Relic deployment, enforces data retention policies, and maintains audit logs. That last metric — accepted versus rejected additions — is the telling one: they measure whether the agents' output survives human review, closing the loop from tool call to shipped code.
Most small deployments observe exactly none of this. The model provider's dashboard shows tokens; nothing shows which tools get called, which get denied, or whether the code they produce gets kept. When something goes wrong — a poisoned tool description, a runaway agent looping on an expensive query — there is no log to read, only a bill to dispute.
Your day-one version is a structured log line per tool call: timestamp, agent identity, server, tool, allow-or-deny, latency. Retention policies and dashboards can wait; the raw record of what your agents did cannot be reconstructed later, and it is the evidence every future security review will ask for first.
What the production ceiling actually means now
So what does this deployment prove about MCP's production ceiling? The honest reading cuts both ways. On one side: 100 governed servers, 500 weekly users, three months from failing pilot to production, in a regulated bank, on infrastructure the bank owns outright — that is not a ceiling, it is a floor, and it was established by a small focused team, not an army. The protocol clearly scales past anything a self-hosted shop will need this year.
On the other side, the industry's overall pilot-to-production record is sobering: one 2026 enterprise survey found only 11–14% of MCP pilots reaching production, with governance — identity, auditability, lifecycle control — named as the blocker. The bank succeeded precisely because it built the governance layer first: runtime, gateway, registry, then users. Teams that skip straight to users get the 86% outcome.
That ordering is the real lesson, and it compresses to a single sentence: run your first MCP server the way the bank runs its hundredth — listed, gated, consolidated, budgeted, and logged. The five practices above cost almost nothing at server one and become a migration project at server twenty.
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: every deploy, log, and status your dashboard shows is also machine-readable over the API. Star the repo on GitHub or deploy your first app today.
