Traffic limits control how many calls an MCP server accepts. Use them to prevent excessive traffic from affecting other users or the systems behind your MCP Tools.
Traffic limits are configured for each MCP server under Access > Governance. All limits are optional. If you don't configure a limit, traffic for that limit remains unrestricted.
Important: Traffic limits are available only for accounts using the multi-environment structure. Only account owners and administrators can configure them.
When to use traffic limits
Consider configuring traffic limits when:
- Multiple users or agents share an MCP server and you want to prevent one end user from consuming excessive capacity.
- MCP tools call applications that have their own API or usage limits.
- You want to control the total number of calls an MCP server accepts.
- You're introducing a new agent and want to control its traffic while determining its normal usage pattern.
Traffic limits don't determine who can access an MCP server or which capabilities they can use. Authentication and end-user access control who can connect, while capability assignments control what they can use. Traffic limits control how many calls they can make.
Understand the traffic limits
You can configure three types of limits:
| Limit | What it controls | Applies to |
| Server rate limit | Total calls the MCP server accepts within a specified time period | All users and authentication methods |
| User rate limit | Calls each end user can make within a specified time period | End users authenticated with OAuth |
| Usage quota | Total calls the MCP server accepts during a calendar period | All users and authentication methods |
The Server rate limit and User rate limit support Minute, Hour, and Day.
The Usage quota supports Day, Week, and Month.
How rate limits and quotas work
Rate limits use a continuously refilling allowance rather than resetting at the beginning of each minute, hour, or day.
For example, a Server rate limit of 600 calls per minute allows an initial burst of up to 600 calls. As calls consume that allowance, it refills at an average rate of approximately 10 calls per second.
A Usage quota works differently. It counts accepted calls during a fixed calendar period in Coordinated Universal Time (UTC):
- Day resets at 00:00 UTC.
- Week resets Monday at 00:00 UTC.
- Month resets on the first day of the month at 00:00 UTC.
If you change a quota during the current period, the calls already counted aren't reset.
How traffic limits work together
Each configured limit is enforced independently, and a call must stay within every limit that applies to it.
For example, consider an MCP server configured with:
- Server rate limit: 600 calls per minute
- User rate limit: 60 calls per minute
- Usage quota: 500,000 calls per month
If one end user exceeds 60 calls per minute, only that user is restricted. If all users together exceed the server rate limit, additional calls are restricted even if individual users remain below their own limits. When the monthly usage quota is reached, calls from all users are rejected until the quota resets.
Calls that count
A call counts when the MCP server accepts it and passes it to a capability. If the capability later fails, the call still counts.
Calls rejected by a traffic limit don't invoke the capability and don't count toward usage.
The following don't count:
- Discovery requests, such as initializing a session or listing capabilities
- Requests that fail authentication
- Test server previews
How authentication affects the user rate limit
The User rate limit applies only when an end user authenticates to the MCP server with OAuth.
| Authentication | Server rate limit | User rate limit | Usage quota |
| OAuth end user | Applies | Applies per end user | Applies |
| API token | Applies | Doesn't apply | Applies |
| Personal access token (PAT) | Applies | Doesn't apply | Applies |
API tokens don't identify an individual end user, and PATs identify workspace users rather than end users. Therefore, this traffic counts only toward server-level limits.
When a traffic limit is reached
When a call exceeds an applicable traffic limit, the MCP server rejects it with an HTTP 429 response. The response identifies the limit that was reached, and the Retry-After header indicates how long the client should wait before retrying.
Traffic limits apply only to new calls. Tool calls already running continue to completion.
A User rate limit affects only the end user who reached the limit. A Server rate limit or Usage quota can affect all users.
Celigo records restrict calls in the MCP server request logs with the consumer identity and the limit that was reached.
Platform maximums
Celigo applies a platform level maximum to MCP server traffic. When configuring a limit, you can't enter a value above the maximum allowed for the selected time unit. If the value is too high, Celigo displays the allowed range.
Pair a usage quota with a rate limit
A Usage quota limits total consumption but doesn't control how quickly the quota is used. A sudden burst of traffic could consume a large portion of the quota.
Consider using a Server rate limit with a Usage quota to control how quickly the quota is consumed. You can also configure a User rate limit to prevent a single end user from using too much of the available capacity.
Traffic limits and MCP proxies
If your MCP server proxies an external MCP server, Celigo traffic limits apply to calls passing through the Celigo MCP server.
The external MCP server can also enforce its own traffic limits. Those limits operate independently of the limits configured in Celigo. See Monitor requests that exceed MCP server traffic limits to learn how proxy calls that exceed rate limits appear in your request logs.
Configure traffic limits for an MCP server
Set traffic limits to control how many calls an MCP server accepts. You can configure a Server rate limit, User rate limit, or Usage quota. All limits are optional.
For details about what each limit controls and how the limits work together, see MCP server traffic limits overview.
Prerequisites
- You must be an account owner or administrator.
- Your account must use the multi-environment structure.
Set a traffic limit
- Go to AI studio > MCP servers, and select the server.
- Select the Access tab, and then select Governance.
- For each limit you want to configure, enter the maximum number of calls and select a time unit. To leave a limit unenforced, leave that field blank.
- Server rate limit: Limits total calls across all consumers and authentication methods. Select Minute, Hour, or Day.
- User rate limit: Limits calls for each end user authenticated with OAuth. Select Minute, Hour, or Day.
- Usage quota: Limits total calls across all consumers. Select Day, Week, or Month.
- Select Save.
If the value exceeds the maximum limit for the selected time unit, Celigo displays the allowed range.
Changes take effect shortly after you save.
Tip: When you configure a Usage quota, consider also configuring a Server rate limit to prevent a traffic burst from consuming the quota too quickly.
Change or remove a traffic limit
- Go to AI studio > MCP servers, and select the server.
- Select Access > Governance.
- Enter a new value to change the limit. To remove the limit, clear its value.
- Select Save.
If you change a usage quota during its current period, Celigo applies the new limit to the usage already counted for that period.
Celigo records each configuration, change, and removal of a traffic limit in the platform audit log.
Choose starting values
If you're unsure what limits to configure, use your existing MCP server traffic as a starting point.
- Open the MCP server's request logs and review its busiest periods.
- Set the Server rate limit high enough to accommodate normal traffic peaks while restricting unexpected bursts.
- If end users authenticate with OAuth, set the User rate limit based on the traffic you expect from an individual user or agent.
- Set the Usage quota based on the total consumption you want to allow over a day, week, or month.
- Monitor the request logs and adjust the limits as your usage patterns change.
Start conservatively when introducing a new agent or workload, and adjust the limits after observing its normal traffic.
Monitor requests that exceed MCP server traffic limits
When an MCP server rejects a call because it exceeds a traffic limit, Celigo records the rejection in the server's request logs. Use the logs to identify which limit was reached, which consumer triggered it, and whether the traffic limit or consumer behavior needs to change.
For details about how traffic limits work, see MCP server traffic limits overview.
Prerequisites
- You are an account owner or administrator, or you have the Manage or Monitor role on the integration that contains the MCP server.
View requests that exceed traffic limits
- Go to AI Studio > MCP servers.
- Select Actions (…) next to the MCP server, and then select View request logs.
- Look for calls that return an HTTP 429 response.
- Select a call to view its request and response details.
The request log identifies the consumer and the traffic limit that rejected the call.
What the client sees
When a traffic limit is reached, the MCP server returns an HTTP 429 response identifying the limit that was reached.
The retry after header in the user interface indicates how long the client should wait before retrying.
For a rate limit, the wait might be brief because the available allowance continuously refills. For a usage quota, the client might need to wait until the current calendar period ends.
Tool calls already in progress continue to completion.
Respond to a request that exceeds a traffic limit
If you're an end user and your MCP client reports that a request exceeded a traffic limit:
- Check the retry after value in the response to see how long to wait.
- Wait for the specified time before retrying.
- Retry the request from your MCP client.
- If your requests continue to exceed the limit, contact your MCP server administrator.
Don't repeatedly retry the request before the specified time. Requests that continue to exceed the limit are rejected again.
If the MCP server's Usage quota has been reached, you might need to wait until the quota resets or ask your administrator to review the configured limit.
Troubleshoot repeated traffic-limit errors
If an agent or user repeatedly exceeds a traffic limit, check the following:
- Identify the limit: Determine whether the request reached the User rate limit, Server rate limit, or Usage quota.
- Identify the consumer: Review the consumer information in the request log to determine where the traffic originated.
- Check for repeated retries: A stream of repeated calls can indicate that an agent is retrying without waiting for the Retry-After period.
- Review the configured limit: If legitimate traffic is repeatedly rejected, consider adjusting the applicable limit.
- Check the usage quota: If the quota has been exhausted, increase or remove it if you need to restore access before the current period ends.
If a usage quota is being consumed too quickly, consider configuring a Server rate limit to control traffic bursts.
Rate limits from an external MCP server
If your MCP server proxies an external MCP server, the external server might enforce its own traffic limits.
External rate-limit failures are independent of the traffic limits configured in Celigo. They appear as failed calls in the request logs but aren't treated as Celigo traffic-limit rejections and don't use Celigo's retry after behavior.
See Troubleshoot an MCP proxy for more information.