Webhooks and analytics
The Webhooks feature turns R1-MCP into an event sink for your RUCKUS One tenant, and adds a set of analytics tools that answer questions the REST API alone can’t.
Enable it under Features in the dashboard.
Setting up the receiver
Section titled “Setting up the receiver”get_webhook_receiver returns the URL to configure as a webhook destination in
RUCKUS One. Once events start flowing, they’re normalized and stored, and the
analytics tools have something to work with.
The analytics are only as good as the event history you’ve collected — a receiver configured five minutes ago can’t tell you about last month.
What you can ask about
Section titled “What you can ask about”Incidents
Section titled “Incidents”list_incidents, get_incident, correlate_incident — the incident feed, and
correlation across incidents to find a common cause rather than a list of
symptoms.
The Network health check (incidents) prompt runs a full assessment from this data.
Clients
Section titled “Clients”list_clients, diagnose_client, get_client_profile — client inventory,
per-client diagnosis, and profile history.
The Client deep-dive troubleshooting report prompt assembles everything known about one MAC into a single report.
Anomalies
Section titled “Anomalies”detect_anomalies plus the Hunt infrastructure anomalies prompt — looks
for infrastructure behaving unlike itself, rather than tripping a fixed
threshold.
Admin and change audit
Section titled “Admin and change audit”list_admin_audit, get_change_chain — who changed what, when, and what
followed from it. The Admin / change audit trail prompt packages this.
When a network “just started” misbehaving, the change chain is usually the fastest path to the answer.
Roaming
Section titled “Roaming”roam_matrix, get_client_roams, find_ping_pong_clients — the roaming
picture across your APs, including clients bouncing between two APs, which is
one of the most common invisible causes of a bad wireless experience.
Events and counts
Section titled “Events and counts”query_events, get_event_counts, get_notifications, get_ap_health,
webhook_event_summary, list_webhook_events, get_webhook_event — the raw
event layer underneath the analytics, when you need to look yourself.
Watches: reproduce and catch
Section titled “Watches: reproduce and catch”Watches are for problems you can trigger but not predict:
watch_client,watch_ap,watch_incidents— arm a watch, with a TTL.list_watches,clear_watch— see and cancel what’s armed.
The workflow is the Live reproduce-and-catch (watch & capture) prompt: arm a watch on the client or AP, go reproduce the fault, and come back to exactly the events that happened during the window — instead of scrolling a firehose hoping to spot it.
This is the single best reason to enable the webhooks feature.