Which tools a client registers and what judges the commands they run are two different controls.
A GitLab bug report puts the failure mode plainly: "MCP tools are injected into all foundational agents by default when the mcp_client feature flag is enabled, regardless of the agent's defined toolset." A "Data Analyst" agent scoped to a minimal toolset was unexpectedly handed unrelated tools—two of them carrying their own description's warning, "[UNTRUSTED SOURCE — READ BEFORE USING]." The reporter's expectation was simple: MCP (Model Context Protocol) tools should respect each agent's configured toolset. (GitLab issue #583935)
It isn't only GitLab's bug to fix. It's what happens by default when an MCP client registers a server's entire tool surface with every connecting agent, and tool exposure isn't treated as its own scoping decision. Every tool the client knows about is something a prompt injection can try to reach—whether or not the agent's task ever calls for it.
Tool overload isn't just a security problem
The same over-registration also makes agents worse at their job. Loaded with its full tool surface, GitHub's official MCP server burns roughly 42,000 tokens on tool definitions alone, by one practitioner's count—before a system prompt or a single line of task content. That write-up traces the consequence: an overloaded agent "misses obvious tool choices," "hallucinates parameters that don't exist," and "picks the wrong tool for simple tasks"—and tasks that ran fine with 10 registered tools fail once that number reaches 50. (dev.to, "MCP tool overload")
So the incentive to scope tool exposure isn't purely defensive. An agent that can see ten tools it might plausibly need reasons better than one holding a menu of fifty. Least privilege and better task performance point the same direction here.
Registering only what an agent needs
Selective tool registration is a concrete control now shipped by both GitHub's own MCP server (a documented --toolsets flag, not an experimental one) and alpacon-mcp local mode in v0.8.0 (2026-07-30). Instead of an AI client registering every tool the MCP server exposes, an operator chooses which groups of tools get registered with that client. Local mode then registers only the selected toolsets. A client that never sees a tool can't be induced to call it, by a prompt injection or by its own confusion over which of 50 tools to reach for.
Two layers, not one
MCP least privilege operates at two separate points in an agent's lifecycle: which tools a client registers with an agent, and what judges the host commands those registered tools go on to run. The first is a registration-time control—it fixes what the agent can even see, before a single command runs. The second is a runtime control—it fixes what happens each time a registered tool actually executes a host command. Scoping at registration is necessary, but it answers only the first question.
On the registration side, --toolsets is the concrete answer: an operator names which tool groups a client can even see, before that agent has issued a single command.
On the runtime side, the question is what happens when a tool the agent calls runs a command on a host. Where Alpacon's command judgment is enabled, that command goes through Alpacon's exec lane—a three-tier verification engine: rules (Tier 1, 40+ patterns), a baseline check (Tier 1.5), and LLM intent judgment on the grey zone (Tier 2, roughly the 0.3–0.8 risk band)—before it reaches the host, not when the tool was registered.
A registration-only deployment gets no verdict on the host commands its registered tools go on to run—there's nothing scoring them once they're called. A judgment-only deployment leaves the whole tool surface open to a prompt injection in the first place, because nothing narrowed what the agent could reach for. A command the exec lane scores in the grey zone can be held for out-of-band human approval before it runs. An MCP deployment with only one of these two controls still has a real gap; which gap depends on which one is missing.
That distinction matters because another over-trust failure surface was disclosed in the same ecosystem. In April 2026, OX Security disclosed an MCP STDIO flaw tied to unsanitized command execution and missing execution boundaries, with an estimated 200,000 vulnerable instances and roughly 7,000 confirmed reachable on public IPs. It's a different failure surface than tool over-registration, but it points to the same operational lesson: defaults can assume trust that production deployments cannot safely extend.
What should you check before wiring up an agent?
If you're connecting an agent to an MCP server today, the practical version of this argument comes down to two questions:
- Does the client register only the tools this agent's task actually needs, or the server's full surface by default?
- When a tool is about to run a command, is anything judging it before it runs—or is registration-time scoping the only control you have?
If the answer to the second question is "nothing," a well-scoped toolset is still doing real work—it's the only thing narrowing what the agent can reach for in the first place. Neither control substitutes for the other, though: the strongest setup runs both—a scoped toolset at registration, and command judgment at runtime.
