Over the past year or more, various agent products—especially desktop and coding ones—have all been doing the same thing: integrating more tools. The protocols they support are increasingly complete, the services they can connect to are increasingly numerous, and their capability lists are increasingly long. On many product pages, "how many kinds of tools are supported" has been written out as a sign of maturity.
But in actual use, the experience is often the opposite. For a question that could have been clarified in a single sentence, the agent first has to pick through a long list of tools, decide which one to use and how to chain them, and then call them step by step; if any step goes wrong along the way, the final answer becomes muddled and off the mark. By contrast, asking a large model directly in the chat box yields an answer that is faster and more accurate.
This is not a flaw of individual products, but a common affliction of this class of systems.
The Race of Capability Lists
Behind the competition over the number of tools is a seemingly reasonable logic: the more capabilities, the broader the scenarios that can be covered. Thus "ecosystem" became the yardstick for measuring maturity—how many services are connected, how many plugins are supported, how many data sources can be linked, all became promotional talking points.
The problem is that the length of the capability list and its actual usage rate are not closely related. When a feature is included in the list, it means it has to participate in judgment every time; but the vast majority of capabilities will not be used in the vast majority of tasks. In systems with longer lists, the few items actually used frequently are more likely to be drowned out.
The More Tools, the Harder the Choice
From the agent's perspective, the reason is actually quite direct.
Every tool must first write its name, purpose, and parameters into the model's workspace before the model can know "there is such a tool." The more tools there are, the more space these descriptions occupy—and that space is the same budget the model uses to understand your sentence, remember the preceding context, and reason through the task.
When the budget is taken up, the consequences are predictable: the model has to make judgments among a pile of plausible-looking options, making it easy to pick wrong, easy to miss your original requirements, and more likely to go back and forth on intermediate steps. The longer the task chain, the more errors compound. Something that could be done in three steps may, because of one wrong choice, veer off course from then on.
The industry has given this phenomenon a name: "context rot." Public discussion around it has continued from the end of last year to today and is no longer an internal topic within the tech circle—it points to a product judgment: more capabilities is not always better; beyond a certain scale, the interference brought by newly added tools may outweigh the convenience they bring.
What Enterprises Want Is Not a Toolbox, but Scenario Solutions
Back at the actual workplace, the conclusion becomes clearer.
Most work in enterprises is repetitive and well-defined: writing a piece of product copy, putting together a weekly report, looking up a customer's history, turning a set of data into a chart. These tasks do not require the agent to "think about which tool to use"—what they need is to put the tools away, keep only the few necessary ones, and then provide a preset, clean workflow.
The toolbox approach does the opposite: it lays out all the tools and lets users pick for themselves. To skilled people, this seems like flexibility; to the vast majority who need to get work done, it is noise. The more tools, the greater the noise, and the less people know where to start.
Handing All the Choice to Users Is Not the Same as Flexibility
A truly useful tool should be like an experienced driver driving a car—fast when it should be fast, turning when it should turn, without having to study every button in the car before every departure.
Many products today throw the entire decision of "which tool to use" to the user and call it flexibility. But what users want has never been the choice itself, but to get things done. When the choice is thrown back, users get an extra burden, not more capability.
So the issue of "noise" is, in the end, a design problem: the scenario encapsulation that should have been done was not done, and the narrowing down that the product should have completed for the user has been shifted onto the user.
Our Own Approach
HOLYPro builds enterprise digital platforms and also provides MCP tools and open APIs externally. We are well aware of how easily this set of capabilities can be stretched into a long list, so we have drawn a few lines for ourselves on this matter:
- The foundation should be complete; delivery should be contained. Data models, APIs, and permission management are all fully provided on the platform, so capabilities are not lacking; but when delivered to a specific role or specific task, only the few tools needed for that one thing are given.
- Combine by scenario, not list by capability. High-frequency work such as content production, data queries, and customer follow-up each corresponds to a defined pathway, ready to use when opened, without having to learn how to use it first.
- Separate read-only from write access, and assign permissions by person. What can be viewed and what can be changed are not mixed together, which both reduces the cost of judgment and lowers the risk of misoperation.
- Keep the number of tools restrained. For every capability added, first ask whether it can be folded into an existing scenario; if it cannot, it is better not to add it.
This idea is not new; it simply makes one thing clear: enterprises do not need an assistant that can do everything, but an assistant that can get the task at hand done cleanly.
Final Words
The best form of technology is when people cannot feel its presence. Users do not need to know how many tools are connected behind the scenes or how many steps are chained; they only need to get the job done.
This is especially true for enterprise services. Less is more, and scenario is king—this is not a slogan, but a principle that must be built into the product structure.