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
Section titled “Adding connections”The 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, tenant ID.
- Enabled / disabled, and a default flag.
Per-row actions: test, edit, enable or disable, set as default, delete.
Choosing a connection in conversation
Section titled “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 when a call doesn’t name one:
| 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 |
That last 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.
Tenant isolation
Section titled “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
Section titled “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.
Delete removes it. The stored secret goes with it; there is no recovery.
Good practice for MSPs
Section titled “Good practice for MSPs”- Label by customer, not by environment — “Acme Production” beats “prod”.
- Keep the default set to your least dangerous tenant, or to none at all if every tenant is production.
- Enable Write Guard and read the tenant name in every confirmation preview.
- Issue read-only R1 API clients for tenants where you only investigate.