Skip to main content
Glama
deenesjakoruzh
CiscoDevNet

Meraki Magic MCP

by CiscoDevNet
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Meraki Magic MCP

Meraki Magic is a Python-based MCP (Model Context Protocol) server for Cisco's Meraki Dashboard. Meraki Magic provides tools for querying the Meraki Dashboard API to discover, monitor, and manage your Meraki environment.

Two Versions Available

šŸš€ Dynamic MCP (Recommended) - meraki-mcp-dynamic.py

  • ~804 API endpoints automatically exposed

  • 100% SDK coverage - all Meraki API methods available

  • Auto-updates when you upgrade the Meraki SDK

  • No manual coding required for new endpoints

šŸ“‹ Manual MCP - meraki-mcp.py

  • 40 curated endpoints with detailed schemas

  • Type-safe with Pydantic validation

  • Custom business logic for specific use cases

  • Clean documentation for common operations

Related MCP server: Meraki MCP Server

Features

Dynamic MCP includes:

  • All organization management (admins, networks, devices, inventory, licensing)

  • Complete wireless management (SSIDs, RF profiles, Air Marshal, analytics)

  • Full switch management (ports, VLANs, stacks, QoS, access policies)

  • Advanced appliance/security (all firewall types, NAT, VPN, traffic shaping)

  • Camera management (analytics, quality, schedules, permissions)

  • Network monitoring (events, alerts, health, performance)

  • Live troubleshooting tools (ping, cable test, ARP table)

  • Webhooks and automation (alert profiles, action batches)

  • And 700+ more endpoints...

Manual MCP includes:

  • Network discovery and management

  • Device discovery and configuration

  • Client discovery and policy management

  • Wireless SSID management

  • Switch port and VLAN configuration

  • Basic firewall rules

  • Camera settings

Quick Installation

Prerequisites

  • Python 3.13+

  • Claude Desktop (or any MCP-compatible client)

  • Meraki Dashboard API Key

  • Meraki Organization ID

Fast Track

macOS:

git clone https://github.com/CiscoDevNet/meraki-magic-mcp-community.git
cd meraki-magic-mcp-community
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env-example .env
# Edit .env with your API credentials

Windows (PowerShell):

git clone https://github.com/CiscoDevNet/meraki-magic-mcp-community.git
cd meraki-magic-mcp-community
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
copy .env-example .env
# Edit .env with your API credentials

šŸ“– For detailed step-by-step instructions, see INSTALL.md

Configuration

Edit .env with your Meraki credentials:

MERAKI_API_KEY="your_api_key_here"
MERAKI_ORG_ID="your_org_id_here"
MERAKI_BASE_URL="https://api.meraki.com/api/v1"

# Optional: Performance tuning
ENABLE_CACHING=true
CACHE_TTL_SECONDS=300
READ_ONLY_MODE=true

Get your API key from: Meraki Dashboard ā†’ Organization ā†’ Settings ā†’ Dashboard API access

READ_ONLY_MODE defaults to true to block create/update/delete/remove operations. Set READ_ONLY_MODE=false only when you intend to make changes. Delete/remove calls also require confirm_destructive_action=true.

Use MERAKI_BASE_URL to point the MCP server at another Meraki region or compatible Dashboard API base URI.

Deployment Options

There are three ways to deploy Meraki Magic MCP:

Method

Best For

Transport

Local (stdio)

Claude Desktop / Cursor on same machine

stdio

HTTP Server

Remote access, shared team server

StreamableHTTP

Docker

Containerized / production deployments

StreamableHTTP

Claude Desktop Setup

Dynamic MCP (Recommended)

  1. Locate Claude config file:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

  2. Edit config with your paths:

macOS Example:

{
  "mcpServers": {
    "Meraki_Magic_MCP": {
      "command": "/path/to/meraki-magic-mcp-community/.venv/bin/fastmcp",
      "args": [
        "run",
        "-t", "stdio",
        "/path/to/meraki-magic-mcp-community/meraki-mcp-dynamic.py"
      ]
    }
  }
}

Windows Example:

{
  "mcpServers": {
    "Meraki_Magic_MCP": {
      "command": "C:/Users/YourName/meraki-magic-mcp-community/.venv/Scripts/fastmcp.exe",
      "args": [
        "run",
        "-t", "stdio",
        "C:/Users/YourName/meraki-magic-mcp-community/meraki-mcp-dynamic.py"
      ]
    }
  }
}

Replace /path/to/ with your actual installation path. Windows users: use forward slashes / and include .exe.

  1. Restart Claude Desktop (Quit completely, then reopen)

  2. Verify: Ask Claude "What MCP servers are available?"

šŸ“– Detailed setup instructions: INSTALL.md

Manual MCP (Original)

Use meraki-mcp.py instead of meraki-mcp-dynamic.py in the config above.

Both MCPs (Advanced)

You can run both simultaneously:

