What is SZ-MCP?

SZ-MCP is a hosted MCP server that connects Claude to your RUCKUS SmartZone controller. You sign in with Google, save your SmartZone admin credentials, and add one URL to Claude as a custom connector. From then on you can ask Claude about your wireless and switch estate in plain language, and it works against the live controller on your behalf.

What's newOct 4: 41 new pages, including Changes and approvals, Monitoring and alerts and Reports. 22 updated.All changes

It covers both of SmartZone’s API surfaces: the WSG wireless API and the SwitchM switch API.

Your controller needs a publicly trusted TLS certificate

SmartZone ships with a self-signed certificate, and Cloudflare Workers reject those on outbound calls with no way to skip verification. A controller reached directly over the internet must present a certificate from a public CA, or nothing here will connect. This is the single most common reason a new setup fails — see Controller requirements. A private or self-signed controller can instead be reached through the controller tunnel, which is in limited rollout: contact support to have it enabled.

The idea: one tool, two API surfaces

Most MCP servers expose one MCP tool per API operation. SmartZone’s two specs define 1,340 operations between them — no model can pick sensibly from a list that long, and the tool definitions alone would swamp the context window.

SZ-MCP instead exposes exactly one MCP tool, code_mode. Inside it, Claude writes small JavaScript programs against twelve namespaces. Two of them can discover SmartZone API endpoints and call them:

Namespace	API surface	Operations
wifi	SmartZone WSG (wireless)	1,102 across 117 tags
switches	SmartZone SwitchM (switch)	238 across 42 tags

Both expose the same eight primitives. So instead of choosing from 1,340 tools, Claude searches the API index, reads the endpoint’s schema, and calls it — the same way you would with the API reference open.

The other ten work mostly on data SZ-MCP keeps for your organisation, without calling the controller API directly: stream (data the controller pushes by Northbound streaming, when that is set up), inventory, metrics, alerts, boards, history (who changed what), notes (site knowledge), mop (methods of procedure), lint (the config linter) and org (the organisation’s setup as one YAML document).

That code runs in a sandboxed V8 isolate on Cloudflare, with your credentials applied server-side. Read How code mode works for the mechanics.

What you can ask for

• “List every AP zone on this controller and how many APs are in each.”
• “Which WLANs are configured with an open security profile?”
• “Show me the switches in the Charleston group and their firmware versions.”
• “Find the endpoint that creates a DHCP profile and tell me what it needs.”
• “What’s the port configuration on switch X?”

Monitoring, alerts and boards

Beyond answering questions, SZ-MCP can watch the controller for you. With API polling on, it collects metrics, alarms and rogue access points every 5 minutes; Nagios-style alert rules turn them into email, webhook (including Slack, Teams and PagerDuty formats) or Jira notifications; and boards show them live on a second screen. The setup checklist at /setup turns all of this on in six steps.

Access is delegated to SmartZone, deliberately

SZ-MCP reaches every WSG and SwitchM endpoint your saved admin account is permitted to call — GET, POST, PUT, PATCH and DELETE alike — so the account you save is the outer access boundary. Create a dedicated SmartZone admin scoped to the minimum role and domain your use case needs. Your role in the SZ-MCP organisation is a second boundary: viewers and operators cannot send writes at all.

Inside that boundary, the write guard (on by default) holds every write until you agree to a preview of it, asks for an authenticator code or a dashboard approval for dangerous actions, and can refuse all writes in read-only mode. See Security model.

Getting started

1. Sign in and save your SmartZone credentials
2. Connect it to Claude
3. Try an example

Explore the docs

Set up

Getting started The three steps end to end: sign in with Google, save your controller credentials, and add the connector to Claude.

Controller requirements The publicly trusted certificate and public address a directly reached controller needs, the refused ranges, ports 8443 and 443, and the tunnel alternative.

SmartZone credentials Every field on the credentials form, how the API version is detected, and how to rotate or delete what you saved.

Connecting to Claude Add SZ-MCP as a custom connector — the MCP URL, the consent screen, how long the tokens last, and how to revoke them.

The setup checklist Six steps at /setup: connect, check the login's privileges, start polling, read the first health report, turn on alerts, open a board.

Reach a private or self-signed controller The controller tunnel (limited rollout): run cloudflared next to the controller, and what passes through it.

Let's Encrypt for a tunnelled controller Have SZ-MCP issue and renew a publicly trusted certificate for a controller behind the tunnel.

How it works

How code mode works Why SZ-MCP exposes one MCP tool instead of 1,340, and how Claude's program runs in a sandboxed isolate.

The two API surfaces What separates wifi from switches — base paths, the shared API version, and what each bundled index contains.

Finding the right endpoint The discovery path: task helpers first, then search, the hints on each hit, and where the request body is.

Security model Where your controller password lives, how service tickets are minted server-side, and what Claude can never see.

Searching the SmartZone guides How Claude searches and reads the 23 SmartZone 7.2.0 guides with search_docs and read_doc.

Endpoint notes Save a quirk you proved about an API endpoint so everyone in your organisation sees it.

Reference

Code mode primitives All eight primitives on both namespaces — arguments, defaults, return shapes, and the error envelopes call returns instead of throwing.

