Meraki Wireless Operations (read-only)
MCP Server
- Server: Cisco's official Meraki MCP — developer.cisco.com
- Endpoint:
https://mcp.meraki.com/mcp (remote HTTP, no local install)
- Self-host fallback: CiscoDevNet/cisco-meraki-mcp-official (Apache-2.0)
- Requires:
MERAKI_DASHBOARD_API_KEY — use a read-only dashboard key
- Tools: exactly two —
semantic_search (discover) and execute_api (invoke)
Read-only, structurally
All 431 mutating Meraki operations (174 POST, 186 PUT, 71 DELETE) are absent from the
capability catalogue. Only non-deprecated GETs are built in, so updateNetwork,
rebootDevice, blinkDeviceLeds and friends return Capability not found.
Do not attempt writes and do not offer them. There is no ServiceNow CR path here because
there is nothing to gate — a change must be made in the Meraki dashboard directly.
How to call it
Two capability IDs may be called directly; everything else must be discovered:
execute_api → getOrganizations — find accessible org IDs
execute_api → getOrganizationNetworks — find network IDs in the chosen org
semantic_search → describe the intent in words → returns ranked capability_ids
execute_api → the chosen capability_id + its required parameters
Discover, do not guess. An earlier version of this skill hardcoded 80 method names and
54 of them did not exist in the Meraki API at all — they failed regardless of server.
semantic_search is the guard against that: it can only return IDs that exist.
Reading results honestly
One page only. execute_api returns a single page. Request a bounded page size when
supported, and never present a page as the complete dataset.
Empty is not absent. n=0 means this network reported none, never none exist.
Live proof from a real sandbox org: getOrganizationDevices returns 0 devices while
the same org has a fully configured network with 15 SSIDs.
Three distinct errors, three different fixes:
| Error |
Meaning |
Fix |
Capability not found |
ID is mutating, deprecated, or invented |
semantic_search for a real one |
Resource not found |
valid ID, wrong org/network/serial |
re-derive the ID from step 1–2 |
Invalid parameters |
valid ID, missing a required parameter |
read the capability's parameters |
Never report any of the three as "no data" — none of them mean that.
Verified capabilities
Live-verified against a real Meraki org (branch_office, wireless + switch + appliance + camera):
| Capability ID |
Verified result |
getNetworkWirelessSsids |
15 SSIDs — auth, VLAN, band, visibility per slot |
getNetworkWirelessSettings |
9 network-level wireless settings |
getNetworkWirelessRfProfiles |
2 RF profiles — band selection, power, channel width |
getNetworkWirelessAirMarshal |
0 — and 0 here means "none seen in the window", not "no rogues exist" |
Meraki always exposes 15 SSID slots whether configured or not, so a count of 15 is the
shape of the API, not evidence of 15 live networks. Check enabled per SSID.
Everything else — connection stats, latency stats, channel utilization, client
connectivity events, per-device radio settings — via semantic_search. There are 98
real wireless capabilities; search rather than guess.
Workflow: Wireless configuration audit
getOrganizations → getOrganizationNetworks → pick the wireless network
getNetworkWirelessSsids — which slots are enabled, auth type, VLAN, band
getNetworkWirelessRfProfiles — power, channel width, band steering
getNetworkWirelessSettings — network-wide wireless posture
getNetworkWirelessAirMarshal — rogue/interference observations, if any
- Report the configuration as read. Recommend changes; do not attempt them.
Workflow: WiFi complaint triage
semantic_search "wireless client connectivity events for a client" → capability ID
semantic_search "wireless connection statistics success failure rates" → capability ID
- Compare the client-specific view against the network-wide one — is it this client or
everyone? Reporting a systemic failure as a client problem sends the operator to the
wrong place.
semantic_search "channel utilization history" for the serving AP — congestion
getNetworkWirelessSsids — auth/VLAN/band restrictions that would exclude the client
- Report findings, explicitly separating what was measured from what is inferred.
Important Rules
- No writes exist. SSID, RF profile and radio changes must be made in the dashboard.
- Channel utilization over 50% is a warning, over 70% is critical — but say which AP and
which window the number came from, or it is not actionable.
- 15 SSIDs is the API's shape, not a finding.
- Record in GAIT — log every wireless assessment.
Integration with Other Skills
| Skill |
How They Work Together |
meraki-network-ops |
Network and device context for wireless work |
meraki-monitoring |
Live diagnostics and loss/latency history for APs |
catc-wireless-ops |
Compare Meraki wireless against Catalyst Center wireless |
gait-session-tracking |
Record all wireless investigations |
Environment Variables
MERAKI_DASHBOARD_API_KEY — Meraki Dashboard API key (read-only recommended)
1---
2name: meraki-wireless-ops
3description: "Cisco Meraki wireless (read-only) — SSID configuration, RF profiles, Air Marshal, channel utilization, signal quality, client connectivity events via Cisco's official Meraki MCP. Use when inspecting Meraki SSIDs, auditing RF configuration, or investigating WiFi connectivity"
4version: 2.0.0
5license: Apache-2.0
6tags: [cisco, meraki, wireless, ssid, rf, wifi, access-point, read-only]
7---
8
9# Meraki Wireless Operations (read-only)
10
11## MCP Server
12
13- **Server**: Cisco's **official** Meraki MCP — [developer.cisco.com](https://developer.cisco.com/meraki/api-v1/mcp-server/)
14- **Endpoint**: `https://mcp.meraki.com/mcp` (remote HTTP, no local install)
15- **Self-host fallback**: [CiscoDevNet/cisco-meraki-mcp-official](https://github.com/CiscoDevNet/cisco-meraki-mcp-official) (Apache-2.0)
16- **Requires**: `MERAKI_DASHBOARD_API_KEY` — use a **read-only** dashboard key
17- **Tools**: exactly two — `semantic_search` (discover) and `execute_api` (invoke)
18
19## Read-only, structurally
20
21All 431 mutating Meraki operations (174 POST, 186 PUT, 71 DELETE) are **absent from the
22capability catalogue**. Only non-deprecated GETs are built in, so `updateNetwork`,
23`rebootDevice`, `blinkDeviceLeds` and friends return `Capability not found`.
24
25Do not attempt writes and do not offer them. There is no ServiceNow CR path here because
26there is nothing to gate — a change must be made in the Meraki dashboard directly.
27
28## How to call it
29
30Two capability IDs may be called directly; everything else must be discovered:
31
321. `execute_api` → `getOrganizations` — find accessible org IDs
332. `execute_api` → `getOrganizationNetworks` — find network IDs in the chosen org
343. `semantic_search` → describe the intent in words → returns ranked `capability_id`s
354. `execute_api` → the chosen `capability_id` + its required parameters
36
37**Discover, do not guess.** An earlier version of this skill hardcoded 80 method names and
38**54 of them did not exist in the Meraki API at all** — they failed regardless of server.
39`semantic_search` is the guard against that: it can only return IDs that exist.
40
41## Reading results honestly
42
43- **One page only.** `execute_api` returns a single page. Request a bounded page size when
44 supported, and never present a page as the complete dataset.
45- **Empty is not absent.** `n=0` means *this network reported none*, never *none exist*.
46 Live proof from a real sandbox org: `getOrganizationDevices` returns **0 devices** while
47 the same org has a fully configured network with **15 SSIDs**.
48- **Three distinct errors, three different fixes:**
49
50 | Error | Meaning | Fix |
51 |---|---|---|
52 | `Capability not found` | ID is mutating, deprecated, or invented | `semantic_search` for a real one |
53 | `Resource not found` | valid ID, wrong org/network/serial | re-derive the ID from step 1–2 |
54 | `Invalid parameters` | valid ID, missing a required parameter | read the capability's parameters |
55
56 Never report any of the three as "no data" — none of them mean that.
57
58## Verified capabilities
59
60Live-verified against a real Meraki org (`branch_office`, wireless + switch + appliance + camera):
61
62| Capability ID | Verified result |
63|---|---|
64| `getNetworkWirelessSsids` | **15 SSIDs** — auth, VLAN, band, visibility per slot |
65| `getNetworkWirelessSettings` | 9 network-level wireless settings |
66| `getNetworkWirelessRfProfiles` | 2 RF profiles — band selection, power, channel width |
67| `getNetworkWirelessAirMarshal` | **0 — and 0 here means "none seen in the window", not "no rogues exist"** |
68
69Meraki always exposes **15 SSID slots** whether configured or not, so a count of 15 is the
70shape of the API, not evidence of 15 live networks. Check `enabled` per SSID.
71
72Everything else — connection stats, latency stats, channel utilization, client
73connectivity events, per-device radio settings — via `semantic_search`. There are **98**
74real wireless capabilities; search rather than guess.
75
76## Workflow: Wireless configuration audit
77
781. `getOrganizations` → `getOrganizationNetworks` → pick the wireless network
792. `getNetworkWirelessSsids` — which slots are `enabled`, auth type, VLAN, band
803. `getNetworkWirelessRfProfiles` — power, channel width, band steering
814. `getNetworkWirelessSettings` — network-wide wireless posture
825. `getNetworkWirelessAirMarshal` — rogue/interference observations, if any
836. Report the configuration as read. Recommend changes; do not attempt them.
84
85## Workflow: WiFi complaint triage
86
871. `semantic_search` "wireless client connectivity events for a client" → capability ID
882. `semantic_search` "wireless connection statistics success failure rates" → capability ID
893. Compare the client-specific view against the network-wide one — **is it this client or
90 everyone?** Reporting a systemic failure as a client problem sends the operator to the
91 wrong place.
924. `semantic_search` "channel utilization history" for the serving AP — congestion
935. `getNetworkWirelessSsids` — auth/VLAN/band restrictions that would exclude the client
946. Report findings, explicitly separating what was measured from what is inferred.
95
96## Important Rules
97
98- **No writes exist.** SSID, RF profile and radio changes must be made in the dashboard.
99- **Channel utilization** over 50% is a warning, over 70% is critical — but say which AP and
100 which window the number came from, or it is not actionable.
101- **15 SSIDs is the API's shape**, not a finding.
102- **Record in GAIT** — log every wireless assessment.
103
104## Integration with Other Skills
105
106| Skill | How They Work Together |
107|-------|----------------------|
108| `meraki-network-ops` | Network and device context for wireless work |
109| `meraki-monitoring` | Live diagnostics and loss/latency history for APs |
110| `catc-wireless-ops` | Compare Meraki wireless against Catalyst Center wireless |
111| `gait-session-tracking` | Record all wireless investigations |
112
113## Environment Variables
114
115- `MERAKI_DASHBOARD_API_KEY` — Meraki Dashboard API key (**read-only** recommended)