{
  "mcpServers": {
    "Meraki_Curated": {
      "command": "/path/to/meraki-magic-mcp-community/.venv/bin/fastmcp",
      "args": ["run", "-t", "stdio", "/path/to/meraki-magic-mcp-community/meraki-mcp.py"]
    },
    "Meraki_Full_API": {
      "command": "/path/to/meraki-magic-mcp-community/.venv/bin/fastmcp",
      "args": ["run", "-t", "stdio", "/path/to/meraki-magic-mcp-community/meraki-mcp-dynamic.py"]
    }
  }
}

HTTP Transport

Run the MCP server over HTTP for remote access or shared team use:

# Set transport in .env
MCP_TRANSPORT=http
MCP_HOST=127.0.0.1  # Use 0.0.0.0 for remote access
MCP_PORT=8000

# Start the server
python meraki-mcp-dynamic.py
# Server available at http://127.0.0.1:8000/mcp

Connect Claude Desktop to an HTTP server using mcp-remote (requires Node.js):

{
  "mcpServers": {
    "Meraki_Magic_MCP": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://127.0.0.1:8000/mcp"]
    }
  }
}

Docker Deployment

The fastest way to deploy remotely:

cp .env-example .env
# Edit .env with your MERAKI_API_KEY and MERAKI_ORG_ID
docker compose up -d
# Server available at http://localhost:8000/mcp

šŸ“– Full HTTP & Docker instructions: INSTALL.md

Keeping Updated

The dynamic MCP automatically stays current with Meraki's API:

# Manually update SDK
pip install --upgrade meraki

Then restart Claude Desktop. See UPDATE_GUIDE.md for details.

Performance & Safety Features

The dynamic MCP includes several optimizations:

āœ… Response Caching - Read-only operations cached for 5 minutes (reduces API calls by 50-90%) āœ… Read-Only Mode - Optional safety mode blocks write operations āœ… Auto-Retry - Automatic retry on failures (3 attempts) āœ… Rate Limit Handling - Automatically waits when rate limited āœ… Operation Labeling - Tools labeled as [READ], [WRITE], or [MISC]

See OPTIMIZATIONS.md for details.

Documentation

How It Works

The Dynamic MCP provides two ways to access Meraki APIs:

  1. Pre-registered tools (12 most common operations):

    • getOrganizations, getOrganizationAdmins, getOrganizationNetworks

    • getNetworkClients, getNetworkEvents, getDeviceSwitchPorts

    • And 6 more common operations

  2. Generic API caller (call_meraki_api):

    • Access ALL 804+ Meraki API methods

    • Example: call_meraki_api(section="appliance", method="getNetworkApplianceFirewallL3FirewallRules", parameters={"networkId": "L_123"})

    • Destructive methods require confirm_destructive_action=true in parameters

Example Usage

Get all admins in my organization

Show me firewall rules for network "Main Office"

Update switch port 12 on device ABC123 to enable BPDU guard

Get wireless clients from the last hour

Create a new network named "Branch Office"

Support

Contributing

Contributions welcome! Please:

  1. Fork the repository

  2. Create a feature branch

  3. Submit a pull request

Manual MCP Tools Reference

The following tools are available in the manual MCP (meraki-mcp.py). The dynamic MCP provides access to these and 760+ additional endpoints through the generic call_meraki_api tool.

Network Tools Guide

This guide provides a comprehensive overview of the curated network tools available in the manual MCP, organized by category and functionality.

Table of Contents

  1. Organization Management Tools

  2. Network Management Tools

  3. Device Management Tools

  4. Wireless Management Tools

  5. Switch Management Tools

  6. Appliance Management Tools

  7. Camera Management Tools

  8. Network Automation Tools

  9. Advanced Monitoring Tools

  10. Live Device Tools

Organization Management Tools

Basic Organization Operations

  • get_organizations() - Get a list of organizations the user has access to

  • get_organization_details(org_id) - Get details for a specific organization

  • get_organization_status(org_id) - Get the status and health of an organization

  • get_organization_inventory(org_id) - Get the inventory for an organization

  • get_organization_license(org_id) - Get the license state for an organization

  • get_organization_conf_change(org_id) - Get the org change state for an organization

Advanced Organization Management

  • get_organization_admins(org_id) - Get a list of organization admins

  • create_organization_admin(org_id, email, name, org_access, tags, networks) - Create a new organization admin

  • get_organization_api_requests(org_id, timespan) - Get organization API request history

  • get_organization_webhook_logs(org_id, timespan) - Get organization webhook logs

Network Management

  • get_networks(org_id) - Get a list of networks from Meraki

  • create_network(name, tags, productTypes, org_id, copyFromNetworkId) - Create a new network

  • delete_network(network_id, confirm_destructive_action) - Delete a network in Meraki

  • get_network_details(network_id) - Get details for a specific network

  • update_network(network_id, update_data) - Update a network's properties

Network Management Tools

Network Monitoring

  • get_network_events(network_id, timespan, per_page) - Get network events history

  • get_network_event_types(network_id) - Get available network event types

  • get_network_alerts_history(network_id, timespan) - Get network alerts history

  • get_network_alerts_settings(network_id) - Get network alerts settings

  • update_network_alerts_settings(network_id, defaultDestinations, alerts) - Update network alerts settings

