There's a standard response in any AI team when an agent isn't performing well enough: add more tools. The agent can't find recent customer data? Add a CRM tool. It can't check deployment status? Add a CI/CD tool. It doesn't know about recent incidents? Add a monitoring integration.
This instinct is understandable and usually wrong.
The problem most AI teams hit within six months of serious MCP adoption is not that their agents lack tools. It's that nobody knows what tools exist, who approved them, which agents have access to them, or what they've actually been doing.
More tools into a system without governance doesn't make the system more capable. It makes it more unpredictable.
The Tool Sprawl Timeline
Here's how it goes in almost every organisation.
Month 1: One team builds an agent. They connect it to three MCP servers: Slack, their internal knowledge base, and a read-only database query tool. Works great. The team is delighted.
Month 3: Two more teams start building agents. They each set up their own MCP server connections. Some duplicate what the first team built — they didn't know it already existed. Some connect to new tools. There's no central inventory, so nobody knows this is happening.
Month 6: Five teams are running agents. There are now 23 MCP server connections across the organisation. Six of them connect to the same Slack workspace through different credentials. Three of them have production database write access that was added "temporarily" four months ago. One of them belongs to a project that was cancelled but the credentials were never revoked.
Month 9: An agent does something unexpected. The investigation reveals it had tool access nobody realised it had, inherited from a shared config file that three different teams were writing to. The post-mortem action item is "document the MCP tool inventory." The document is outdated within two weeks.
This is not a hypothetical. It's the normal trajectory of MCP adoption in any organisation that treats tool connections as application-level configuration rather than infrastructure.
Why "More Tools" Makes Agents Worse, Not Better
There's a specific mechanism by which tool sprawl actively degrades agent performance, separate from the security and governance issues.
When an LLM is given a large list of available tools, it uses context window space to process them. A tool list of 50 tools is substantially larger in tokens than a tool list of 8 tools. More importantly, a large tool list introduces ambiguity: the model has to reason about which of many available tools is appropriate for a given task, and with more options, the reasoning quality on tool selection tends to decrease.
The principle of least privilege isn't just a security principle for AI agents. It's also a performance principle. An agent that can only see the 6 tools it legitimately needs will select and use them more reliably than an agent that sees 40 tools and has to figure out which 6 are relevant.
This is one of the counterintuitive findings of production agent deployments: reducing the tool surface area available to an agent — scoping it tightly to what it actually needs — consistently improves task completion rates alongside reducing security risk.
What the Fix Actually Looks Like
The core shift is treating MCP tool access as infrastructure policy rather than application configuration.
In application configuration, tool access is defined in code. Every agent specifies its own tool list. Changes require code changes and deployments. There's no single place to see the full inventory.
In infrastructure policy, tool access is defined in a central registry. Each tool is registered once, with a description, an owner, and an access policy that defines which roles can use it. Agents request access based on their role. The registry enforces the policy. Changes to access policies take effect immediately across all agents without any code changes.
This shift has four immediate effects:
Visibility: The registry is the single source of truth for what MCP tools exist in your organisation. Any team can see what's available. No more duplication because nobody knew a tool already existed.
Accountability: Every tool has an owner. When a tool behaves unexpectedly, there's a clear path to the person responsible for it.
Auditability: Every tool call is logged with the identity of the agent and the user on whose behalf it acted. Compliance questions have answers.
Predictability: Agents only see the tools they're meant to use. Their behaviour is more predictable because their action space is intentionally constrained.
This Is a Platform Problem, Not a Team Problem
The reason tool sprawl happens isn't that teams are careless. It's that the default state of MCP deployment gives teams no infrastructure to do this well. There's no built-in registry. There's no built-in access policy system. Teams solve the problem the way engineers always solve problems in the absence of infrastructure: in code, inconsistently, and just well enough to ship.
The solution isn't to ask teams to be more disciplined about documentation and credential management. The solution is to give them infrastructure where discipline is the default rather than the exception.
TrueFoundry's MCP Gateway provides exactly this infrastructure layer. Its centralised MCP server registry lets teams register tools once, define access policies at registration, and make tools discoverable to authorised agents automatically — without per-team configuration work. Approval workflows ensure new MCP servers go through a review process before they're accessible to any agent. The registry spans cloud, on-premises, and hybrid deployments, visible in one view. And because TrueFoundry runs in your own infrastructure, the tool inventory never leaves your environment.
Teams using TrueFoundry's MCP Gateway consistently find two things: their agents perform better when tool access is scoped correctly, and their platform team spends significantly less time managing tool credentials and access policies manually.
More tools, managed badly, makes agents worse. Fewer tools, managed well, makes them significantly better.
Explore TrueFoundry's MCP Gateway →
Explore TrueFoundry's AI Gateway →
Explore TrueFoundry's Agentic Gateway →
Top comments (0)