**Okta Proposes Identity‑Scoped MCP Tool Lists as a Way to Cut AI Agent Token Costs**
Large language models are increasingly being used as autonomous “agents” that can call tools, query databases, and take actions on behalf of users. To support this, the Model Context Protocol (MCP)—originally developed by Anthropic—has gained traction as a standardized way for AI agents to discover and connect to tools and data sources. However, as Okta highlights in a recent post, every tool exposed by an MCP server is packaged into the prompt sent to the model on each turn, creating significant hidden costs and security risks. The company argues that identity‑scoped filtering of tool lists can meaningfully reduce these costs while improving security.
How MCP Tool Schemas Create Prompt Overhead on Every Turn
MCP servers expose a wide range of tools, from Slack and Google Workspace integrations to internal enterprise services. When an AI agent interacts with an MCP server, it receives a full representation of every available tool in its prompt for each turn. This representation includes the tool’s schema, name, description, and parameters.
While this enables flexibility, it also introduces “prompt overhead.” Even if an agent never uses most of the available tools, their schemas still consume tokens. According to Okta, this overhead occurs before any actual tool call is attempted. If a request is later rejected due to insufficient permissions, the tokens spent processing those unauthorized tool definitions cannot be recovered.
The problem is compounded when widely used MCP servers expose dozens or even hundreds of tools. Each active agent incurs this overhead every time it makes a model call. This creates both a scalability challenge—driven by tool count—and a security challenge—driven by access control.
Okta Filters Tools Before the Agent Prompt Is Built
In response, Okta proposes handling tool visibility at the identity level. The approach is part of the company’s broader “blueprint for the secure agentic enterprise,” which emphasizes identifying agents, their connections, and their authorized actions.
Instead of granting access to an entire MCP server and then filtering requests at runtime, Okta allows administrators to define which individual tools a particular agent or user identity can use. Using the Okta dashboard, admins configure a scoped tool set for each role or identity. When an agent is built, it receives only that limited list, and the system revalidates permissions before executing any tool call.
By removing unauthorized tools from the prompt entirely, Okta says both token consumption and attack surface are reduced. The agent never sees or processes schemas for tools it is not authorized to use.
Internal Modeling Shows Significant Tool‑Schema Cost Reductions
To validate the approach, Okta ran internal simulations using its own product data and public vendor documentation. It modeled a single MCP client with access to a catalog of enterprise tools and compared visibility before and after identity‑based scoping.
The company mapped MCP server tools to OAuth scopes that unlock them and defined representative user segments, including helpdesk read‑only users, helpdesk operators, app administrators, brand and email administrators, and super administrators. Each segment was weighted by its expected share of traffic.
Results showed that some permission scenarios reduced the number of visible tools by more than 90%. Because tool‑schema costs scale nearly linearly with tool count, Okta observed roughly proportional reductions in token overhead. However, the company notes that actual savings depend on factors such as tool catalog size, permission distribution, model choice, schema complexity, request volume, and pricing.
Identity‑Based Scoping vs. Gateway Spending Controls
Okta also contrasts its identity‑based approach with traditional API gateway controls, which can limit spending by key, team, or group and provide rate limiting or routing. Gateways are effective at capping token usage after decisions are made, but they do not prevent models from seeing or processing unnecessary tool schemas.
Identity entitlements offer a more preventative mechanism. Rather than applying coarse‑grained limits after the fact, Okta’s method uses the same entitlement data that governs security to determine which tools an agent can even consider. This aligns cost control with existing governance and reduces the risk of unauthorized actions.
Security Implications: Reducing Blast Radius Through Tool Visibility
Tool visibility is not just a cost issue—it also affects security. When agents can see tools beyond their authorization scope, a compromised identity could attempt actions it should not be able to perform. Runtime checks can block execution, but by that point the model has already consumed tokens processing the tool definition.
Okta’s two‑stage design filters tools at prompt construction time and again at execution time. This reduces the “blast radius” of a compromised identity by limiting the tools available to it in the first place. The methodology relies on mapping MCP server tools to OAuth scopes and comparing the full catalog against scoped catalogs for each user segment.
Frequently Asked Questions (FAQ)
What is the Model Context Protocol (MCP)?
MCP is a protocol that enables AI agents to discover and connect to tools and data sources. It allows servers to expose capabilities—such as accessing a calendar or sending a message—that AI agents can call within their prompts.
What is “tool tax” in this context?
“Tool tax” refers to the tokens consumed each time an AI model considers available tools, including schemas, names, descriptions, and parameters, even if the agent never actually uses those tools.
How does Okta reduce tool‑related token costs?
Okta filters the list of tools an agent can see based on identity‑based permissions before the prompt is built. By exposing only authorized tools, the model consumes fewer tokens on unused schemas.
Does Okta provide real‑world deployment data?
No. The company’s findings are based on internal modeling using its own product data and public vendor documentation. No customer data was used.
Is this approach limited to Okta’s ecosystem?
The concept is broadly applicable to any MCP implementation. However, Okta’s solution is integrated within its identity and access management platform.
Conclusion
As AI agents become more central to enterprise workflows, managing token costs and security risk associated with tool catalogs is essential. Okta’s identity‑scoped approach to MCP tool visibility offers a way to reduce prompt overhead by ensuring agents only see tools they are authorized to use. By filtering tool lists before prompts are constructed—and revalidating at execution time—organizations can lower token consumption, shrink attack surfaces, and align cost control with existing identity governance. While real‑world results will vary based on catalog complexity and tooling, the model highlights the growing role of identity in AI economics and security.
