How code mode works

Probe MCP’s tools/list returns exactly one tool: code_mode. Understanding what happens inside it explains most of the server’s behavior.

The approach

code_mode accepts a small program — the body of an async JavaScript function (plain JavaScript only; TypeScript syntax is a parse error). Inside it, a probe object provides functions that list your probes, read stored rollups, and reach live into the LAN. Claude writes the program, the engine runs it in a sandboxed V8 isolate on Cloudflare, and only the result comes back into the conversation.

The payoff: Claude can loop, filter, and join across many probe calls in one round trip, and only the answer — not thousands of intermediate rows — enters the context window.

See the Probe tools reference for the full probe.* catalog.

Stored vs. on-demand — the important split

Every probe.* function is one of two kinds, and the difference is what breaks when a probe goes offline:

• Stored functions read aggregates the engine already ingested — they work even if the probe is currently offline. These include list_probes, probe_status, list_devices, syslog_rollups, snmp_metrics, and top_talkers.
• On-demand functions reach live into the probe over its tunnel — SNMP gets/walks, live syslog search, topology, PoE, live packet connections, SSH, and so on. These require the probe to be Online; if it isn’t, they return a probe_offline result rather than data.

So “what did syslog look like yesterday?” works any time, but “walk this switch’s SNMP right now” needs the probe up.

The run budget

Each code_mode run has a 30-second wall-clock budget, and each on-demand tunnel call within it has its own timeout of about 10 seconds. If the run exceeds the budget it returns { error: 'timeout' }. A very broad request may come back in stages; asking for a narrower scope is usually faster than asking for everything at once.

Errors don’t throw

probe.* calls return structured results instead of throwing — a call that fails comes back with an error field (for example probe_offline or timeout) so the program can inspect it and adapt. If Claude reports a specific failure back to you, that’s why.

Your credentials never leave the server

The program runs on Cloudflare, not in Claude. When it reaches the probe, the engine applies your identity and the probe’s shared secret server-side. Claude sees the results; it never sees the probe’s secret. See the Security model.