The two API surfaces

SmartZone exposes two separate REST APIs, and SZ-MCP presents each as its own namespace. They are independent catalogues with independent tags — an endpoint on one is never reachable through the other.

	wifi	switches
SmartZone API	WSG (wireless)	SwitchM (switch)
Base path	/wsg/api/public/{version}	/switchm/api/{version}
Operations	1,102	238
Tags	117	42
Spec title	Virtual SmartZone - High Scale	Switch Manager

Those counts come from the indexes bundled into the deployed Worker, built from specs vendored at version v14_0 (SmartZone 7.2.0). SZ-MCP also adds three operations the specs leave out but that work: POST /audit/list on wifi, and POST /switch/troubleshooting/ping and /traceroute on switches, so search covers 1,103 and 240.

Both surfaces share one API version

The version is detected once, from your controller, when you save credentials — and the same value is used to build the base path for both namespaces. There is no separate SwitchM version to configure.

This matters because the SwitchM base path does carry the version, exactly as WSG’s does. A call to switches.call({ method: 'POST', path: '/switch' }) on a controller detected as v14_0 reaches /switchm/api/v14_0/switch.

Paths are spec paths, never full URLs

Every primitive takes the raw path from the spec, starting with /. The base path is added server-side.

// Correct
await wifi.call({ method: 'GET', path: '/domains' });
await switches.call({ method: 'POST', path: '/switch', body: { page: 1, limit: 100 } });

// Wrong — the prefix is added for you
await wifi.call({ method: 'GET', path: '/wsg/api/public/v14_0/domains' });

The service ticket is added server-side too. Although serviceTicket appears as a query parameter on nearly every operation in the spec, you never pass it.

What each surface covers

The two catalogues are shaped very differently, and it is worth knowing which one a question belongs to before searching.

wifi — the larger surface

The WSG API is where zones, AP groups, WLANs, authentication and the system itself live. Its biggest tags:

Tag	Operations
Access Point Configuration	83
AP Group	79
Ruckus Wireless AP Zone	38
System	33
Application Visibility Control	32
Authentication Service	29
Cluster Management	27
WLAN	25

switches — narrower and switch-shaped

SwitchM covers switch configuration, groups, VLANs, ports and health:

Tag	Operations
Switch Configuration	16
Switch CLI Config CLI Template	14
Switch BGP eVPN	13
Switch	11
Switch Group	9
Switch Traffic	9
Switch VLAN Setting	8
Switch Health	7

Reads and writes on each surface

Worth internalising before pointing Claude at a production controller: these are configuration APIs, and on WSG most of their operations change things.

Method	wifi	switches
GET	312	65
POST	266	89
PUT	83	36
PATCH	92	2
DELETE	349	46
Classified as writes	704 of 1,102	119 of 238

DELETE is the single most common method on the WSG surface. The method alone does not decide what is a write: SwitchM’s list endpoints are POSTs (POST /switch lists switches; GET /switch is 405) whose operationIds say add…, and SZ-MCP classifies them as reads, which is why SwitchM splits evenly. Every call Claude sends that is classified as a write goes through the write guard, which is on by default — see Security model.

How the specs are stored

Specs are vendored, not fetched from your controller at runtime. SZ-MCP ships two artefacts per surface:

• A slim index bundled into the Worker, holding one entry per operation: method, path, operationId, tags, summary, a parameter summary, and hints: whether it is a read or a write, its pagination style, its required parameters and its body and response field names. This is what search_endpoints and list_endpoints_by_tag read, with no network call.
• The full spec, stored in object storage and lazy-loaded the first time get_endpoint_details asks for that surface in a given isolate. That first load adds a few hundred milliseconds; subsequent calls in the same isolate are served from memory.

The catalogue is v14_0, your controller may not be

The bundled indexes describe a v14_0 controller. Your detected version is used to build request paths, but the endpoint catalogue Claude searches is always the vendored one. On an older controller, an endpoint found in the index may not exist — which surfaces as a 404 from call, not as a discovery failure.

Next steps

Finding the right endpoint The search path that works on these specs, the hints on each hit, and where the request body is.

Code mode primitives Per-primitive arguments, defaults and return shapes on both namespaces.

Security model Why a DELETE-heavy surface makes the SmartZone account the real control.

Examples Programs that query each surface.