One endpoint for every agent, instead of 20 MCP configs per repo.

Background

The platform team supported around sixty engineers across a dozen product squads. Over a year of MCP adoption, each squad had wired up its own set of servers — GitHub, Postgres, Linear, Sentry, an internal deploy tool — directly into Claude Code and Cursor configs. Every repository carried its own mcp.json, and onboarding a new tool meant a pull request against every project that wanted it.

The setup worked, but it did not scale. Twenty-odd servers were now duplicated across dozens of config files, each with slightly different versions and credentials pasted in by whoever set it up first.

The challenge

Three problems kept surfacing in retros.

• Config sprawl. Adding or upgrading a server meant touching every repo. Configs drifted, and no one could say with confidence which squads had which tools.
• Credentials in the wrong place. Personal access tokens and API keys lived in developer machines and, occasionally, in committed config. Rotating a leaked token was a scavenger hunt.
• A crowded context window. Each MCP server pushed its full tool schema into every prompt. With twenty servers connected, the agent spent a large share of its context on tool definitions before it saw a line of the actual task.

The approach

The team stood up a single onemcp portal and added their servers to it once, authenticating each upstream in place. Instead of every client speaking to every server, clients now speak to the portal, and the portal fans out to the upstreams.

Two things changed the shape of the problem:

• One endpoint replaces many. A repo no longer lists servers; it points Claude Code or Cursor at the portal URL and inherits the whole curated toolset. Swapping or upgrading a server happens once, in the portal.
• Code Mode replaces the wall of definitions. Rather than injecting every tool schema up front, the portal exposes three meta-tools — search, describe, and execute. The agent discovers the handful of tools a task needs and calls them from a single script, in one round-trip.

The rollout

Migration ran squad by squad over two weeks. For each repo, the team deleted the local server list and dropped in one portal entry. Because the portal held the credentials, developers removed tokens from their machines as they went.

The platform team kept the portal as the single control point: new servers were vetted and added centrally, and access was managed in one place instead of across dozens of mcp.json files.

Results

• 20+ servers behind one endpoint. Repositories reference a single portal URL. Adding a tool is a portal change, not a fleet-wide pull request.
• ~90% smaller tool overhead per request. Replacing hundreds of pre-loaded definitions with three meta-tools brought per-request tool overhead down from roughly 15,000 tokens toward ~500 — context the agents now spend on the task.
• Credentials host-side. Upstream OAuth and tokens live in the portal, never in client configs or committed files. Rotation is one update in one place.

We stopped shipping MCP config in pull requests. Now a repo points at one endpoint and gets everything, and the security team owns the tokens instead of us.

Related case studies

• An AI support agent on a token diet
• Self-serve data agents without leaking credentials