Troubleshooting

Connection test fails

Test connection mints a real RUCKUS token, so a failure is always in the credentials chain. In order of likelihood:

1. Wrong region. The credentials are valid but the tenant isn’t in that region. Check whether your tenant is US, Europe, or Asia — see Getting started.
2. Wrong tenant ID. The token URL includes it, so a wrong value fails at mint time.
3. Client secret mistyped. The field is write-only, so you can’t inspect what’s stored — re-enter it rather than trying to verify it.
4. Client disabled or deleted in RUCKUS One. Check the API client is still active.

The connector won’t authorize

• Redirect loop or “too many redirects” — a cookie problem during the Google sign-in hop. Use a normal (non-private) window, allow cookies for r1-mcp.lanpulse.com, remove the connector, and add it again.
• “Not authenticated” on every call — the token was revoked, or the connector was added before sign-in completed. Remove and re-add.
• Connector connects, but calls fail on credentials — MCP auth is fine and RUCKUS auth isn’t. Go re-run Test connection in the dashboard.

See Connecting to Claude.

A tool or prompt is missing

• Check the feature it belongs to is enabled on your account.
• Reconnect the connector. Tool and prompt lists are fetched when the connector refreshes; a newly enabled feature often needs a reconnect before Claude sees it.
• For Early Access features (GraphQL, Probe, Data Studio, Console), confirm Early Access is unlocked on your account.

”Connection required” errors

You have more than one enabled RUCKUS connection and the call didn’t name one. This is intentional — R1-MCP will not guess which tenant you meant. Name the connection:

Using the Acme Production connection, …

See Multiple connections.

Related: unknown_connection means the label didn’t match anything; connection_disabled means it matched a connection you’ve disabled.

Rate limits (429)

GET, PUT, and DELETE are retried automatically, honoring Retry-After, up to a small cap. POST and PATCH are not replayed automatically, because re-sending a create or a partial update isn’t safe.

If you’re hitting limits consistently, narrow the scope of the request — a question about one venue makes far fewer calls than one about every venue.

Calls time out or come back partial

Each code_mode run has a shared wall-clock budget. A very broad request exhausts it and continues in a fresh run, which reads as a partial or staged answer.

The fix is scope, not retries: ask for one venue, one time window, one device.

The FastIron syntax is wrong

Almost always a firmware train mismatch. R1-MCP scopes documentation search to one release, and defaults to the newest train — which may not be your switch’s.

Tell it the firmware: read switchFirmwareVersion from R1 or run show version, and say “this switch is on 10.0.10”. The patch level doesn’t matter; the minor does. Never mix trains within one switch’s config. See ICX.

device_cli can’t reach a device

A prompt timeout — no prompt after login, or the session closing right after login — usually means the device is offline or unreachable, not that the call was wrong. Confirm the device is online with a status query before retrying; each first-call retry opens a fresh session, so blind retries against a dead target just accumulate.

Also check you passed the device serial number, not its MAC.

Claude paraphrased console output instead of showing it

Ask for it verbatim. R1-MCP’s instruction is to surface live console output in a fenced code block labeled with its command — if you only got a summary, “show me the raw output” gets you the rest.

An endpoint behaves differently from the spec

That happens — the RUCKUS spec doesn’t capture everything. Ask Claude to save an endpoint note describing the quirk; it’s private to you and resurfaces whenever that endpoint’s details are looked up again. See Core tools.

If it’s a spec-wide problem worth everyone knowing, tell support — notes can be promoted to global visibility.

Still stuck

Contact support. Include the tenant region, roughly when the request ran, and the error text Claude reported — R1-MCP surfaces real R1 status codes and bodies, so that text is usually diagnostic.