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,116	238
Tags	119	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 v13_1.

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({ path: '/switches' }) on a controller detected as v13_1 reaches /switchm/api/v13_1/switches.

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: 'GET', path: '/switches' });

// Wrong — the prefix is added for you
await wifi.call({ method: 'GET', path: '/wsg/api/public/v13_1/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	81
AP Group	79
Ruckus Wireless AP Zone	38
System	33
Application Visibility Control	32
Authentication Service	29
Cluster Management	27
WLAN	26

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

Writes outnumber reads on both

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

Method	wifi	switches
GET	316	65
POST	272	89
PUT	81	36
PATCH	94	2
DELETE	353	46

DELETE is the single most common method on the WSG surface. SZ-MCP does not gate by method — 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 and a parameter summary. 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 v13_1, your controller may not be

The bundled indexes describe a v13_1 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, and what the spec quirks cost you.

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.