Limits and quotas
Every limit that can end a CP-MCP request, in one place. Most of them only matter when you ask Claude for something broad — “audit every property”, “list every enrollment” — which is the case worth knowing about in advance.
The code_mode invocation
Section titled “The code_mode invocation”| Limit | Value | What happens when you hit it |
|---|---|---|
| Wall-clock budget | 20 seconds | The invocation is aborted with code_mode exceeded 20000ms wallclock budget. Work already done is lost |
| Code size | 20,000 characters | Rejected before execution with “code must be under 20,000 characters” |
| Single Cloudpath request | 15 seconds | That one call resolves with ok: false; the rest of the program keeps running |
The two timeouts compose badly on purpose: three slow Cloudpath calls in sequence can exhaust the 20-second budget on their own. A program that has to touch many resources should be split across several turns rather than looped inside one invocation.
Cloudpath’s own rate limits
Section titled “Cloudpath’s own rate limits”These are enforced by Cloudpath on cloud-hosted deployments, not by CP-MCP.
Exceeding them produces an error from Cloudpath, which reaches you as a normal
ok: false result with Cloudpath’s status.
| Limit | Value | Notes |
|---|---|---|
| API requests | 180 per minute, per tenant | Shared with everything else hitting that Cloudpath — other integrations count |
| Token mints | 10 per minute | CP-MCP caches tokens for up to 240 seconds, so a normal session mints once per surface every few minutes |
The mint cap is effectively unreachable through CP-MCP. The request cap is
reachable: a pagination loop over a large list can issue dozens of requests in
a few seconds. Prefer a server-side filter over fetching every page — see
Calling conventions.
Pagination
Section titled “Pagination”pageSize is chosen by Cloudpath, not by you, and tops out at 1,000
records per page. Read it back from the response envelope rather than
assuming a value.
Token cache
Section titled “Token cache”| Property | Value |
|---|---|
| Maximum cache lifetime | 240 seconds |
| Upstream JWT lifetime | ~5 minutes |
| Safety margin | 60 seconds before the upstream expiry |
Automatic retries on 401/406 | Exactly 1 |
The margin is why a cached token is never used within a minute of expiring, and the single retry is why a token that expires mid-request costs you one extra round trip rather than an error. See Security model.
generate_passphrase
Section titled “generate_passphrase”| Parameter | Range | Default |
|---|---|---|
count | 1–100 passphrases per call | 1 |
wordCount | 2–8 words | 3 |
separator | up to 3 characters | - |
Need more than 100? Call it again in the same program — it is a local computation with no upstream request, so repeated calls cost nothing but time. See Generating passphrases.
generate_image
Section titled “generate_image”Image dimensions are fixed per target and cannot be overridden.
| Target | Output | AI call |
|---|---|---|
tenant_logo, mgmt_logo | 1024×256 PNG | Yes — one Workers AI generation per call |
tenant_favicon, mgmt_favicon | 128×128 PNG | No |
Logo generation is the slowest thing CP-MCP does and the only part that bills AI compute, so it counts against the 20-second budget more than anything else. Generating a logo and a favicon and uploading both in one invocation is routine; generating a dozen logos in one is not. See Generating portal images.