Client Management

  • get_clients(network_id, timespan) - Get a list of clients from a network

  • get_client_details(network_id, client_id) - Get details for a specific client

  • get_client_usage(network_id, client_id) - Get the usage history for a client

  • get_client_policy(network_id, client_id) - Get the policy for a specific client

  • update_client_policy(network_id, client_id, device_policy, group_policy_id) - Update policy for a client

Network Traffic & Analysis

  • get_network_traffic(network_id, timespan) - Get traffic analysis data for a network

Device Management Tools

Device Information

  • get_devices(org_id) - Get a list of devices from Meraki

  • get_network_devices(network_id) - Get a list of devices in a specific network

  • get_device_details(serial) - Get details for a specific device by serial number

  • get_device_status(serial) - Get the current status of a device

  • get_device_uplink(serial) - Get the uplink status of a device

Device Operations

  • update_device(serial, device_settings) - Update a device in the Meraki organization

  • claim_devices(network_id, serials) - Claim one or more devices into a Meraki network

  • remove_device(network_id, serial, confirm_destructive_action) - Remove a device from its network

  • reboot_device(serial) - Reboot a device

Device Monitoring

  • get_device_clients(serial, timespan) - Get clients connected to a specific device

Live Device Tools

Network Diagnostics

  • ping_device(serial, target_ip, count) - Ping a device from another device

  • get_device_ping_results(serial, ping_id) - Get results from a device ping test

  • cable_test_device(serial, ports) - Run cable test on device ports

  • get_device_cable_test_results(serial, cable_test_id) - Get results from a device cable test

Device Control

  • blink_device_leds(serial, duration) - Blink device LEDs for identification

  • wake_on_lan_device(serial, mac) - Send wake-on-LAN packet to a device

Wireless Management Tools

Basic Wireless Operations

  • get_wireless_ssids(network_id) - Get wireless SSIDs for a network

  • update_wireless_ssid(network_id, ssid_number, ssid_settings) - Update a wireless SSID

  • get_wireless_settings(network_id) - Get wireless settings for a network

Advanced Wireless Management

  • get_wireless_rf_profiles(network_id) - Get wireless RF profiles for a network

  • create_wireless_rf_profile(network_id, name, band_selection_type, **kwargs) - Create a wireless RF profile

  • get_wireless_channel_utilization(network_id, timespan) - Get wireless channel utilization history

  • get_wireless_signal_quality(network_id, timespan) - Get wireless signal quality history

  • get_wireless_connection_stats(network_id, timespan) - Get wireless connection statistics

  • get_wireless_client_connectivity_events(network_id, client_id, timespan) - Get wireless client connectivity events

Switch Management Tools

Basic Switch Operations

  • get_switch_ports(serial) - Get ports for a switch

  • update_switch_port(serial, port_id, name, tags, enabled, vlan) - Update a switch port

  • get_switch_vlans(network_id) - Get VLANs for a network

  • create_switch_vlan(network_id, vlan_id, name, subnet, appliance_ip) - Create a switch VLAN

Advanced Switch Management

  • get_switch_port_statuses(serial) - Get switch port statuses

  • cycle_switch_ports(serial, ports) - Cycle (restart) switch ports

  • get_switch_access_control_lists(network_id) - Get switch access control lists

  • update_switch_access_control_lists(network_id, rules) - Update switch access control lists

  • get_switch_qos_rules(network_id) - Get switch QoS rules

  • create_switch_qos_rule(network_id, vlan, protocol, src_port, **kwargs) - Create a switch QoS rule

Appliance Management Tools

Basic Appliance Operations

  • get_security_center(network_id) - Get security information for a network

  • get_vpn_status(network_id) - Get VPN status for a network

  • get_firewall_rules(network_id) - Get firewall rules for a network

  • update_firewall_rules(network_id, rules) - Update firewall rules for a network

Advanced Appliance Management

  • get_appliance_vpn_site_to_site(network_id) - Get appliance VPN site-to-site configuration

  • update_appliance_vpn_site_to_site(network_id, mode, hubs, subnets) - Update appliance VPN site-to-site configuration

  • get_appliance_content_filtering(network_id) - Get appliance content filtering settings

  • update_appliance_content_filtering(network_id, **kwargs) - Update appliance content filtering settings

  • get_appliance_security_events(network_id, timespan) - Get appliance security events

  • get_appliance_traffic_shaping(network_id) - Get appliance traffic shaping settings

  • update_appliance_traffic_shaping(network_id, global_bandwidth_limits) - Update appliance traffic shaping settings

Camera Management Tools

Basic Camera Operations

  • get_camera_video_settings(network_id, serial) - Get video settings for a camera

  • get_camera_quality_settings(network_id) - Get quality and retention settings for cameras

Advanced Camera Management

  • get_camera_analytics_live(serial) - Get live camera analytics

  • get_camera_analytics_overview(serial, timespan) - Get camera analytics overview

  • get_camera_analytics_zones(serial) - Get camera analytics zones

  • generate_camera_snapshot(serial, timestamp) - Generate a camera snapshot

  • get_camera_sense(serial) - Get camera sense configuration

  • update_camera_sense(serial, sense_enabled, mqtt_broker_id, audio_detection) - Update camera sense configuration

