Linking with R1-MCP

Probe MCP is a companion to the RUCKUS MCP servers. Linking your Probe MCP account to R1-MCP lets R1-MCP’s Claude reach the on-LAN ground truth a cloud controller can’t see — local inventory, live device CLI, and switch config restore — using your probe.

The link is started from the R1-MCP side

This is the part people get backwards: you begin in R1-MCP, not here. The consent link carries R1-MCP’s signed identity assertion, so it can only be minted on the R1-MCP side. Your Probe MCP probes list shows a note saying the same thing; it is informational, and there is no button here that starts a link.

1. Open your R1-MCP dashboard and enable the Test Bed Manager feature.

2. In the Probe (config restore) card, click Connect probe-mcp.

3. You land on Probe MCP’s link page. If you aren’t signed in, sign in with Google.

4. Review the two identities shown — your R1-MCP account and your Probe MCP account — and click Connect accounts.

That’s it. The link is one-time and revocable.

Why two identities are shown

The link is gated by two independent facts: a signature proving a trusted sibling (R1-MCP) vouched for that external identity, and your live Probe MCP session proving you own the Probe MCP account. Both must line up, so the consent page shows you both sides before you approve.

What the link grants

Once linked, R1-MCP’s Claude — acting for your linked identity — can call 36 of the 43 probe functions against your probe. The allowlist is deny-by-default: everything that mutates your account or produces a shareable artifact is held back.

Included, and worth knowing about before you approve:

• All the stored and on-demand read functions — inventory, syslog, SNMP, flows, topology, PoE, pcap, and access sessions.

• https_forward and connection_egress, so R1-MCP’s Claude can reach a private on-prem controller through your probe and make authenticated upstream calls with a secret it never sees.

• The SSH device CLI — device_cli, ssh_send, ssh_read, ssh_close, and run_device_cli. This is not read-only: the grant permits a linked R1-MCP session to run commands on switches and APs using credentials you already stored. It still needs ssh.enabled on the probe, which is off by default.

  Read this as a permission, not as today’s behaviour: R1-MCP currently exposes only 15 read-only tools of the 36 to its model, and the CLI is not among them. Widening that needs no change here, though — which is why the allowlist, not R1-MCP’s current surface, is what you are approving.

• serve_tftp / stop_tftp for config restore — granted to R1-MCP only, not to the other companion systems.

• The forward-link pair, r1_forward_configure and r1_forward_remove — also R1-MCP only. These are the one part of the grant that writes: they rewrite the lbs block of your probe’s config to add or remove venue credentials, and switch the LBS receiver on and off with them. Everything else a linked system can reach either reads, or acts on a device with a credential you stored — this changes the probe’s own configuration.

Held back, first-party to your own Probe MCP session: generate_scorecard, get_reference, store_connection, delete_connection, vault_pubkey, provision_vault_secret, and store_device_credential. A linked system can use a stored credential or connection; it cannot create, replace, or delete one.

Config restore over TFTP — what it needs

The reason the TFTP pair exists: once RUCKUS One ages out a switch backup, there is no cloud API left to re-inject it. A Worker can’t help — it speaks HTTPS to a hostname, not UDP to a LAN address — so the probe serves the saved config on the switch’s own LAN and the switch pulls it with copy tftp startup-config.

Linking the accounts is necessary but not sufficient. The restore also needs:

• tftp.enabled: true in the probe’s config. It is off by default, and serve_tftp returns tftp disabled until you turn it on.
• The probe on the same LAN as the switch, since the switch is given the probe’s LAN IP to fetch from.

What the probe serves is deliberately narrow: one file, one client, read requests only, held in memory and never written to disk, size-capped at 1,024 KB, its SHA-256 verified before the first byte goes out, and torn down automatically when the window expires.

That window is tftp.ttl_sec, which is both the default and the ceiling — 300 seconds out of the box. Asking serve_tftp for a longer window doesn’t extend it; you get tftp.ttl_sec regardless. Raise the config key if a restore genuinely needs longer.

Caution

TFTP is cleartext and unauthenticated. For the length of the serve window, anything on that LAN can request the file, and a switch config carries secret material. This is built for a lab or bench test bed — call stop_tftp as soon as the copy finishes rather than waiting for the TTL.

Telemetry forwarding to R1-MCP

The link has a second half that isn’t a tool call at all. Once R1-MCP registers sources against your probe, matching telemetry is forwarded to it as it arrives, with no round trip through Claude. Three source kinds exist — lbs, syslog, and snmp — and R1-MCP handles the LBS ones today.

Registering an LBS source is what switches the probe’s LBS receiver on: the call provisions that venue’s credentials on the probe’s embedded MQTT broker and sets lbs.enabled. Removing the last one turns it off again. The probe applies either change on its next heartbeat, within 60 seconds. You don’t edit the lbs block yourself — your own settings in it (port, bands, reporting interval) are carried through untouched.

Checking the forward is alive

forward_status reports one verdict per link. Read the verdict, not the timestamp:

Verdict	Means
ok	Forwarding, and the last attempt was accepted
faulted	The last forward was refused. lastError says whether the whole link is being rejected or only some sources
silent	Something was forwarding and stopped
never_forwarded	Nothing has ever been sent. Not the same as silent — nothing was configured, versus something that was and quit
disabled	Turned off deliberately

silent is the one no other signal can see. Every other health check on either side needs a message to arrive before it can report anything, so a probe that simply stops forwarding trips none of them. A link counts as silent after 600 seconds without a successful forward.

Note

Every verdict here is about what this system sent, never about what arrived. R1-MCP answers the receiving half separately, using the same words for different claims. ok here with nothing showing there points at the network or the URL between them — not at the probe, and not at the ingest.

Moving a link between accounts

If the R1-MCP identity is already linked to a different Probe MCP account, the link is refused unless you explicitly confirm the move (a checkbox that warns the other account loses access). Re-linking the same pair just shows “already connected.”

Revoke a link

From the Probe MCP dashboard, view your links and delete the one you want to revoke. Every link, owner-move, and revoke is recorded in an audit trail.

Note

sz-mcp, cp-mcp, and the coordinator are registered as potential companions, but only R1-MCP is a live caller today. The other three get a smaller allowlist — 31 functions, the shared read and egress surface — without the TFTP pair, the forward-link pair, or forward_status. Serving a switch config on your LAN is deliberately R1-MCP’s Test Bed Manager alone, and the forward links are R1-MCP’s own relationship with your probe.

Next steps

Probe tools reference The full catalog of probe.* functions, so you can see exactly what the allowlist covers.

Security model How the link is authenticated — per-system signing keys, rotation, and the audit trail.

Limits and budgets The TFTP serve window and size cap, and the services a linked caller still needs enabled.