Probe — on-LAN ground truth

The Probe feature lets Claude check what RUCKUS One believes against what is actually on your LAN. R1 tells you a controller’s view; a probe on the wire tells you whether that view is true.

This is an Early Access feature: unlock Early Access, then turn it on in the Early Access card of the dashboard. Its toggles appear once the password is accepted; the Features card holds only the generally available features.

You connect one connector, not two

You add only R1-MCP to Claude. R1-MCP calls Probe MCP itself, machine to machine over a private binding — there is no second connector to install.

What you do need is a one-time consent link on the Probe MCP side, which is what authorizes R1-MCP to drive your probes on your behalf.

Claude issues probe_call to R1-MCP; R1-MCP forwards it to Probe MCP over the private binding, signing an identity assertion for your account; Probe MCP resolves that against its own consent table and queries your LAN. Until you complete the consent link, that resolution fails and the call returns not_linked with a link_url — open it once in a browser and it stops happening.

Once the feature is on, the dashboard also shows a Probe connection card. It reads “Connected to probe-mcp as …” when you’re linked, or offers a Connect probe-mcp button that opens the same consent page — the easiest way to do the one-time link.

probe_link_status reports the current state: { linked: true, email } when connected, { linked: false, link_url } when not. Call it first when a probe call comes back not_linked, or before starting a probe-backed workflow.

The four R1-MCP tools

Tool	What it does
`probe_link_status`	Whether your account is connected to Probe MCP, and the link URL if not
`probe_describe`	The probe tools available, with a JSON Schema for each
`probe_call`	Invoke one read-only probe tool
`probe_reconcile`	The cloud-versus-LAN divergence sweep (see below)

Schemas live on the probe side and can gain fields between deploys, so probe_describe is fetched before composing probe_call arguments rather than assumed. It works before your account is linked — schemas only, no data.

What `probe_call` can reach

The exposed surface is read-only and deliberately narrower than what Probe MCP itself can do:

Group	Tools
Inventory	`list_probes`, `probe_status`, `list_devices`, `inventory`, `reconcile_inventory`
Onboarding	`auth_sessions` — real 802.1X / RADIUS / DHCP outcomes seen on the wire
Switch ports	`poe_status`, `port_diag`
Topology	`topology` — live LLDP and association data
Logs	`query_syslog`, `search_syslog`, `syslog_rollups`
SNMP	`snmp_get`, `snmp_walk`, `snmp_metrics`

CLI, packet capture, traffic, and egress tools are not exposed through R1-MCP, and probe_describe filters them out of the schema listing. probe_call will not accept a tool name outside this list.

Two boundaries, not one

Probe MCP’s side of the link and R1-MCP’s side draw different lines, and it is worth knowing which one you are reading about.

	Set by	Covers
Security boundary	Probe MCP’s companion allowlist	36 of the 43 probe functions — what a linked R1-MCP is permitted to call. It is deny-by-default, and it is the control that matters for what your consent grants
Product boundary	R1-MCP’s own exposed list	The 15 read-only tools above — what R1-MCP actually offers the model today

The 15 are a deliberate subset of the 36. So when Probe MCP’s linking page says the grant includes the SSH device CLI, that is accurate about the permission — and R1-MCP ships no way for the model to use it. Widening the product boundary later needs no change on the Probe MCP side, which is exactly why the permission you approve is the one to read carefully.

Four granted functions sit outside the exposed 15 because R1-MCP calls them itself, never the model:

Function	When R1-MCP calls it
`serve_tftp`, `stop_tftp`	During test bed config restore
`r1_forward_configure`, `r1_forward_remove`	When a location (LBS) source is set up or removed — these write the probe’s LBS forwarding configuration

A fifth, forward_status, is granted but not called by R1-MCP today.

For a live CLI session to R1-managed switches and APs, the tool you want is device_cli under Live CLI — not the probe.

`probe_reconcile` — the divergence sweep

probe_reconcile is the composite worth knowing by name. It joins the R1 AP and switch inventory against what the probe actually sees, in one call, and returns divergent devices first.

Verdict	Meaning
`confirmed_online`	Cloud and LAN agree — collapsed to a count unless you ask for the detail
`dead`	Offline in both
`disconnected_from_cloud`	Cloud says offline, but the device is alive on the LAN — the cloud path is broken, the device is fine
`missing_from_lan`	Cloud says online, but the probe can’t see it

Matched devices can also carry mismatches — an ip mismatch is often just a management interface versus a LAN interface, not a fault.

It also reports rogue devices — things on the LAN that RUCKUS One does not manage. The default filter shows alive infrastructure-role devices only and is capped; ask for all rogues, or none, if the default isn’t what you want.

The R1 side of the sweep always comes from your default connection: probe_reconcile has no connection argument, so with several tenants connected it reconciles only the default one.

Verifying a write

The probe’s other use is confirming that a change to R1 actually took effect on the wire. The probe-verify reference doc maps each class of write to the check that verifies it — auth_sessions for WLAN and AAA changes, port_diag and poe_status for port configuration, probe_reconcile for anything that affects inventory, and topology / syslog / SNMP for the rest.

Error envelopes

Probe MCP’s errors pass through verbatim — R1-MCP never rewrites them — so they can be acted on directly:

Error	What to do
`not_linked` (with `link_url`)	Open the link once in a browser to consent
`probe_offline`	The probe itself isn’t reachable; check it before retrying
`tool_failed`	The probe tool ran and failed; the probe’s own message says why
`companion_unavailable`	This deployment has no probe integration wired
`ambiguous_connection`	More than one probe connection matched; the envelope echoes the choices
`unknown_tool`	The tool is not in R1-MCP’s allowlist on the Probe MCP side
`no_identity`	Your account has no Google identity to link against — returned by every probe tool
`probe_unreachable`	R1-MCP could not reach Probe MCP at all; `detail` says why. Retry later
`bad_assertion`	Probe MCP rejected R1-MCP’s signed identity — a deployment problem, not yours; contact support
`companion_disabled`	Probe MCP has no companion key configured — also a deployment problem

probe_reconcile adds ambiguous_probe when your account has more than one probe and you didn’t name one; it auto-resolves when there is exactly one. It can also return no_probes (no probe registered on your Probe MCP account), no_cloud_devices (nothing in the R1 inventory — or in the venueId you gave — to reconcile), and r1_query_failed (the R1 inventory read failed; R1’s status and body are passed through).