Network Automation Tools

Action Batches

  • create_action_batch(org_id, actions, confirmed, synchronous) - Create an action batch for bulk operations

  • get_action_batch_status(org_id, batch_id) - Get action batch status

  • get_action_batches(org_id) - Get all action batches for an organization

Schema Definitions

The manual MCP includes comprehensive Pydantic schemas for data validation:

  • SsidUpdateSchema - Wireless SSID configuration

  • FirewallRule - Firewall rule configuration

  • DeviceUpdateSchema - Device update parameters

  • NetworkUpdateSchema - Network update parameters

  • AdminCreationSchema - Admin creation parameters

  • ActionBatchSchema - Action batch configuration

  • VpnSiteToSiteSchema - VPN site-to-site configuration

  • ContentFilteringSchema - Content filtering settings

  • TrafficShapingSchema - Traffic shaping configuration

  • CameraSenseSchema - Camera sense settings

  • SwitchQosRuleSchema - Switch QoS rule configuration

Best Practices

  1. Error Handling: Always check API responses for errors

  2. Rate Limiting: The Meraki API has rate limits; use appropriate delays (or use dynamic MCP with caching)

  3. Batch Operations: Use action batches for bulk operations

  4. Validation: Use the provided schemas for data validation

  5. Monitoring: Regularly check network events and alerts

  6. Security: Keep API keys secure and rotate them regularly

Troubleshooting

Common Issues

  1. Authentication Errors: Verify your API key is correct and has appropriate permissions

  2. Rate Limiting: If you encounter rate limiting, implement delays between requests (or use dynamic MCP with caching)

  3. Network Not Found: Ensure the network ID is correct and accessible

  4. Device Not Found: Verify the device serial number is correct and the device is online

Debug Information

Enable debug logging by setting the appropriate log level in your environment.

āš ļø Disclaimer

IMPORTANT: PRODUCTION USE DISCLAIMER

This software is provided "AS IS" without warranty of any kind, either express or implied. The authors and contributors make no representations or warranties regarding the suitability, reliability, availability, accuracy, or completeness of this software for any purpose.

USE AT YOUR OWN RISK: This MCP server is designed for development, testing, and educational purposes. Running this software in production environments is done entirely at your own risk. The authors and contributors are not responsible for any damages, data loss, service interruptions, or other issues that may arise from the use of this software in production environments.

SECURITY CONSIDERATIONS: This software requires access to your Meraki API credentials. Ensure that:

  • API keys are stored securely and not committed to version control

  • API keys have appropriate permissions and are rotated regularly

  • Network access is properly secured

  • Regular security audits are performed

NO WARRANTY: The authors disclaim all warranties, including but not limited to warranties of merchantability, fitness for a particular purpose, and non-infringement. In no event shall the authors be liable for any claim, damages, or other liability arising from the use of this software.

SUPPORT: This is an open-source project. For production use, consider implementing additional testing, monitoring, and support mechanisms appropriate for your environment.

License

See LICENSE file for details.

Available Tools

22 tools
cache_clearB

Clear all cached data

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only states 'Clear all cached data' without mentioning that it is destructive, requires permissions, or affects performance. Significant gap for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, single sentence front-loading the action. No unnecessary words, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema being present, the description does not mention return values or side effects. For a destructive tool, it should disclose behavioral context beyond the action itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has no parameters (0 params, 100% coverage). The description adds the basic meaning that this tool clears all cached data, which is sufficient given no parameters to explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Clear) and the resource (all cached data). It distinguishes from siblings like 'clear_cached_files' by being broader in scope, though it could be more specific about what 'cached data' entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'clear_cached_files' or 'cache_stats'. Lack of context for selecting this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cache_statsA

Get cache statistics and configuration

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only says 'Get cache statistics and configuration' without disclosing behavioral traits like read-only safety, authorization needs, or side effects. The burden is on the description, but it falls short.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no waste, front-loaded. Perfectly concise for a zero-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema, the description is reasonably complete for a simple stats tool. However, it could mention that this is a read-only operation to differentiate from mutating siblings like cache_clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters, so schema coverage is 100% trivially. Per rules, baseline is 4. No additional parameter info is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get cache statistics and configuration' clearly states the verb (get) and resource (cache statistics and configuration), distinguishing it from siblings like cache_clear and get_cached_response.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as cache_clear or list_cached_responses. The description does not specify context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

call_meraki_apiA

Call any Meraki API method - provides access to all 804+ endpoints

Args: section: SDK section (organizations, networks, wireless, switch, appliance, camera, devices, sensor, sm, etc.) method: Method name (e.g., getOrganizationAdmins, updateNetworkWirelessSsid, getNetworkApplianceFirewallL3FirewallRules) parameters: Dict of parameters (e.g., {"networkId": "L_123", "name": "MySSID"})

