All answers

Everyone on the team connects their own MCP servers and context is not centralized. What fixes this?

Dennis PilarinosDennis Pilarinos·Oct 26, 2026·Context Engine · AI Agents

Two things. First, put the shared server list in version control so every engineer loads the same set. Second, replace the pile of lookup servers (GitHub, Jira, Confluence, Slack) with one context engine server that returns a single reconciled answer. Add an MCP gateway only if you still run ten or more tool servers that need shared auth and an audit trail.

When everyone connects their own MCP servers, context is not centralized because each engineer is running a private copy of the same integration work. The fix has two parts. Move the shared server list into version control so the whole team loads one set. Then collapse the servers that exist only to look things up (GitHub, Jira, Confluence, Slack, Notion) into one server that answers the question instead of handing back raw results. MCP sprawl is the state where each person on a team keeps their own list of Model Context Protocol servers, keys and logins, with no shared configuration and no shared answers. An MCP gateway is a proxy that fronts many MCP servers behind one endpoint and handles authentication, routing, rate limits and logging. A context engine is a service that ingests code, pull requests, tickets, docs and chat, and returns one cited, permission-filtered answer through a single MCP server.

What everyone connecting their own MCP servers costs#

The first cost is the context window. Anthropic's tool-search documentation gives the figure for a typical five-server setup (GitHub, Slack, Sentry, Grafana and Splunk): about 55,000 tokens in tool definitions before the model does any work. The same page says tool selection accuracy degrades once an agent has more than 30 to 50 tools available. Claude Code's tool search defers MCP tool definitions by default; the accuracy problem remains for any client that loads tools up front.

The second cost is the one we hear on sales calls: a dozen API keys and a handful of servers that keep asking to reauthenticate, each on a different laptop. Nobody can see who connected what, and a fix one engineer finds stays on that laptop.

The third cost is the quiet one. Every engineer asks the same question about the billing service. Every agent pulls the same four raw result lists into its own context window and reconciles them there, which is exactly the regime where model performance degrades as context grows (Cao et al., 2026). The reconciled answer is thrown away when the session ends. The MCP project's 2026 roadmap names the enterprise gaps as audit trails, SSO-integrated auth, gateway behavior and configuration portability. None of those is a shared answer, so the roadmap will not close this gap on its own.

Fix one: an MCP gateway centralizes access#

A gateway solves the access half. One endpoint fronts every approved server, injects credentials, applies allow-lists and logs every call. Docker's MCP Gateway, IBM's ContextForge and Amazon Bedrock AgentCore Gateway all take this shape. It is the right fix when the problem is governance: many tool servers, many keys, and a security team that needs a call log.

What a gateway does not change is what comes back. The agent still makes four calls for one question and still reconciles four raw result lists on its own. If the complaint is "context is not centralized," a gateway centralizes the plumbing and leaves the context where it was. The longer comparison is in MCP gateway vs context engine.

Fix two: a context engine centralizes the answer#

A context engine solves the answer half. It sits behind one MCP server, so it goes into the shared config once. When an agent asks why the retry limit is three, the engine has already read the merged pull request, the Jira ticket that argued about it and the Slack thread where the decision was made. It returns one answer with citations, filtered by the asking user's permissions. Every engineer and every agent gets the same answer, and the lookup servers come out of the list.

Unblocked is one of these. We measured the difference in a same-prompt, same-model run: the agent with Unblocked as its only MCP server used 42 percent fewer tokens than the same agent with no context server, searching the codebase on its own (the full numbers). That is one controlled run, not a population. Webflow connected Unblocked over MCP to the sandbox of Flower, its internal remote-agent platform, as described in their customer story. Russ Nealis, Staff Technical Product Manager at Webflow, told us: "To really make agentic development work at scale, you need context. You can spend a lot of time directing agents to go gather it for you — call one MCP to fetch the Jira ticket archaeology, another to dig through historical Slack conversations, a third to pull the PR history, then try to munge it all together. Unblocked just does that for us." Other vendors, such as Glean and Augment Code, ship servers in this category; the difference is whether they reconcile sources or only search them. The Glean comparison is in Glean MCP vs a context engine.

