Multiple RUCKUS One connections

If you manage more than one RUCKUS One tenant — an MSP with several customers, or a production and a lab tenant — you can save each as its own connection and tell Claude which one to work against.

Adding connections

The RUCKUS One connections card in the dashboard is the full manager. Each connection carries:

• A label you choose — this is what you’ll say to Claude, so make it memorable and unambiguous.
• Client ID, client secret (write-only), region, token URL, tenant ID.
• Enabled / disabled, and a default flag. The first connection you add becomes the default.

Per-row actions: Test, Edit, Disable / Enable, Make default, Delete. Labels must be unique among your connections.

Choosing a connection in conversation

list_connections shows Claude your enabled connections — id, label, tenant id, region, and which is default. Never secrets. So you can say:

Using the Acme Production connection, list the venues.

Resolution rules for call_r1 and the other tools that take a connection argument:

Situation	What happens
Connection named explicitly	That connection is used — if it’s enabled
Named but disabled	Rejected with connection_disabled
Named but unknown	Rejected with unknown_connection
Not named, exactly one enabled	That one is used
Not named, more than one enabled	Rejected with connection_required, listing the choices
Not named, connections saved but all disabled	Rejected with no_enabled_connection
No connections saved at all	Rejected with no_credentials

The fifth row is the important one: with several tenants live, R1-MCP will not guess. It asks. An ambiguous call against the wrong customer’s tenant is not a mistake worth being convenient about.

A name matches exactly — the label, including its capitalization, or the connection id. “acme production” does not match “Acme Production”.

Where the default connection is used

device_cli is the exception to the table. When you don’t name a connection, a live CLI session opens against your default connection instead of asking — unattended MOP replays have nobody to answer the question. That is what the default flag is for; for the tools in the table above it changes nothing. A disabled default is refused (connection_disabled), never swapped for another connection.

Tenant isolation

RUCKUS tokens are cached per user and per connection. Tenant A’s bearer token can never be served for a tenant B call — they’re separate cache entries by construction, not by a check that could be forgotten.

Write Guard reinforces this: the connection id is part of the confirmation fingerprint, so a token you approved for tenant A cannot be replayed against tenant B, and the confirmation preview names the target tenant explicitly.

Disabling versus deleting

Disable keeps the credentials but takes the connection out of circulation — it stops appearing to Claude and any call naming it is rejected. Useful for a customer you’ve paused work on.

Disabling the default also stops device_cli

A device_cli session opened without a connection uses your default connection, and if that connection is disabled it is refused with connection_disabled — it never falls back to another connection. Before disabling your default, use Make default on another connection so unattended MOP replays keep working.

Delete removes it. The stored secret goes with it; there is no recovery. If you delete the default, the oldest remaining connection becomes the default.

Deleting your only connection disconnects Claude

Deleting your last connection also revokes every access and refresh token issued to your Claude connectors — every connected Claude client stops working and has to be re-authorized. The dashboard warns you before it does this.

Good practice for MSPs

• Label by customer, not by environment — “Acme Production” beats “prod”.
• Keep the default set to your least dangerous tenant — it is what device_cli uses when no connection is named. There is always a default; you can move it with Make default but not clear it.
• Enable Write Guard and read the tenant name in every confirmation preview.
• Issue read-only R1 API clients for tenants where you only investigate — but AP CLI needs a read-write one. On a read-only connection device_cli returns jwt_mint_forbidden for an AP; name a read-write connection with connection. A held CLI session keeps the connection it was opened with — naming another on a later call returns connection_mismatch.