Where tool scoping for AI agents actually belongs

Why does giving an agent fewer visible tools usually make it more accurate, not less capable?

Because tool selection is itself a reasoning task, and every additional tool description in a prompt is one more option the model has to correctly rule out. A model with three tools available rarely picks the wrong one. A model with three hundred tools available, most of them irrelevant to the current request, has to hold all three hundred descriptions in context and still land on the right one, and the failure mode is the selection problem getting harder, not the model getting dumber. Cutting the visible set down to what's relevant to the request removes the wrong options before the model has to reason its way past them, which is a narrower and easier problem than reasoning correctly despite them.

What happens to tool-selection accuracy as the number of available tools grows?

It falls sharply, and this is measured, not assumed. RAG-MCP, a framework that applies retrieval to tool selection instead of exposing every tool description directly, tested this on a stress benchmark for MCP, the Model Context Protocol that AI agents use to connect to tools, and found accuracy drop from over 90% with only a few tools available down to roughly 13.6% once the pool grew large. Retrieving just the relevant tool descriptions before the model reasons about them recovered accuracy to about 43.1% on the same stress test, more than tripling it, while cutting prompt tokens by over half. A separate paper, "ToolScope: Enhancing LLM Agent Tool Use through Tool Merging and Context-Aware Filtering," presented at ACL 2026, combined tool merging with context-aware filtering and reported gains of 8.4 to 38.6 percentage points in tool selection accuracy across three benchmarks and three frontier models. Two independent research groups, two different techniques, the same conclusion: the size of the visible toolset is a variable that directly determines accuracy, not a detail that washes out once the model is good enough.

Where does scoping happen in a real MCP deployment, then?

At three different layers, and they answer three different questions. An SDK session or template answers "which specific tools should this particular agent be allowed to call, right now." Identity-based access control, the layer Magic MCP runs on, answers "which integrations and actions is this specific person allowed to reach at all, across every agent they use." A Skill answers "which tools does this specific workflow need to run correctly." All three narrow something. None of them narrow the same thing, and an architecture built on the assumption that one layer does all three jobs is where these deployments break.

What does tool scoping look like at the SDK or session layer?

This is the layer built for engineers writing their own agents, and it's real, not aspirational: session templates in Metorial's API carry a tool_filters field, scoped per provider, per deployment, and per auth configuration, and the platform computes the effective tool set a given session exposes by applying those filters together. An engineer building a scoped agent, one that should only ever read a calendar and never send an email, for instance, sets that allow-list once at the session level, and every call through that session is bound by it. This is the layer where the accuracy research above applies most directly: an engineer deciding exactly which tools an agent needs for its job, and exposing nothing else, is the same intervention RAG-MCP and ToolScope both measured, done by hand instead of by retrieval.

Why doesn't Magic MCP do this same kind of per-request filtering?

Because it's solving a different problem, and forcing it to solve the SDK layer's problem would make it worse at its own job. Magic MCP is a single URL a person signs into once, and every call through it runs on that person's real identity rather than a shared service credential, reaching only the integrations and actions access control allows for that person, with every call logged. It's an access decision, made once at sign-in and enforced continuously, separate from any per-request decision about what gets crammed into a specific prompt. The major AI clients that speak MCP, Claude, Cursor, and others, already run their own progressive tool discovery on the client side, deciding what enters a given prompt's context from the tools available to them. A second, server-side filtering pass on top of that would add a network round trip to every call and risk invalidating the prompt cache the client already built, for a job the client is already doing. Access control decides what a person may reach. The client decides what enters context on a given call. Collapsing those into one layer doesn't make the system safer, it makes both jobs slower.

Isn't identity-based access control a weaker form of scoping than filtering the context window?

Weaker at a different thing, not weaker at its own thing. Filtering the context window is about accuracy: fewer irrelevant tools in front of the model, better tool selection, per the research above. Identity-based access control is about ceiling: what's reachable at all, regardless of how good the model's selection is. A perfectly accurate model that's still allowed to reach a payroll system it has no business touching hasn't been made safe by better tool selection. Magic MCP's own access model does allow per-agent limits on top of the identity layer, restricting which tools and actions a given agent may use, but that's a ceiling control, not a per-request context optimization, and a given claim about scoping needs to say which of the two it means.

What does a Skill scope, and what doesn't it?

A Skill attaches the specific integrations its workflow relies on, through one Magic MCP connection, so installing it gives an agent access to exactly those tools without anyone wiring up an integration by hand. It solves the setup problem: the workflow and the tools it needs travel together instead of being assembled separately. What it doesn't confirm is whether attaching a skill's specific tools reduces the total number of tools already visible to an agent that has broader Magic MCP access through other means. Asserting that without checking would be exactly the kind of unearned efficiency claim this post is built to avoid.

Which layer should an engineer build against?

Start with the SDK session layer if the job is building a scoped agent for a specific purpose, since tool_filters is the documented, per-request mechanism built for exactly that, and it's the layer the accuracy research above speaks to most directly. Reach for Magic MCP and access control when the question is which systems a person or team should be able to reach at all, independent of which specific agent they're using that day. Reach for a Skill when the goal is packaging a workflow so the people who'll run it don't have to assemble its tools themselves. Using one layer to try to do all three jobs is how "scoping" ends up meaning something different in every conversation about it.

What's the honest limitation across all three?

None of them are a substitute for the others, and none of them is complete on its own. A tightly scoped SDK session still runs behind whatever a person is allowed to reach at the identity layer. A well-governed identity layer still benefits from a smaller, better-chosen tool set at the session level, for the accuracy reasons the research above measured. And a Skill's convenience in attaching tools says nothing about whether the agent using it is otherwise over-permissioned elsewhere. Treating any one of the three as the whole answer is the failure mode, not a shortcoming of any single layer.

FAQ

Is tool scoping mainly a security feature or a performance feature?

Both, at different layers. At the SDK session layer, scoping is primarily about accuracy, per the RAG-MCP and ToolScope research cited above. At the identity and access-control layer, it's primarily about ceiling: what's reachable at all. Conflating the two is the most common mistake in how teams talk about this.

Does Magic MCP filter which tools appear in a model's context on a given call?

No, and it isn't designed to. Magic MCP enforces identity-based access control, deciding what a person and their agents can reach at all. Deciding what enters a specific prompt's context is left to the AI client, which already runs its own progressive tool discovery.

Does installing a Skill reduce the number of tools an agent can see?

It attaches the specific tools that skill's workflow needs, confirmed on Metorial's own product page. Whether that narrows the total toolset already visible to an agent through other access it holds isn't something this post can confirm, and it isn't claimed here.

Is the SDK-level tool_filters feature shipped, or planned?

Shipped. It's a documented field in Metorial's own API, scoped per provider, deployment, and auth configuration, and the platform computes a session's effective tool set from those filters directly.

Does adding more tools to an agent always hurt performance?

Not inherently, but unfiltered growth in visible tools does measurably hurt tool-selection accuracy, per both cited studies. The fix is retrieving or filtering down to the relevant subset before the model has to choose among them, not fewer integrations available in principle.

Sources

1. "RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation," arXiv:2505.03275 (checked 2026-09-08)
2. Liu et al., "ToolScope: Enhancing LLM Agent Tool Use through Tool Merging and Context-Aware Filtering," Proceedings of ACL 2026 (checked 2026-09-08)
3. Metorial, Magic MCP product page (checked 2026-09-08)
4. Metorial, Skills product page (checked 2026-09-08)