How code mode works

SZ-MCP gives Claude one MCP tool, code_mode. Claude writes a short TypeScript program, the Worker runs it in a sandboxed isolate with your credentials applied server-side, and the program’s return value becomes the answer. That is the whole mechanism.

Why one tool

SmartZone’s two OpenAPI specs define 1,354 operations — 1,116 on the WSG wireless API and 238 on SwitchM. Registering each as its own MCP tool would produce a tool list no model can choose from sensibly, and the definitions alone would consume most of the context window before any work started.

So the tool list stays at one entry. Its description carries the type signatures for two objects, and Claude composes calls against them instead of picking from a menu:

wifi — the SmartZone WSG (wireless) API
switches — the SmartZone SwitchM (switch) API

Both expose the same five primitives: list_tags, search_endpoints, list_endpoints_by_tag, get_endpoint_details and call. See the primitives reference.

What a run looks like

Claude passes the body of an async arrow function. A program can discover an endpoint and call it in one pass, keeping intermediate results in ordinary variables rather than round-tripping each step through the model:

async () => {
  const hits = await wifi.search_endpoints({ query: 'wlan' });
  const top = hits.results[0];
  const details = await wifi.get_endpoint_details({ method: top.method, path: top.path });
  return { top, requiredParams: details.parameters?.filter(p => p.required) };
}

Because this is real code, a loop over pages costs one MCP round trip rather than one per page — which matters, since the run is bounded by wall clock rather than by call count.

Where the code runs

The program executes in a dynamically loaded Worker isolate on Cloudflare, separate from the Worker handling your MCP request. It has no filesystem, no network access of its own, and no ambient credentials. The only things it can reach are the five primitives on the two namespaces.

Your SmartZone password never enters that isolate. Neither does the service ticket. When the program calls wifi.call(...), the request is handled by the parent Worker, which decrypts the password if it needs to mint a ticket, attaches the ticket to the upstream URL, and hands back only the response.

The diagram restates the boundary in the paragraph above: Claude reaches the isolate, the isolate reaches the parent Worker, and only the parent Worker touches the encrypted password or the service ticket. The response that travels back to Claude has the ticket redacted from its url field.

What comes back

code_mode returns the program’s return value, plus anything it logged:

{
  "result": { "status": 200, "count": 12 },
  "logs": []
}

If the program throws, or exceeds its budget, the tool result is flagged as an error and carries the message — for example code_mode error: code_mode exceeded 20000ms wallclock budget.

The two budgets

Budget	Value	What it bounds
`code_mode` wall clock	20 seconds	The whole program, across every call it makes
One upstream request	15 seconds	A single `call` to the controller
Program source	20,000 characters	Rejected before execution above this

A program that needs more than 20 seconds should return partial results and continue in a fresh run — each code_mode call gets its own budget. This is why unbounded pagination loops are a bad idea: see Limits and quotas.

Next steps

The two API surfaces What separates wifi from switches, and what each bundled index holds.

Finding the right endpoint The discovery path that works on these specs, and the schema fields that mislead.

Code mode primitives All five primitives, their arguments and their return shapes.

Examples Worked programs, including safe pagination.