Every AI agent call ships a tool list to the model. Okta is turning the list itself into a security gate.

MCP (Model Context Protocol) is the connector layer that lets an AI agent reach Google Workspace, Slack, internal databases, or any other tool the agent has been wired to. On every model call, the agent's prompt includes a description of every available tool: its name, what it does, and the parameters it accepts. The list can run into the hundreds. Each entry has to be paid for, in tokens, on every turn, for every active user. That overhead is the structural feature of how agent systems are being built, and it has grown large enough to show up on a finance team's invoice.

Okta's open-source MCP server now ships a control point at that step. The June 3, 2026 release notes added scope-based tool loading: instead of a single agent identity seeing every tool the server exposes, an administrator can pin a specific agent identity to a specific list of tools. The model never sees the ones it was never going to use, and the prompt never has to pay for them. Okta also added Customization tools and Device Assurance Policy tools in the same release.

The headline number, reported by Artificial Intelligence News, is that some permission scenarios cut the number of visible tools by "more than 90%", with tool-schema costs falling by "roughly the same proportion." That figure comes from Okta's internal modelling. Okta has not published an absolute token count, a dollar figure, or a baseline, so the 90% should be read as a vendor claim about the order of magnitude, not as a measured result.

The zhang-liz/mcp-token-benchmark on GitHub, a Maxim AI write-up on cutting MCP token costs at 500 tools, and a Future AGI analysis on reducing Claude Code token costs all report reductions in the 90 to 95% range from similar prompt-assembly redesigns. None of those measurements re-tests Okta's specific control, but together they describe a stable cost pattern across different vendors and different agent frameworks.

The control is a cost feature only at the surface. The deeper move is that Okta is turning the prompt-assembly step into an access-control primitive. An agent that sees a tool it cannot legally use is a security surface, because a model can be steered toward a tool simply by seeing its description. A rejection at runtime, after the model has already considered the tool and spent tokens thinking about whether to call it, cannot recover the prompt tokens already spent, and the rejection itself becomes a tax on the response. Filtering at the prompt-assembly step is the only point where the cost and the security boundary can be enforced together.

That reframing matters because Okta is currently the only major vendor naming this control point. The Okta blueprint for the secure agentic enterprise treats MCP scoping as part of an identity-driven security story, not a token-optimization story. The two framings are not in conflict. The pre-prompt filter does both jobs. But the security framing is the one that turns a vendor optimization into a category pattern, and it is the framing competitors are most likely to copy or contest.

The test for whether this is a category shift or a one-vendor optimization is a model-side fix. If a frontier model learns to ignore unauthorized tools from its own weights, or if runtime rejection becomes cheap enough that the prompt tax no longer matters, the pre-prompt filter loses its cost case. The access-control case survives that test: a model that simply does not see a tool cannot be steered toward it, regardless of how cheap reasoning becomes. Okta's bet is that the security case is the durable one, and that the cost case rides along for free.

Watch the next round of MCP server releases from competitors for whether scope-based tool loading shows up as a default, and watch the Okta and MCP maintainer channels for absolute token or dollar disclosures. Until those numbers land, the 90% headline is a vendor-claimed ceiling, not a measured floor.