Meraki Network 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 IDsexecute_api → getOrganizationNetworks — find network IDs in the chosen orgsemantic_search → describe the intent in words → returns ranked capability_idsexecute_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.
This is the entry point
Every other Meraki skill needs an org ID and a network ID. Those come from the only two
capability IDs Cisco documents as directly callable:
execute_api capability_id=getOrganizations
execute_api capability_id=getOrganizationNetworks organizationId=<from step 1>
Verified capabilities
Live-verified against a real org:
| Capability ID |
Verified result |
getOrganizations |
1 org — id, name, licensing model, cloud region |
getOrganizationNetworks |
1 network — branch_office (appliance, camera, switch, wireless) |
getOrganizationAdmins |
2 admins |
getOrganizationLicensesOverview |
co-term licensing |
getOrganizationSaml |
SAML config |
getNetworkSettings |
5 network settings |
getNetworkAlertsSettings |
3 alert settings |
getOrganizationDevices |
0 |
getOrganizationInventoryDevices |
0 |
getNetworkClients |
0 |
getNetworkGroupPolicies |
0 |
Read the bottom four rows carefully. This org has zero devices, zero inventory, zero
clients and zero group policies — while holding a fully configured four-product network
with 15 SSIDs and live firewall rules. That is the single most important fact in this
skill: a configured network can report nothing at all.
Workflow: Discovery
getOrganizations — record every org ID and namegetOrganizationNetworks per org — record network IDs and productTypesgetOrganizationDevices — the device inventory- Report the counts you actually got, including zeros, before answering anything else.
Downstream skills need to know whether they are working from data or from an empty org.
Workflow: Network inventory report
- Discovery, as above
getNetworkSettings and getNetworkAlertsSettings per networkgetNetworkGroupPolicies — policy objects, if anygetOrganizationAdmins — who can change this orggetOrganizationLicensesOverview — licence model, expiry, device entitlementproductTypes per network tells you which sibling skill applies: wireless →
meraki-wireless-ops, switch → meraki-switch-ops, appliance →
meraki-security-appliance
Important Rules
- No writes exist. Network and org changes go through the dashboard.
- Report zeros explicitly. "0 devices" is a finding and must be stated, never smoothed
over or filled in from the network's configuration.
productTypes drives which skill to hand off to — do not run wireless workflows
against a network without wireless.- One page only on
getOrganizationNetworks and getNetworkClients for large orgs.
- Record in GAIT — log every discovery run.
Integration with Other Skills
| Skill |
How They Work Together |
meraki-wireless-ops |
Hand off networks with productType wireless |
meraki-switch-ops |
Hand off networks with productType switch |
meraki-security-appliance |
Hand off networks with productType appliance |
meraki-monitoring |
Health and change history once IDs are known |
gait-session-tracking |
Record all discovery runs |
Environment Variables
MERAKI_DASHBOARD_API_KEY — Meraki Dashboard API key (read-only recommended)
1---
2name: meraki-network-ops
3description: "Cisco Meraki organization and network operations (read-only) — org discovery, network inventory, device inventory, clients, group policies, admins, licensing, alert settings via Cisco's official Meraki MCP. Use as the entry point for any Meraki question, to discover org and network IDs, or to inventory Meraki networks and devices"
4version: 2.0.0
5license: Apache-2.0
6tags: [cisco, meraki, organization, network, inventory, clients, discovery, read-only]
7---
8
9# Meraki Network 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## This is the entry point
59
60Every other Meraki skill needs an org ID and a network ID. Those come from the only two
61capability IDs Cisco documents as directly callable:
62
63```
64execute_api capability_id=getOrganizations
65execute_api capability_id=getOrganizationNetworks organizationId=<from step 1>
66```
67
68## Verified capabilities
69
70Live-verified against a real org:
71
72| Capability ID | Verified result |
73|---|---|
74| `getOrganizations` | 1 org — id, name, licensing model, cloud region |
75| `getOrganizationNetworks` | 1 network — `branch_office` (appliance, camera, switch, wireless) |
76| `getOrganizationAdmins` | 2 admins |
77| `getOrganizationLicensesOverview` | co-term licensing |
78| `getOrganizationSaml` | SAML config |
79| `getNetworkSettings` | 5 network settings |
80| `getNetworkAlertsSettings` | 3 alert settings |
81| `getOrganizationDevices` | **0** |
82| `getOrganizationInventoryDevices` | **0** |
83| `getNetworkClients` | **0** |
84| `getNetworkGroupPolicies` | **0** |
85
86Read the bottom four rows carefully. **This org has zero devices, zero inventory, zero
87clients and zero group policies — while holding a fully configured four-product network
88with 15 SSIDs and live firewall rules.** That is the single most important fact in this
89skill: a configured network can report nothing at all.
90
91## Workflow: Discovery
92
931. `getOrganizations` — record every org ID and name
942. `getOrganizationNetworks` per org — record network IDs and `productTypes`
953. `getOrganizationDevices` — the device inventory
964. **Report the counts you actually got**, including zeros, before answering anything else.
97 Downstream skills need to know whether they are working from data or from an empty org.
98
99## Workflow: Network inventory report
100
1011. Discovery, as above
1022. `getNetworkSettings` and `getNetworkAlertsSettings` per network
1033. `getNetworkGroupPolicies` — policy objects, if any
1044. `getOrganizationAdmins` — who can change this org
1055. `getOrganizationLicensesOverview` — licence model, expiry, device entitlement
1066. `productTypes` per network tells you which sibling skill applies: `wireless` →
107 `meraki-wireless-ops`, `switch` → `meraki-switch-ops`, `appliance` →
108 `meraki-security-appliance`
109
110## Important Rules
111
112- **No writes exist.** Network and org changes go through the dashboard.
113- **Report zeros explicitly.** "0 devices" is a finding and must be stated, never smoothed
114 over or filled in from the network's configuration.
115- **`productTypes` drives which skill to hand off to** — do not run wireless workflows
116 against a network without `wireless`.
117- **One page only** on `getOrganizationNetworks` and `getNetworkClients` for large orgs.
118- **Record in GAIT** — log every discovery run.
119
120## Integration with Other Skills
121
122| Skill | How They Work Together |
123|-------|----------------------|
124| `meraki-wireless-ops` | Hand off networks with productType `wireless` |
125| `meraki-switch-ops` | Hand off networks with productType `switch` |
126| `meraki-security-appliance` | Hand off networks with productType `appliance` |
127| `meraki-monitoring` | Health and change history once IDs are known |
128| `gait-session-tracking` | Record all discovery runs |
129
130## Environment Variables
131
132- `MERAKI_DASHBOARD_API_KEY` — Meraki Dashboard API key (**read-only** recommended)
gabrielmoreira