Rate Limiting

Rate limiting caps how many requests a caller can make in an hour. It protects your upstream applications from a runaway agent, a retry loop, or an agent being used far more heavily than you planned for.

In the portal this is called Risk-based throttling, because the default limits are set by how risky an operation is.

Quick Start: What do you want to do?

I want to...	Go to
Cap everything on one MCP server	Limit an MCP server
Cap one specific tool	Limit a single tool
Cap what one agent can do	Limit an Agent Persona
Understand which limit applied	Persona and server limits both apply
See the built-in limits	Default limits
Know what a limited caller sees	What a limited caller gets

---

Where limits can be set

There are three places, and they do different jobs.

Set it on	What it caps	Granularity
An MCP server	Every call to that server	One number for the whole server, plus a limit per tool
A single tool	Calls to that one tool	One number per tool
An Agent Persona	Everything that persona does	One number for the whole persona

All limits are counted per user, per hour. Hour is the only window the portal offers.

Limit an MCP server

1. Open the server from the MCP Registry.
2. Select the Risk-based throttling tab.
3. Turn on Enforce Risk-based throttling.
4. Set Server Requests per Hour and select Save.
5. Re-deploy the server when prompted, so the change reaches the running gateway.

Turning the toggle off leaves the per-tool limits below it visible but inactive.

Default limits

When you enable throttling, every tool gets a starting limit based on the risk of its operation:

Risk	Operations	Default limit
Low	GET, HEAD, OPTIONS	1,000 requests per hour
Medium	POST, PUT, PATCH, DELETE	100 requests per hour
Critical	Anything else	10 requests per hour

Reads are cheap and usually safe, so they get the most headroom. Anything that writes is held to a tenth of that. The Critical tier catches operations the gateway cannot classify, and is deliberately strict.

Limit a single tool

On the same Risk-based throttling tab, the tools are listed in the middle, grouped by risk. Select one to open it on the right, then choose:

Option	Effect
Default	Use the limit for the tool's risk level, shown next to the option
Custom	Enter your own Maximum Requests per Hour
No Limit	Exempt this tool from throttling entirely

Each tool card shows its current limit, so you can scan the list for anything unusual.

Limit an Agent Persona

A persona has its own limit, independent of the servers behind it. This is the right control when you want to cap a particular agent rather than a particular application.

1. Open the persona from Agent Personas.
2. Go to Configuration → Policy → Risk-Based Throttling.
3. Turn on Enable rate limits.
4. Set Requests per Hour.
5. Select Save & deploy.

Turning the toggle on for the first time starts at 1,000 requests per hour. Turning it off keeps the number, so switching it off and on again does not lose your setting.

A persona has one limit for the whole persona. There is no per-tool control at the persona level — per-tool limits live on the MCP server.

Persona and server limits both apply

This is the part that most often causes confusion.

Persona limits and MCP server limits are separate counters. They do not override one another, and the more specific one does not win. When an agent calls a tool through a persona, the gateway checks the persona's limit and the server's limit, and either one can refuse the request.

So if a persona is capped at 500 requests per hour and the server behind it at 100, the agent gets 100 — the lower cap is reached first.

A persona with no limit of its own

If you have not set a limit on a persona, it does not go unlimited. It picks up the numbers configured on the MCP server behind it — but counts them in its own separate budget.

In practice, with two personas in front of one server limited to 100 requests per hour:

• each persona gets its own 100 per hour
• the server also enforces its own 100 per hour across both

The effect is that the server's own cap is what actually bounds total traffic, while each persona is additionally bounded on its own. If you want a persona to have a specific allowance, set it explicitly rather than relying on what it inherits.

Unauthenticated callers share one counter

Requests that arrive without an identity are all counted together as a single caller. One noisy anonymous client can therefore use up the allowance for all of them. This is a good reason to require authentication on anything that matters.

What a limited caller gets

A caller over the limit receives HTTP 429 (Too Many Requests), with a Retry-After header saying how many seconds to wait. The response says which limit was hit and what it is set to, so an agent can report something useful rather than just failing.

The window is a fixed hourly bucket, not a rolling one. A limit of 100 per hour means 100 requests within the clock hour; the count resets at the top of the next hour rather than gradually freeing up.

Every refusal is recorded with the reason rate_limit_exceeded. See Observability.

note

If the gateway cannot reach the service that stores the counters, requests are allowed through rather than refused. Rate limiting is there to protect your applications from overuse, not to act as a security boundary — it is deliberately not a way to deny access.

Token limits for AI providers

An LLM connection's Configuration → Safeguards → Cost section shows Rate and spend limits — tokens per minute, day and month, plus an allowed-models list. These are marked Coming soon and are not enforced yet.

To cap what agents spend on AI today, use Budgets and AI Spend, which works in dollars. The Response length cap on the same page is active, and bounds the cost of any single call by limiting how long an answer can be.

Circuit breaking

Circuit breaking protects your deployment when an upstream application stops responding. Rather than sending requests into a failing service and waiting for each to time out, the gateway stops forwarding to that backend for a while.

1. After repeated failures the circuit opens, and requests are refused immediately with a 503.
2. After a cooldown, the gateway tries one request.
3. If it succeeds the circuit closes and traffic resumes. If not, the cooldown starts again.

You will see requests failing faster than before, and audit events with the reason circuit_breaker_open. Repeated events usually mean an upstream service needs attention. Circuit breaking is automatic — there is nothing to configure.

Real-world examples

Protect a CRM from agent overuse

Tool	Limit
list_contacts	2,000 per hour
create_lead	50 per hour
delete_contact	5 per hour

The sales team can query freely, while anything that creates or removes records is tightly bounded.

Give automation more headroom than people

Set the limit on each persona rather than building duplicate MCP servers:

Persona	Requests per hour	Used by
Interactive Assistant	200	People working in Cursor or Claude Desktop
CI Release Bot	5,000	Pipelines running with an access key

Both can point at the same MCP server. Keep the server's own limit high enough to accommodate the busiest persona, since it applies on top.

What to ask your IT team

Ask for	Why you need it
Expected request volume per tool, per hour	The starting point for any limit that is not a guess
Any rate limits the upstream application enforces itself	Your limit should sit below theirs, or they will do the refusing
Peak periods, such as month-end	A limit sized for a normal day will fail on the busiest one

Tips

• Start with the defaults. They are reasonable for most workloads. Change them when you see a real problem.
• Watch before you tighten. Check activity for actual usage before setting a number — most first guesses are too low.
• Limit the persona for agent behaviour, the server for application protection. They answer different questions, which is why both exist.
• Remember both counters apply. If an agent is being refused at a number you did not configure, check the other one.
• Leave headroom for retries. A client that retries three times on failure consumes three requests.