Examples: call_meraki_api(section="organizations", method="getOrganizationAdmins", parameters={"organizationId": "123456"}) call_meraki_api(section="wireless", method="updateNetworkWirelessSsid", parameters={"networkId": "L_123", "number": "0", "name": "NewSSID", "enabled": True}) call_meraki_api(section="appliance", method="getNetworkApplianceFirewallL3FirewallRules", parameters={"networkId": "L_123"})

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionYes
methodYes
parametersNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does not disclose side effects, readonly vs mutation, auth needs, or rate limits. Behavior depends on the method called, but the tool's consistent behavior is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with Args and Examples, making it clear. It is somewhat lengthy but each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity and existence of an output schema, the description covers how to use each parameter and provides representative examples. It lacks error handling or auth details but is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% parameter descriptions, but the description adds full context: section lists SDK sections, method is the endpoint name, parameters is a dict. Examples clarify usage, providing high value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it calls any Meraki API method with access to all 804+ endpoints, distinguishing it from specific sibling tools like getDevice or getNetwork.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for any Meraki API method, especially those without dedicated tools, and provides examples. It lacks explicit 'when not to use' or comparison to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

clear_cached_filesC

Clear cached response files older than specified hours

Args: older_than_hours: Delete files older than this many hours (default: 24)

ParametersJSON Schema
NameRequiredDescriptionDefault
older_than_hoursNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully convey behavioral traits. It states the tool deletes files, indicating destructive behavior, but does not disclose additional traits such as irreversibility, permission requirements, or effects on other cached responses. This is insufficient for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and includes a structured args section. It contains no unnecessary words, but could perhaps integrate the parameter description more naturally. Overall, it earns its place with minimal verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and the presence of an output schema, the description should still cover context like the scope of 'cached response files' and potential side effects. It lacks this context, and the existence of sibling caching tools further demands comparison, which is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It explains that 'older_than_hours' specifies the age threshold for deletion, adding meaning beyond the schema's type and default. However, the explanation is minimal and does not elaborate on format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool clears cached response files older than a specified number of hours, using the verb 'clear' and resource 'cached response files'. However, it does not differentiate from the sibling tool 'cache_clear', which may perform a similar or related function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides the parameter default but offers no guidance on when to use this tool versus alternatives like 'cache_clear', nor does it include any exclusions or prerequisites. The agent is left to infer usage context without explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cached_responseA

Retrieve a paginated slice of a cached response from a file

IMPORTANT: This tool returns paginated data to avoid context overflow. For full data access, use command-line tools: cat | jq

Args: filepath: Path to the cached response file (from _full_response_cached field) offset: Starting index for pagination (default: 0) limit: Maximum number of items to return (default: 10, max: 100)

Examples: get_cached_response(filepath="...", offset=0, limit=10) # First 10 items get_cached_response(filepath="...", offset=10, limit=10) # Next 10 items get_cached_response(filepath="...", offset=0, limit=100) # First 100 items

ParametersJSON Schema
NameRequiredDescriptionDefault
filepathYes
offsetNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses pagination behavior, offset/limit defaults and max, and context overflow warning. No annotations provided, but description covers key behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with structured sections (IMPORTANT, Args, Examples). Every sentence provides value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive for a 3-parameter tool with output schema. Includes examples and warnings, leaving no critical gaps for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds detailed meaning for all three parameters: filepath source, offset starting index, limit max items. Examples further clarify usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Retrieve a paginated slice of a cached response from a file', which is a specific verb+resource. It distinguishes from sibling tools like 'list_cached_responses' and 'cache_clear'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (paginated access) and when not to (full data via CLI tools), providing clear usage guidance and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getDeviceC

Get device by serial

ParametersJSON Schema
NameRequiredDescriptionDefault
serialYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description is minimal. It implies a read operation but omits details such as data freshness, authentication requirements, rate limits, or side effects. The description carries the burden but fails to disclose these traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence of five words. It is concise and earns its place, though it omits optional context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description does not need to explain return values. However, it is very terse and could add context about conditions (e.g., device not found). Adequate for a simple retrieval tool but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It identifies the serial parameter role ('by serial') but adds no constraints or format details. The value is marginal beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get device by serial' clearly states the action (get) and resource (device) along with the key identifier (serial). It distinguishes from siblings like getNetwork or getNetworkDevices, but could be more specific about the type of device or scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like getNetworkDevices or getOrganizationDevices. The description lacks context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getDeviceSwitchPortsC

Get switch ports for a device

ParametersJSON Schema
NameRequiredDescriptionDefault
serialYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only says 'Get switch ports', implying it is read-only but provides no additional behavioral context such as required permissions, rate limits, or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise. However, it is too minimal; a slightly more informative description would be appropriate given the context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and 0% schema coverage, the description lacks completeness. It does not specify what the output contains (list of ports with fields), nor does it mention important behavioral aspects for a tool with an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain the 'serial' parameter. The parameter name 'serial' hints at a device serial number, but the description adds no explanatory value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action 'Get' and resource 'switch ports' clearly. It indicates read operation but does not differentiate from sibling tools like 'updateDeviceSwitchPort' or 'getDevice', which limits differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or conditions for use, and no mention of limitations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_mcp_configA

