Cisco Meraki
Every network, uplink and port — answerable, with the classic NOC toolkit still on tap.
Meraki is the layer everything else at a client sits on, and it is where an outage gets diagnosed or misdiagnosed. Connect it and a session reads the whole picture — networks, devices and their live status, wireless health, switch ports, appliance uplinks and VPN, licensing and firmware — then runs the five safe NOC actions on top: ping from a device, cable test, port cycle, LED blink, reboot. Configuration is not merely withheld; the client refuses any request outside those five action paths, so there is no way to change a setting from here.
The story
What changes once it’s connected.
The Meraki dashboard is a good dashboard, which is exactly the problem: the answer is always three clicks away, in a different org, behind a filter someone else set. Connect Meraki here and the three clicks become a sentence. Which devices are dark or alerting, whether the branch uplink is dropping packets, what the wireless failures at the clinic actually broke on, which licenses fall off the end of the quarter — asked once, answered with the network and serial attached.
The read surface tracks how a Meraki estate is actually run. Org-wide device status and availability, uplink loss and latency, licensing under both the co-termination and per-device models, firmware upgrade records, and the assurance alerts Meraki raises on its own. Networks, devices and the clients seen on them. SSID configuration and the wireless connection stats behind it, with the individual failed associations broken out by the stage they died at. Switch port configuration alongside live port status, errors and neighbours. Appliance uplinks, site-to-site VPN reachability, and one MX's load score when the box itself is suspect.
Then the part most read-only integrations leave out: the actions a NOC actually needs at two in the morning. Ping a target from a Meraki device, cable-test a run, cycle a port, blink a chassis LED, reboot a device. Five, and only five — the client checks every non-GET request against an allowlist of those exact endpoints and refuses anything else, so no SSID, VLAN, firewall rule, port setting, or firmware schedule can be written from here at all. A connection binds one or more Meraki organizations chosen at connect time; every org-scoped question runs inside them, and where several are bound the ask has to say which one it means.
Things you can ask
Ask it like you’d ask a teammate.
Skills included
Every skill, in the open.
29 skills across 7 areas
Reads, plus exactly five device actions — ping from a device, cable test, switch-port cycle, LED blink, and reboot. Nothing else can be written, because the client rejects any request to a path outside that allowlist before it leaves the building: no SSID, VLAN, firewall rule, port setting, license, or firmware schedule is changeable from here, and there is no create or delete anywhere in the surface. Of the five, ping, cable test and LED blink are harmless. Cycling a port drops whatever hangs off it for the moment it takes, and a reboot puts the device off the network for 30–60 seconds. Neither is held behind a typed confirmation — the serial and ports named in the ask are the ones that go down — so the confirming is yours to do before you ask. The API key carries whatever dashboard rights the admin who generated it holds, and every org-scoped call is fenced to the Meraki organizations bound at connect time.
Organization & inventory8The org-wide view: what every device is doing right now, how uplinks are performing, what licensing and firmware look like, and what Meraki itself has flagged.⊘ Read-only. It cannot schedule or cancel a firmware upgrade, claim, move, or renew a license, or acknowledge and close an alert. Long lists are followed up to a page cap and come back marked as truncated rather than quietly short. Everything here runs inside one bound Meraki organization at a time — where a connection binds several, the ask has to name which.›
get_organizationThe bound organization's own record — its name, the licensing model it runs under, and how it's managed.list_device_statusesWhere every piece of hardware stands at this moment — online, alerting, offline or dormant — each row carrying its network and serial.list_device_availabilitiesThe same estate seen as uptime instead of a status colour: availability state, device by device.uplink_loss_latencyPacket loss and latency on every MX and Z uplink in the org, sampled over the last five minutes only — a live reading, not a trend line.licenses_overviewLicensing in summary — status, expiry, counts — and the one that answers for co-termination and per-device orgs alike.list_licensesLicensing broken out device by device; a co-termination org has no such list and returns a 404 instead, so the summary is the answer for those.firmware_upgradesThe firmware record for the org: what's scheduled, what's running, and what already landed.list_assurance_alertsWhat Meraki is raising on its own — devices down, uplinks struggling, config-drift signals — narrowable by severity and by category.
Networks & clients6The day-to-day layer: which networks exist, what hardware sits in each, and what has been connected to them lately.⊘ Reading only — no network is created, renamed, tagged, or deleted, and no client is blocked, unblocked, or given a group policy. Client history reaches back 31 days at the outside; that ceiling is Meraki's, not a setting here.›
list_networksEvery network under the bound org, with its product types, tags, and timezone — and filterable by tag when a client uses them.get_networkA single network's record, pulled straight by its N_ identifier.list_devicesThe hardware inventory — model, serial, home network, firmware, and site address — narrowable to one model family such as MR, MS, or MX.get_deviceOne device on its own, looked up by the serial on its label.list_network_clientsWhat has actually been on a network in a given window — usage, IP, VLAN, and how each one connected. A day unless you widen it, and 31 days is as far back as it goes.get_network_clientA single connected device on a network, found either by its client id or by its MAC.
Wireless3SSID configuration and the health of what's associating to it — the aggregate number, and the individual failures underneath it.⊘ SSIDs are readable and never writable: none is created, renamed, enabled, disabled, or re-keyed from here. Radio settings, RF profiles, and per-client wireless history aren't part of this surface. SSID responses can include pre-shared keys, so what comes back is treated as sensitive rather than something to paste into a summary.›
list_ssidsThe SSIDs configured on a wireless network — read-only, and worth handling carefully, because the response can carry admin pre-shared keys.wireless_connection_statsAssociation success against failure for a whole network over the window you choose — the health number you check before going hunting.wireless_failed_connectionsThe failures behind that number, one event at a time, each pinned to the stage it broke at: association, authentication, DHCP, or DNS.
Switching2A switch's ports both ways round: how they're configured, and what they're doing right now.⊘ Port configuration is read-only — no VLAN, PoE setting, or port name is written from here. The one thing a session can do to a port is cut its power and restore it, and that lives with the NOC actions.›
list_switch_portsHow a switch's ports are set up — name, VLAN, enabled state, PoE — as configuration to read, never to rewrite.switch_port_statusesThe live half of the same switch: link and negotiated speed, error and warning counts, traffic, and the CDP/LLDP neighbour on the far end.
Security appliance3The MX and Z side: WAN uplinks across the org, site-to-site VPN reachability, and how hard a single appliance is working.⊘ Status and load only. Firewall rules, VPN configuration, traffic shaping, and content filtering are neither read nor changed here — if the answer is 'a rule is wrong', fixing it is still a dashboard job.›
appliance_uplink_statusesEvery appliance's WAN interfaces across the org — IP, gateway, and whether the connection is genuinely up.vpn_statusesSite-to-site VPN seen org-wide, appliance by appliance, with each peer and whether it can currently be reached.appliance_performanceOne MX's load score — the number that decides whether the box itself is the bottleneck.
NOC actions6The five things a session can actually do to a device, and the fetcher for a job that outran the call that started it.⊘ None of it writes configuration: no setting, policy, or schedule changes. Ping, cable test, and port cycle run as Meraki jobs — the call waits around thirty seconds and, if the job is still going, hands back a job id to collect later instead of blocking. Nothing here is gated on a typed confirmation, so the serial and ports named in the ask are acted on as asked: a port cycle drops what's plugged into it, and a reboot takes the device off the network for 30–60 seconds.✎ Writes: Five device operations, and nothing beyond them: ping_device sends packets out from a Meraki device, cable_test probes named switch ports, cycle_switch_port powers those ports off and back on, blink_device_leds flashes a chassis light, and reboot_device restarts the device. That list is the complete write surface — the client refuses any other action path outright.›
ping_devicePing a target from a Meraki device instead of from your own desk — a job, created and then waited on until it reports.cable_testCheck the copper on named switch ports; harmless to run, but slow enough that half a minute before a result is normal.cycle_switch_portCut power to named ports and bring it back — the classic fix for a stuck AP or phone, at the cost of a brief drop for whatever is on them. Works on MS switches including Catalyst.blink_device_ledsSet a device's LEDs flashing so whoever is standing in the rack can find it; nothing else about the device is touched.reboot_deviceRestart a device, which takes it off the network for 30–60 seconds. No confirmation step stands in the way, so the serial in the ask is the one that goes down — check it first.get_live_tool_resultCollect a ping, cable test, or port cycle by its job id when the original call stopped waiting — a read, not a second run of the action.
Agent & session1What this connection is: the Meraki organizations it's bound to, and whether the key behind it still works.⊘ Read-only, and it reports the binding rather than altering it — it cannot add an organization to the roster, swap the API key, or repair a connection Meraki has stopped accepting. When a key is revoked in the dashboard the next call fails and the connection is marked invalid; this is where that shows up.›
whoamiWhich Meraki organizations this connection binds, what the session is allowed to do, and whether the stored key is still valid and when it was last checked.
Connecting
Wire it in, in an afternoon.
How to connect
- 01In dashboard.meraki.com, open My Profile → API access on an account with the dashboard rights you want the connection to have.
- 02Generate an API key — it inherits exactly that account's permissions, no more and no less.
- 03Paste the key here and tick the Meraki organizations to bind; the connection is checked against every one of them before it saves.
Patch your stack in.
Start the Switchboard free trial against your own environment — read-only, traced answers, live in an afternoon. The apps are on the shelf when you want them.