Which fix, and what stays on the laptop#

Count your servers by job. Servers that look things up (code, tickets, docs, chat) belong behind a context engine, because the value is the reconciled answer and not the raw result. Servers that do things (run a browser, query a database, open a pull request, page an on-call engineer) stay as tools. If that second list has ten or more entries and the security team wants shared auth and a call log, add a gateway in front of it.

Some servers should stay local on purpose. Claude Code's docs recommend local scope for personal development servers, experimental configurations, or servers with credentials you don't want in version control. The test is whether a teammate would want the same server with the same credentials. If not, keep it local.

A migration order that works#

  1. Inventory. Ask every engineer to run /mcp in Claude Code (or open their MCP settings in VS Code) and paste the list. Count the servers, the tools and the keys.
  2. Share the common set. Put the servers everyone needs into .mcp.json at the repo root, which Claude Code loads at project scope, or into .vscode/mcp.json for GitHub Copilot, which shares the servers with everyone who opens the project. Commit the file.
  3. Replace the lookup servers with one. Swap the GitHub, Jira, Confluence, Slack and Notion entries for a single context engine entry. The agent now makes one call for company context.
  4. Gate the action tools if you need to. If the tool servers that remain need shared credentials and an audit trail, put a gateway in front of them, with the inventory from step one as the allow-list.
  5. Enforce it. Claude Code lets administrators deploy a fixed server set with managed-mcp.json or provide servers to every user with managedMcpServers. GitHub Copilot Business and Enterprise have an organization policy that turns MCP on or off for members. Use those so the shared config cannot drift back into a pile of personal lists.

Most of the pain in the question goes away after step three, and those steps are configuration work rather than a platform project. Steps four and five matter when the security team also needs a governance layer.

Read More

MCP Gateway vs Context Engine: Which One Your Agents Need, and Why It's Usually Both
MCP Gateway vs Context Engine: Which One Your Agents Need, and Why It's Usually Both
A gateway governs how agents reach many MCP servers. A context engine changes what comes back. Most teams past a handful of servers end up wanting both.
Oct 23, 2026•Context Engine
A Pile of MCP Connectors Is Not a Context Engine
A Pile of MCP Connectors Is Not a Context Engine
MCP connectors give an agent access to your sources, one system at a time. Cross-source assembly, contradiction resolution, and unwritten conventions still need a context engine.
Jul 29, 2026•Context Engine

Related Answers

There is drift between our repos and our documentation and agents cannot tell. What handles this?
No single tool stops documentation drift, so handle it in three places. Catch it in the pull request by making doc owners review code changes. Detect old drift with scheduled checks that test docs against code. Then put a context engine between the agent and the docs, so answers weigh the docs against the current code and show the conflict.
Nov 3, 2026•Context Engine
How do I mark old Confluence pages as deprecated so AI stops using them?
Archive the pages nobody should read, since Confluence quick search and Glean's Confluence connector both skip archived content. For pages you still need, add a deprecated label and exclude that label in the AI tool's crawl or search query, and put a one-line warning with a link to the replacement at the top of the page. A page status on its own is a note for people, not a filter for AI.
Nov 3, 2026•Context Engine
MCP tools are eating the whole context window in Claude Code. How do other teams give agents company context?
Claude Code now defers MCP tool definitions by default, so a full window usually means tool search is switched off or raw tool results are piling up. Teams fix it in three moves: run /context to see which it is, push bulky lookups into subagents or CLI tools, and replace a stack of search servers with one context server that returns a short, cited answer.
Nov 3, 2026•Context Engine
We have context all over the place and constantly being generated. How do we organize it so AI pulls the right thing?
Don't move it. Leave context where people write it, add a few cheap links that tell a machine what is current and who owns it, and let a retrieval layer rank the sources each time the AI asks. A cleanup project goes stale the week it ships; the links and the ranking keep working as new context arrives.
Nov 3, 2026•Context Engine