Inventory, tags and locations
The inventory is SZ-MCP’s map of your controller: domains, zones, AP groups,
WLANs, APs and radios, switch groups, switches, ports, what each port connects
to (from LLDP), and Wi-Fi clients. Your team adds tags, locations and
critical devices on top. Claude reads it through the inventory.*
functions in code mode without calling the controller, and metrics, alert
rules and boards all name things by its ids.
How is the inventory kept up to date?
Section titled “How is the inventory kept up to date?”A first sync reads the controller once; after that it refreshes every hour.
The first sync happens in step 3 of the
setup checklist, with Sync now on the
dashboard’s Inventory card (engineers and above), or when Claude runs
inventory.sync(). A sync only reads: about 10 calls plus one per zone and per
domain. It lists up to 5,000 Wi-Fi clients by default.
The Hourly refresh switch on the Inventory card (admin) turns the refresh on or off. If the controller refuses the saved login, the refresh pauses until the credentials are updated, so it never keeps retrying a bad password against SmartZone’s lockout.
A sync run by Claude stops before the code-mode run budget runs out and reports
truncated. Run it again, or let the hourly refresh finish the job.
What are the entity ids?
Section titled “What are the entity ids?”Every entity has an id that metrics, alerts and boards use:
| Entity | Id |
|---|---|
| AP | ap:<MAC> |
| Radio | radio:<MAC>:<band> |
| Switch | switch:<MAC> |
| Port | port:<switch MAC>/1/1/5 |
| Wi-Fi client / wired client | client:<MAC> / wired_client:<MAC> |
| Registered device | device:<MAC> |
| Zone, AP group, domain, switch group | zone:<uuid>, apgroup:<uuid>, domain:<uuid>, switchgroup:<uuid> |
| WLAN | wlan:<zone uuid>:<wlanId> (its SSID is in info.ssid) |
| Location | location:<slug path>, e.g. location:dc1/hall-b |
The inventory also holds the cluster, its nodes, and the certificates, licences and licence pools read for expiry metrics. A bare MAC works wherever an id is expected.
What can Claude do with it?
Section titled “What can Claude do with it?”| Function | What it does | Role |
|---|---|---|
sync | Refresh from the controller | Any |
status | Size by type, links, tagged entities, and how the last sync went | Any |
find | Find by type, container (within), tags, text (id, MAC, name) or status; 100 results by default, up to 1,000 | Any |
describe | Everything about one entity: its path, effective location and tags (and where each came from), children, links, what it physically depends on, recent changes | Any |
neighbors | The entities around one, 1 to 3 hops out | Any |
changes | The change feed: added, removed, returned, renamed, moved, changed (model, serial, IP, firmware), linked, unlinked, tagged, located, labelled. Clients are left out | Any |
locations | The location tree with counts and tags | Any |
tag | Set or clear tags on entities | Engineer or above |
add_location / remove_location | Create a location, or delete an empty one | Engineer or above |
set_location | Place entities in a location, or unplace them | Engineer or above |
add_device / remove_device | Register or unregister a critical device by MAC | Engineer or above |
Viewers and operators who ask for a change get write_blocked, naming the
roles that can.
Ask, for example: “Which APs in Hall B are offline?”, “What is switch port 1/1/5 on the core switch connected to?” or “What changed in the inventory this week?”
How do tags work?
Section titled “How do tags work?”Tags are free-form key/value pairs, such as criticality: high,
owner: facilities or facility: yes. Claude sets up to 20 at a time on a list
of ids or on everything a selector matches; a value of null clears one.
Tags are inherited. A tag on a zone, AP group, switch or location applies to
everything under it; the nearest one wins. Metrics carry tags as tag_<key>
labels, alert rules and boards can select on them, and the starter pack’s
rogue-facility-ssid rule watches WLANs tagged facility: yes.
How do locations work?
Section titled “How do locations work?”Locations are your own physical tree, independent of SmartZone’s zones and
groups. Levels are campus, site, building, floor, hall, room, row
and rack, and an id is the slug path, e.g. location:dc1/hall-b.
Placing an entity places everything under it, so placing a zone or AP group
places its APs. A location’s tags are inherited by what is placed in it, and
within: 'location:…' works in find, metrics, alert rules, downtime and
boards. A location can only be deleted once it has no sub-locations; entities
placed in it are then unplaced.
What is a registered device?
Section titled “What is a registered device?”A device you care about that isn’t managed by SmartZone — a badge reader,
camera or building-management controller — registered by MAC with a name, tags
and a location. It stays in the inventory even when it isn’t seen, and
describe shows where it is connected now: as a Wi-Fi client, on a switch port,
or as an LLDP neighbour. SZ-MCP warns when the MAC is randomised, since a
private MAC can change.
A presence alert rule raises a problem when a registered device isn’t seen.