Cap tool call volume
Keep a looping agent from exhausting an MCP server's quota, with call budgets per server, per tool or per user
A looping agent can keep calling a paid API behind an MCP server until it exceeds the server's quota or uses capacity other people need. A Usage Limits rule caps how many tool calls reach a server, a tool, or each person, in a window of up to an hour.
Protect one server's quota
Scope the rule to the server, and give it a budget under the server's own quota:
- On Controls › Usage Limits, create a rule.
- In the scope, pick the MCP server, or a label that several servers carry.
- Set the calls per window, such as 600 calls per minute.
The whole organization shares that budget by default.
To give each person their own, split the budget by user.
Budget each tool or each server separately
One rule can give every server or every tool its own budget, without a rule per server:
| Split the budget by | Each one gets its own budget |
|---|---|
mcp | each MCP server |
tool | each tool |
user | each person |
agent_instance | each connected agent |
Splitting by user and tool gives each person their own budget on each tool, so one person exhausting search doesn't touch their summarize budget or anyone else's.
To limit one expensive tool more tightly, scope a second rule to that tool's name or label.
Every rule that matches a call must have budget left, so the tight rule and the broad one both apply.
What counts against a budget
Only a call the gateway forwards to the MCP server counts.
- A call an access rule denies costs nothing.
- A call to a server the person hasn't connected yet costs nothing, so they get the link to connect rather than a limit error.
- Listing tools and connecting are never limited.
What the agent sees
A refused call comes back as a failed tool result the agent can read and back off from:
Rate limit exceeded for "search". Retry in 4s.Agent Trail records it as a rate_limited tool error naming the rule.
When the MCP server throttles a call itself, Agent Trail records upstream_rate_limited instead.
Frequent upstream_rate_limited errors mean your agents are hitting the server's own quota:
add a rule that keeps them under it.
Test a limit first
Set the rule's action to log_only, and it records the calls it would refuse without refusing them.
They appear in Agent Trail with a logged, not blocked badge, so you can tune the number before you enforce it.
Next steps
Your MCP servers now have a ceiling that a looping agent can't push past. Next, check that the limit fits real traffic before you enforce it.
- Usage Limits – conditions, burst, and organization-wide defaults
- MCP usage analytics – see which tools and servers get the most calls