Get MCP configuration

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavior. 'Get' implies a read-only operation, but no details are given about caching, cost, or whether the configuration changes. The simplicity of the tool (no params) limits risk, but more transparency would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, read-only) and the presence of an output schema, the description is complete enough for an agent to understand the tool's purpose. It could be slightly more descriptive, but it suffices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and schema description coverage is 100%. The description does not need to add parameter-level detail, and it correctly implies that no inputs are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get MCP configuration' clearly states the action (get) and the resource (MCP configuration). It distinguishes itself from sibling tools like getDevice or getNetwork, which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or typical scenarios, leaving the agent without decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_method_infoA

Get detailed parameter information for a method

Args: section: SDK section (e.g., 'organizations', 'networks') method: Method name (e.g., 'getOrganizationAdmins')

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionYes
methodYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states what the tool does, not any behavioral aspects like being read-only, side effects, or auth requirements. The description does not contradict annotations, but it omits important transparency details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and to the point, with three lines of content. However, the blank line at the start and the informal 'Args' section slightly reduce clarity. Still, it is efficient and well-sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown), the description adequately covers the tool's purpose and parameters. It is complete enough for a simple retrieval tool without needing further details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaningful examples and context: section (e.g., 'organizations') and method (e.g., 'getOrganizationAdmins'). This provides more semantic value than the schema's bare titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets detailed parameter information for a method, which is a specific verb+resource. It distinguishes from sibling tools like call_meraki_api or search_methods by being a meta-information tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like search_methods or list_all_methods. The description only defines its function without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getNetworkC

Get network details

ParametersJSON Schema
NameRequiredDescriptionDefault
networkIdYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description does not disclose behavioral traits beyond being a read operation. There is no mention of permissions, rate limits, or any side effects, leaving the agent without important context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (three words), but this brevity sacrifices clarity and completeness. It does not effectively communicate the tool's purpose or usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description does not mention the structure or content of the response. Given the single parameter and lack of annotations, the description is insufficient for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for its only parameter, networkId. The description does not explain what this parameter represents or how to use it, failing to compensate for the schema's lack of detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get network details', which is a clear verb+resource pair, but it lacks specificity about what details are included. Among sibling tools like getNetworkClients and getNetworkDevices, this description does not differentiate itself, making it somewhat vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as getNetworkClients or getNetworkDevices. The description offers no context about prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getNetworkClientsC

Get network clients

ParametersJSON Schema
NameRequiredDescriptionDefault
networkIdYes
timespanNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description fails to disclose whether this operation is read-only, destructive, or has side effects. The agent gets no behavioral hints beyond the literal verb 'Get'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is too shortā€”only three words. It omits critical details that could be added without bloat. Under-specification is not conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists (covering return structure), the description fails to provide any usage context or behavioral notes. The agent has little to decide when to invoke this tool appropriately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the tool description does not explain the meaning of 'networkId' or 'timespan'. The default value of 86400 for timespan is not contextualized, leaving the agent to guess its purpose (e.g., time range in seconds).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description says 'Get network clients' which identifies the action and resource, but lacks specificity compared to sibling tools like getNetworkDevices or getNetworkEvents. It doesn't clarify what qualifies as a 'client' or whether it's a list or single item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as getNetworkDevices (which might return devices) or other tools. No exclusions or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getNetworkDevicesD

Get network devices

ParametersJSON Schema
NameRequiredDescriptionDefault
networkIdYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior such as read-only nature, required permissions, or data scope. It states nothing beyond the basic action, leaving the agent uninformed about side effects or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is short, it is not meaningfully conciseā€”it provides no additional information beyond the tool name. Every sentence should add value; here, the single sentence is a waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and schema descriptions, the description is severely incomplete. Even though an output schema exists, the description does not hint at the return format or fields, making it insufficient for effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for parameters, and the description adds nothing about the 'networkId' parameterā€”no format, source, or validation hints. The parameter's purpose is only implied by the tool's name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get network devices' is a tautologyā€”it merely restates the tool name without specifying what network devices are retrieved (e.g., all devices in a network, filtered, detailed info). It fails to differentiate from sibling tools like 'getDevice' or 'getNetworkClients'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., 'getDevice' for a single device, 'getOrganizationDevices' for org-wide). There are no usage prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getNetworkEventsC

Get network events

ParametersJSON Schema
NameRequiredDescriptionDefault
networkIdYes
productTypeNo
perPageNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits. It only states 'Get network events' without disclosing whether it is read-only, any rate limits, pagination behavior (despite a perPage parameter), or the nature of the events.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (3 words) but under-specified; it is not meaningfully concise. The structure is minimal and does not front-load key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters and an output schema, the description is drastically incomplete. It does not explain what events are returned, how to filter (productType), or pagination implications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the parameters networkId, productType, or perPage. Since the input schema has 0% description coverage, the description fully fails to add meaning beyond the property types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get network events' includes a verb ('Get') and a resource ('network events'), indicating the tool retrieves events. However, it does not differentiate from sibling tools like getNetwork or getNetworkClients; it lacks specifics on the type of events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where other tools might be preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getNetworkWirelessSsidsC

