How code mode works

CP-MCP publishes exactly one MCP tool, code_mode. Claude passes it the body of an async arrow function; the Worker runs that code in a sandboxed V8 isolate, and the value the function returns becomes the MCP response.

Why one tool

Cloudpath’s REST API spans three surfaces and 175 operations in the indexed spec. Registering each as its own MCP tool would overwhelm Claude’s tool list and waste context on metadata the model rarely needs. Instead, the single code_mode tool gives Claude three namespaced objects it drives from code:

• core — Cloudpath Core API (admin)
• tenant — Tenant Portal API
• property — Property Management API

Because the code runs in an isolate, Claude can plan, search, loop, and post-process across many calls without a tool-call round-trip per step. See The three API surfaces for what each object reaches.

The six primitives

Each of the three objects exposes the same six primitives:

Primitive	What it does
list_tag_groups	The tag groups the surface’s index defines
list_tags	Endpoint categories, optionally scoped to a group, each with an operation count
search_endpoints	Keyword search over the spec index, ranked by relevance
list_endpoints_by_tag	Enumerate operations under a known tag
get_endpoint_details	Full parameters, request body, and response schema for one operation
call	Execute an authenticated call against an endpoint on that surface

core carries two extra utilities on top of these six: generate_passphrase and generate_image.

Note

The Cloudpath REST API User Guide has no group hierarchy above its endpoint categories, so the extracted index gives each surface a single tag group named All. list_tag_groups is therefore a thin call — list_tags and search_endpoints are the useful places to start.

The workflow

A typical code_mode program follows the same shape you would with the docs open:

1. Orient with core.list_tag_groups() / core.list_tags() (or the tenant / property equivalents) when you don’t know where to look.
2. Discover with search_endpoints({ query, tag?, method? }) or list_endpoints_by_tag({ tag }).
3. Inspect with get_endpoint_details({ method, path }) when you need the property table or examples.
4. Execute with call({ method, path, pathParams?, query?, body? }). For the property surface, also pass propertyMgmtPortalGuid.

Search results usually carry enough detail that Claude calls call directly without a separate get_endpoint_details fetch.

Where the index comes from

Cloudpath publishes no OpenAPI document — the REST API is specified only in the Cloudpath Enrollment System REST API User Guide for release 6.0. CP-MCP extracts that PDF once and ships the result in two pieces:

Piece	Where it lives	Used by
Slim index — method, path, tags, summary, parameter hints, return codes	Bundled into the Worker	list_tag_groups, list_tags, search_endpoints, list_endpoints_by_tag
Full spec — per-endpoint property tables and descriptions	Object storage (Cloudflare R2)	get_endpoint_details

The slim index runs in memory with no I/O. The full spec is lazy-loaded the first time get_endpoint_details needs it in a given isolate, which adds a few hundred milliseconds to that one call and nothing afterwards.

Because the index is extracted from a release-pinned document, it describes Cloudpath 6.0. An endpoint your deployment has but the guide doesn’t will not appear in search_endpoints — you can still call it by path.

Limits

• The code you pass must be under 20,000 characters.
• Each code_mode invocation has a 20-second wall-clock budget; a program that exceeds it is aborted.
• Each individual Cloudpath request inside it times out after 15 seconds.

See Limits and quotas for the full set, including Cloudpath’s own rate limits.

Next steps

The three API surfaces What core, tenant, and property each reach, and how big each one is.

Calling conventions Return shape, pagination, filtering, and how errors surface.

Limits and quotas Every timeout, size cap, and rate limit in one place.

Examples What a good request looks like when Claude is writing the program.