Limits and quotas Every timeout, size cap, token lifetime and cache window, and what each one does when you reach it.

Namespaces and helpers All 12 namespaces and 147 functions Claude can call, with the role each one needs.

Lint rules The 30 best-practice rules the config linter checks, their severity, and which it can fix.

Built-in prompts The ten starter prompts in Claude's + menu and the arguments each one takes.

Monitoring and alerts

How alerts work Nagios-style SOFT and HARD states, flapping, acknowledgements, downtime, unreachable devices, the Alerts page and who can do what.

Alert rules The six rule kinds and their fields, backtesting, the 37-rule starter pack, and keeping rules in git as YAML.

Alert notifications Email to confirmed addresses, the webhook as signed JSON, Slack, Teams or PagerDuty, Jira issues, escalation levels and the digest.

Monitoring the monitoring The /health and /health/org endpoints for your NMS, and a dead-man's-switch heartbeat.

Boards Live dashboards Claude builds: panel types, variables, live updates, layout editing and kiosk mode.

Sharing boards View-only links for wall screens, with expiry and one-click revoke.

Inventory, tags and locations The map of zones, APs, switches, ports and links Claude reads, plus your own tags, locations and critical devices.

Metrics and the scrape endpoint What polling collects and keeps, and scraping GET /metrics into Prometheus with a scrape token.

Unknown-device detection Alert on a Wi-Fi or wired device nobody registered, with allow lists by MAC, vendor, host name or OS.

Synthetic reachability checks Have chosen APs ping a gateway or server on a schedule, and alert when it stops answering.

Switch power supplies, fans and temperature ICX PSU, fan and temperature readings, and starter rules that recover when the hardware does.

Weekly baselines What is normal for this hour of the week, the 3-week warm-up, and the PromQL baseline functions.

Topology diagrams A Mermaid diagram of switches, APs and their LLDP links, drawn from the last sync.

Site notes and runbooks What your team knows about a site or a rule, sent with every problem notification.

The context pack Where a problem is, what it hangs off, related problems, recent events and changes, and how often it happened before.

Reports

Availability (SLA) reports Uptime per AP, switch, port, controller node or synthetic check against a target, with planned downtime and coverage.

Capacity forecasts When licence pools, PoE budgets, ports, clients per AP and airtime will reach their limits.

Alert quality report Which rules are noisy, ignored or slow to acknowledge, and what to change.

Shift-handover digest What happened since the last shift, on demand or emailed daily or weekly.

Alert post-mortems A write-up of one alert episode, ready to print or download as Markdown.

Audit evidence pack One zip of availability, audit, change and alert records for a period, with a SHA-256 manifest.

Changes and approvals

Approving dangerous changes Confirm in chat, an authenticator code, or a dashboard approval: which a change needs and who can give it.

Write history and undo The one-year record of every change sent through SZ-MCP, and what history.undo can reverse within 30 days.

Post-change verification What SZ-MCP watches for 15 minutes after a write, and the verdict it reaches.

Controller audit log and timeline The controller's own admin audit log, merged with SZ-MCP's writes, drift and alerts.

Config snapshots and drift Daily configuration snapshots and the field-level changes between them, kept 180 days.

Change procedures (MOPs) Checked, step-by-step changes approved once per run, with a change window and rollback.

Scheduling a MOP Run a MOP once or on a daily or weekly schedule as a standing approval.

MOP documents and branding A MOP or run record as Word, Markdown or a printable page, with your logo.

Best-practice config linter Check the configuration against best practice, waive findings, and turn fixes into a MOP.

Switch config backup and restore Back up an ICX switch config, compare backups, and restore one safely.

Troubleshooting tools

Client journey One Wi-Fi client's joins, roams, failures and disconnects in time order.

Switch port lookup Which ICX switch port a device or AP is plugged into, and whether it is an uplink.

Ping, traceroute and routing tables Ping and traceroute from an AP or ICX switch, and read a switch routing table.

Integrations

Nagios and Icinga Send alert state as passive check results, with generated config and a freshness check.

Zabbix Push alert state to Zabbix over the API or the sender, with the SZ-MCP alerts template.

Splunk and syslog Forward alerts, alarms, admin activity and writes to Splunk HEC or a syslog server.

ServiceNow Open an incident for a HARD problem and resolve it when the problem recovers.

NetBox Pull locations from NetBox and push devices and interfaces to it.

Organisation

Teams, organisations and roles Share a controller with your team: the five roles, invites, ownership and switching organisations.

Privacy controls How long client data is kept, and pseudonymising client names.

Configuration bundle Export an organisation's setup as one YAML file and import it elsewhere.

More

Examples Worked code-mode programs — listing zones, paginating safely, and reading an endpoint's schema before calling it.

Troubleshooting Certificate refusals, failed connection tests, forbidden hosts, 401 loops and the errors that arrive inside a 200.

How your credentials are handled

Your SmartZone password is encrypted at rest with AES-256-GCM, decrypted only when a service ticket needs minting, and never sent to Claude or included in any model context. The service ticket is attached to upstream URLs server-side and redacted from everything the model sees. See Security model.