Get wireless SSIDs

ParametersJSON Schema
NameRequiredDescriptionDefault
networkIdYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states only the action without disclosing side effects, authentication needs, or behavior for empty results. The tool appears read-only but lacks explicit safety cues.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is too brief to be considered appropriately concise. It fails to provide necessary context, making it under-specified rather than succinct.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the availability of an output schema, the description could be minimal but still misses key details like what the tool returns (list vs. details), preconditions, and error states. It is insufficient for safe and correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for the single parameter networkId, and the tool description adds no extra meaning. The parameter's role and source remain unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get wireless SSIDs' clearly indicates retrieval of SSIDs. It is a specific verb+resource combination, though it does not differentiate from other get* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like getNetwork or getNetworkClients. The context of use is only implied by the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getOrganizationAdminsC

Get organization administrators

ParametersJSON Schema
NameRequiredDescriptionDefault
organizationIdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only says 'Get', implying a read operation, but does not explicitly state read-only nature, permissions needed, or any side effects. The description is insufficient for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it is too minimal to fully convey the tool's purpose and usage. It prioritizes brevity over completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, output schema present), the description is barely adequate. It covers the basic action but lacks parameter and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description does not mention the single parameter 'organizationId', its role, or constraints. Parameter semantics are completely absent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets organization administrators. It uses a specific verb ('Get') and resource ('organization administrators'), distinguishing it from sibling tools like getOrganizationDevices or getOrganizationNetworks. However, it does not specify whether it returns a list or a single item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives. There is no mention of required input, prerequisites, or comparative context with other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getOrganizationDevicesC

Get organization devices

ParametersJSON Schema
NameRequiredDescriptionDefault
organizationIdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description offers no behavioral details beyond the basic read operation. There is no information on auth requirements, rate limits, or what data is returned (despite an output schema existing). The description fails to carry the transparency burden in the absence of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just one phrase, which is efficient but not appropriately sized given the lack of other context. It is not structured and omits critical information, making it under-specified despite its brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is incomplete for a tool with one parameter and an output schema. It does not explain what 'organization devices' includes, how it differs from related tools, or any edge cases. The output schema exists but is not referenced, leaving the agent without enough context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter (organizationId) with no description and 0% schema description coverage. The description does not mention or explain the parameter, nor does it add any meaning beyond what the schema provides. It fails to compensate for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'organization devices', making the purpose unambiguous. However, it does not differentiate from sibling tools like getNetworkDevices or getDevice, which also deal with devices but at different scopes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as getNetworkDevices or getDevice. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getOrganizationNetworksC

Get organization networks

ParametersJSON Schema
NameRequiredDescriptionDefault
organizationIdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the burden of behavioral disclosure. It only states the action (get) but does not disclose authentication needs, rate limits, the meaning of 'networks', or whether the operation is read-only. Lacks important context for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence that front-loads the action. However, it is under-specified for the parameter, making it too sparse for a complete definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description does not need to detail return values, but it fails to provide enough context for the single parameter. For a simple tool, this minimalism is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'organizationId' parameter. It adds no meaning beyond the parameter name, so the agent cannot infer its format or role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get organization networks' provides a specific verb and resource, clearly stating the tool's purpose. It distinguishes from siblings like 'getOrganizations' (which returns organizations) and 'getNetwork' (which returns a single network), though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'getNetwork' or 'getOrganizations', nor does it mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getOrganizationsA

Get all organizations

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavior. 'Get' implies a read-only operation, but no details on side effects, data volume, or permissions are given. It is minimally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at three words, which is appropriate for a simple list tool. However, it could benefit from a bit more context without being verbose, so it scores slightly below perfect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple, the description lacks any details about the output or behavior beyond 'Get all organizations'. An output schema exists, but the description does not reference it or explain the return value, which would add completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and schema description coverage is 100% (empty schema). The description adds nothing about parameters because none exist, meeting the baseline expectation for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all organizations' uses a specific verb and resource, clearly indicating the action and scope. It distinguishes itself from sibling tools like getOrganizationAdmins or getOrganizationNetworks by being the broadest retrieval tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the purpose is clear, there is no explicit guidance on when to use this tool versus siblings that return filtered organization data (e.g., getOrganizationNetworks). The usage context is implied but not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_all_methodsA

List all available Meraki API methods

