Examples

R1-MCP works best when you ask for an outcome and let it work out the calls. These are patterns that reliably produce good results.

Inventory and orientation

List my venues, and for each one show the AP count and how many are offline.

Claude searches the API index for the relevant endpoints, calls them, joins the results inside the sandbox, and returns a table. You get the answer, not 400 rows of JSON.

Which of my switches are running a firmware train older than 10.0.20?

Good first question for any ICX work — it tells you which firmware train to target for syntax.

RF and coverage

Do an RF health check on the Charleston venue for the last 24 hours.

The RF health check (venue) prompt is the guided version. For a single AP:

What’s the airtime utilization on AP xx:xx:xx:xx:xx:xx this week, and is it the worst in its venue?

Client troubleshooting

Client aa:bb:cc:dd:ee:ff keeps dropping. Give me the full picture — connections, roams, and any related incidents.

With the webhooks feature enabled this gets much richer, because incident and roaming history are available. The Client deep-dive troubleshooting report prompt packages it.

For an intermittent fault you can reproduce:

Arm a watch on this client for the next 20 minutes — I’m going to reproduce the problem.

Then go reproduce it, come back, and ask what was caught.

Diagrams and documentation

Draw me L2 and L3 topology diagrams for this venue.

Diagrams come back as Mermaid by default; you can ask for D2 or draw.io (importable mxGraph XML) instead.

Read the confidence note on each layer — they come from different sources. L2 is the controller’s forwarding graph and is high confidence but cached. L1 is built from LLDP and is best-effort. L3 reflects routing intent from VE/SVI subnets and static routes, not live adjacency — for live OSPF or BGP state, ask for show ip ospf neighbor or show ip bgp summary over live CLI.

Build an as-built documentation packet for the Charleston venue.

Switch configuration

This switch is on 10.0.20. Generate the config to add VLAN 200 tagged on ports 1/1/1 through 1/1/8, verify the syntax against the FastIron docs, and show me the commands before applying anything.

Naming the firmware train is the highest-value thing you can do here — see ICX. Ask to see the commands first, and turn on Write Guard if this is production.

To make it repeatable:

Turn what we just did into a MOP with rollback steps, and export it.

See MOPs.

Multi-tenant

Using the Acme Production connection, list the venues with an active incident.

Always name the connection when you have more than one enabled — R1-MCP will refuse to guess rather than act on the wrong tenant. See Multiple connections.

Questions about RUCKUS One itself

How does RUCKUS One handle DPSK, and where do I configure it?

This goes to search_docs against the RUCKUS One user guide rather than the API, and comes back with links into the live documentation.

Tips

• Scope narrowly. “Audit every venue” burns the run budget and comes back in stages. One venue at a time is faster.
• Ask for the evidence. “Show me the raw output” is always a reasonable request, and for live CLI it’s the default behavior.
• Say the tenant and the firmware. Those two facts remove most of the ambiguity in most requests.