Args: section: Optional section filter (organizations, networks, wireless, switch, appliance, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description is adequate for a simple read operation. However, it does not detail potential side effects or authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: one line for the main description and one line for the parameter doc. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and presence of an output schema, the description sufficiently covers purpose and parameter behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds meaning by explaining the section parameter as an optional filter with examples, compensating for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all available Meraki API methods' with a specific verb and resource. It distinguishes from siblings like get_method_info and search_methods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage via the section filter but lacks explicit when-not or alternative tool guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_cached_responsesA

List all cached response files

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It accurately indicates a non-destructive read operation. However, it lacks details about behavior such as response size limits, ordering, or caching implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence that is front-loaded and contains no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter list tool with an output schema, the description is complete and sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so baseline is 4. The description does not add parameter details, but none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List all cached response files' clearly states the verb (list) and resource (cached response files). It distinguishes this tool from siblings like cache_clear, cache_stats, and get_cached_response.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or context-specific usage notes provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_methodsA

Search for Meraki API methods by keyword

Args: keyword: Search term (e.g., 'admin', 'firewall', 'ssid', 'event')

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the basic purpose and gives keyword examples. It does not disclose traits like case sensitivity, behavior on empty or no-match keywords, pagination, or response format. For a search tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, consisting of only two short sentences and an example. It front-loads the purpose and immediately provides usage context via examples. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one required parameter) and has an output schema, so the description need not detail return values. However, it lacks completeness in terms of specifying behavior on edge cases (e.g., no matches, case sensitivity). For a minimal search tool, it is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, meaning the JSON schema provides no explanation for the 'keyword' parameter. The description partially compensates by providing concrete examples ('admin', 'firewall', 'ssid', 'event'), adding meaning beyond 'string'. However, it does not specify expected format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for Meraki API methods by keyword, using a specific verb ('Search') and resource ('Meraki API methods'). It distinguishes from siblings like 'get_method_info' (retrieves details of a specific method) and 'list_all_methods' (lists all methods).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear context for using the tool to search by keyword, with examples of valid keywords. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'get_method_info' for detailed info on a single method) or when not to use it. This is implicit in the sibling names, but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

updateDeviceSwitchPortC

Update switch port configuration. For the full parameter set use call_meraki_api.

ParametersJSON Schema
NameRequiredDescriptionDefault
serialYes
portIdYes
nameNo
enabledNo
poeEnabledNo
typeNo
vlanNo
voiceVlanNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description only states it updates the configuration, with no details on side effects, permissions, idempotency, or what happens to existing settings. The reference to call_meraki_api does not disclose behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous information, but the second sentence is a pointer to another tool rather than enriching the description. Could be more structured with parameter roles.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters (2 required) with no schema descriptions and no annotations, the description is insufficient for an agent to correctly invoke the tool. Output schema exists but does not compensate for missing param context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description provides no information about any of the 8 parameters, their purpose, or constraints. The phrase 'update switch port configuration' is too vague to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states updating switch port configuration, verb and resource are clear. Distinguishes from read-only sibling getDeviceSwitchPorts. However, it does not explicitly differentiate from the generic call_meraki_api which can also perform updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions using call_meraki_api for the full parameter set, implying this tool is for a subset. However, it does not specify when to choose this tool over alternatives, nor when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 22 tool updatesv0.1.0
    • First observedcache_clear
    • First observedcache_stats
    • First observedcall_meraki_api
    • First observedclear_cached_files
    • First observedget_cached_response
    • First observedget_mcp_config
    • First observedget_method_info
    • First observedgetDevice
    • First observedgetDeviceSwitchPorts
    • First observedgetNetwork
    • First observedgetNetworkClients
    • First observedgetNetworkDevices
    • First observedgetNetworkEvents
    • First observedgetNetworkWirelessSsids
    • First observedgetOrganizationAdmins
    • First observedgetOrganizationDevices
    • First observedgetOrganizationNetworks
    • First observedgetOrganizations
    • First observedlist_all_methods
    • First observedlist_cached_responses
    • First observedsearch_methods
    • First observedupdateDeviceSwitchPort
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.4/5.0
Disambiguation2/5

Multiple tools like getOrganizationAdmins, getDevice, etc., overlap with the generic call_meraki_api, which can perform all those actions and more. This creates ambiguity about which tool to use for a given operation.

Naming Consistency2/5

Tool names mix conventions: some use camelCase (getDevice, getNetworkClients) while others use snake_case (get_mcp_config, list_all_methods). This inconsistency makes it harder to predict tool names.

Tool Count3/5

With 22 tools, the count is on the higher side. Many tools are specific getters that could be subsumed by the generic call_meraki_api, making the set feel bloated for the domain.

Completeness4/5

The generic call_meraki_api provides access to all 804+ Meraki endpoints, so the tool surface is essentially complete. The specific tools cover common reads, but missing CRUD operations are addressed by the generic method.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Meraki Dashboard MCP Server

    rigzindorje
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP (Model Context Protocol) server that enables interaction with the Cisco Meraki Dashboard API, allowing users to manage Meraki networks, devices, and configurations through natural language.
    -

  • Meraki MCP Server

    xaviervalette
    F
    license
    Not graded
    quality
    D
    maintenance
    This MCP (Model Context Protocol) Server provides a communication interface for the Meraki Dashboard API, auto-generated using AG2's MCP builder from the Meraki OpenAPI specification.
    -

  • meraki-mcp

    reshif
    A
    license
    Not graded
    quality
    B
    maintenance
    A read-only MCP server for Cisco Meraki Dashboard, enabling LLMs to discover devices, check health, troubleshoot, and generate reports via natural language.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CiscoDevNet/meraki-magic-mcp-community'

If you have feedback or need assistance with the MCP directory API, please join our Discord server