Skip to main content
Glama
dipeshmaindolia001

Meraki MCP Server

by dipeshmaindolia001
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Meraki MCP Server

A Model Context Protocol (MCP) server that exposes a curated subset of the Cisco Meraki Dashboard API to MCP-aware clients (e.g., Cursor, Claude Desktop). It provides role-based access to ensure safe and scoped operations.

Features

  • Role-based access control (noc | sysadmin | all)

  • OpenAPI-driven tool generation (using the bundled spec)

  • Global schema validation bypass to tolerate Meraki null values (prevents "None is not of type 'string'")

  • Simple configuration via environment variables

Related MCP server: Meraki MCP Server

Requirements

  • Python 3.10+

  • A Meraki Dashboard API key with appropriate org access

  • Optional: uv for reproducible Python environments (recommended)

Install

Option A: Using uv (recommended)

# 1) Install uv if needed
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2) From project root
cd /path/to/your/meraki-mcp-server

# 3) Create and sync the environment based on pyproject.toml / uv.lock
uv sync

Option B: Using pip (fallback)

# 1) Create a virtual environment
python3 -m venv .venv
source .venv/bin/activate

# 2) Install dependencies
pip install fastmcp httpx jsonschema

Configure

Set environment variables (you can export them in your shell or supply via your MCP client config):

  • MERAKI_KEY (required): Your Meraki Dashboard API key

  • MCP_ROLE (optional): One of noc, sysadmin, all (defaults to noc)

  • MERAKI_BASE_URL (optional): Defaults to https://api.meraki.com/api/v1

Example (macOS/Linux):

export MERAKI_KEY="<your-meraki-api-key>"
export MCP_ROLE="noc"     # or sysadmin | all

Quick Run (smoke test)

You can quickly validate the server starts locally (even outside an MCP client):

# Using uv
uv run python meraki_mcp_server.py

# Or with plain Python (ensure venv is active)
python3 meraki_mcp_server.py

This will start the MCP server process. Typically, you run this via an MCP client over stdio.

Windows (PowerShell)

# Create and activate a virtual environment
python -m venv .venv
.\.venv\Scripts\Activate.ps1

# Run the server
python meraki_mcp_server.py

MCP Client Configuration

Below is an example mcp_server_config.json entry you can adapt in your MCP client (e.g., Cursor, Claude Desktop). Ensure you replace the directory path with your actual project location.

{
  "Meraki-MCP-Server": {
    "command": "uv",
    "env": {
      "MERAKI_KEY": "${MERAKI_KEY}",
      "MERAKI_BASE_URL": "https://api.meraki.com/api/v1",
      "MCP_ROLE": "noc",
      "_comment": "Set MERAKI_KEY in your shell env. MCP_ROLE values: noc | sysadmin | all"
    },
    "args": [
      "--directory",
      "/path/to/yourMCPdirector/meraki-mcp-server",
      "run",
      "python",
      "meraki_mcp_server.py",
      "stdio"
    ]
  }
}

Notes:

  • The ${MERAKI_KEY} placeholder means your MCP client will inherit the key from your shell environment.

  • stdio at the end ensures the server communicates over standard I/O as MCP expects.

  • If you do not use uv, replace command and args accordingly to invoke your Python environment.

Roles and Allowed Endpoints

The server uses route maps to constrain access:

  • noc (default):

    • GET /organizations

    • GET /organizations/{orgId}/networks

    • GET /organizations/{orgId}/devices

    • GET /organizations/{orgId}/firmware/upgrades

    • GET /organizations/{orgId}/licenses/overview

    • PUT /networks/{networkId}/firmwareUpgrades

    • All other endpoints are blocked

  • sysadmin:

    • Same read endpoints as noc, but with PUT operations blocked (read-only)

  • all:

    • Firehose mode. All endpoints allowed (use with caution)

You can switch roles by setting MCP_ROLE before launching the server.

Validation Behavior

Meraki may return null for some fields the official schema marks as strings. To avoid frequent validation errors (e.g., None is not of type 'string'), this server disables JSON schema output validation globally. This keeps tools responsive and avoids brittle schema mismatches.

If you prefer strict validation, remove the monkey patch in meraki_mcp_server.py and update the OpenAPI spec to mark nullable string fields explicitly.

Security

  • Never commit your API key. Use environment variables.

  • Limit the server’s accessible endpoints by using the appropriate role.

  • Consider running this behind a process supervisor and restricting filesystem/network access where appropriate.

Troubleshooting

  • Import errors (e.g., RouteType vs MCPType): This project is pinned to the FastMCP API compatible with MCPType. If your local FastMCP differs, install the version specified in pyproject.toml/uv.lock.

  • Validation errors: By design, validation is disabled to tolerate Meraki nulls. If you still see validation errors, ensure you’re running the current meraki_mcp_server.py.

License

MIT (or your preferred license)

Files of interest

  • meraki_mcp_server.py: Main MCP server implementation and role routing.

  • mcp_server_config.json: Example MCP client configuration for launching the server.

  • openapi/spec3.json: Meraki OpenAPI specification used to generate tools.

If you'd like, I can also update mcp_server_config.json with a filled example using your local paths and environment variables.

Available Tools

6 tools
getOrganizationDevicesB

List the devices in an organization that have been assigned to a network.

ParametersJSON Schema
NameRequiredDescriptionDefault
macNoOptional parameter to filter devices by MAC address. All returned devices will have a MAC address that contains the search term or is an exact match.
macsNoOptional parameter to filter devices by one or more MAC addresses. All returned devices will have a MAC address that is an exact match.
nameNoOptional parameter to filter devices by name. All returned devices will have a name that contains the search term or is an exact match.
tagsNoOptional parameter to filter devices by tags.
modelNoOptional parameter to filter devices by model. All returned devices will have a model that contains the search term or is an exact match.
modelsNoOptional parameter to filter devices by one or more models. All returned devices will have a model that is an exact match.
serialNoOptional parameter to filter devices by serial number. All returned devices will have a serial number that contains the search term or is an exact match.
perPageNoThe number of entries per page returned. Acceptable range is 3 - 1000. Default is 1000.
serialsNoOptional parameter to filter devices by one or more serial numbers. All returned devices will have a serial number that is an exact match.
networkIdsNoOptional parameter to filter devices by network.
endingBeforeNoA token used by the server to indicate the end of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
productTypesNoOptional parameter to filter devices by product type. Valid types are wireless, appliance, switch, systemsManager, camera, cellularGateway, sensor, wirelessController, campusGateway, and secureConnect.
sensorMetricsNoOptional parameter to filter devices by the metrics that they provide. Only applies to sensor devices.
startingAfterNoA token used by the server to indicate the start of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
organizationIdYesOrganization ID
tagsFilterTypeNoOptional parameter of value 'withAnyTags' or 'withAllTags' to indicate whether to return networks which contain ANY or ALL of the included tags. If no type is included, 'withAnyTags' will be selected.
sensorAlertProfileIdsNoOptional parameter to filter devices by the alert profiles that are bound to them. Only applies to sensor devices.
configurationUpdatedAfterNoFilter results by whether or not the device's configuration has been updated after the given timestamp

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/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 full burden of disclosing behavioral traits. It only mentions the scope (devices assigned to a network) but omits important behaviors like pagination, filtering capabilities, read-only nature, or any prerequisites. The extensive parameter list implies pagination and filtering, but these are not disclosed in the description.

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, concise sentence that immediately states the tool's purpose. It contains no filler or redundant information, making it highly efficient and easy to parse.

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 has 18 parameters and an output schema, the description itself is minimal. The schema and output schema carry most of the contextual detail. The description adds only the 'assigned to a network' scope. This is sufficient for basic understanding but lacks guidance on how to effectively use the many filters and pagination features, making it only minimally complete for a complex tool.

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 100%, so the parameters are fully documented in the input schema. The description does not add any parameter-level meaning, but the schema already provides detailed descriptions for each of the 18 parameters. Thus, the baseline of 3 is appropriate.

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 uses the specific verb 'List' and identifies the resource as 'devices in an organization that have been assigned to a network.' This clearly distinguishes it from sibling tools that list networks, organizations, or licenses, making the tool's purpose unambiguous.

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 getOrganizationNetworks or getOrganizationFirmwareUpgrades. The description states what it does but offers no contextual hints about preferable use cases, filtering scenarios, or exclusions.

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

getOrganizationFirmwareUpgradesC

Get firmware upgrade information for an organization

ParametersJSON Schema
NameRequiredDescriptionDefault
statusNoOptional parameter to filter the upgrade by status.
perPageNoThe number of entries per page returned. Acceptable range is 3 - 1000. Default is 1000.
endingBeforeNoA token used by the server to indicate the end of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
productTypesNoOptional parameter to filter the upgrade by product type.
startingAfterNoA token used by the server to indicate the start of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
organizationIdYesOrganization ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior1/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 pagination behavior, filtering capabilities, or read-only nature. The description only says 'Get firmware upgrade information' with no additional behavioral context.

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 with no wasted words. It is concise and easy to parse, though it may be too minimal to fully contextualize the tool.

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 having 6 parameters including pagination tokens and filters, the description provides no context about these features. The output schema exists but does not compensate for missing explanation of the tool's scope and behavior.

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 coverage is 100%, meaning all parameters have descriptions. The tool description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance understanding of parameters.

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 operation ('Get firmware upgrade information') and the target resource ('for an organization'). It is specific enough to distinguish from sibling tools such as updateNetworkFirmwareUpgrades and getOrganizationDevices.

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?

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is a standalone statement with no context about when it should be selected.

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

getOrganizationLicensesOverviewA

Return an overview of the license state for an organization

ParametersJSON Schema
NameRequiredDescriptionDefault
organizationIdYesOrganization ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
statesNoAggregated data for licenses by state (Per-device licensing only)
statusNoLicense status (Co-termination licensing only)
licenseCountNoTotal number of licenses (Per-device licensing only)
licenseTypesNoData by license type (Per-device licensing only)
expirationDateNoLicense expiration date (Co-termination licensing only)
systemsManagerNoAggregated data for Systems Manager licenses (Per-device licensing only)
licensedDeviceCountsNoLicense counts (Co-termination licensing only)

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 of behavioral disclosure. It only says 'Return an overview' without mentioning safety, permissions, rate limits, or what the overview contains. This is minimal and fails to disclose any behavioral traits beyond the basic return action.

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 filler words. Every word earns its place, making it extremely concise and well-structured.

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?

For a simple tool with one required parameter and an output schema, the description is adequate but minimal. It states the core function but does not explain what the overview includes or any edge cases. The presence of an output schema mitigates the need to detail return values, but the description still lacks nuance that could help an agent fully anticipate behavior.

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 schema describes the only parameter (organizationId) fully, so schema coverage is 100%. The description adds no additional meaning about the parameter, so the baseline score of 3 applies.

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 uses a specific verb and resource ('Return an overview of the license state') and clearly ties it to an organization. This distinguishes it from sibling tools like getOrganizationDevices or getOrganizationNetworks, 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 Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the name and description, but there are no exclusions or alternative recommendations. For a simple read-only tool, this is acceptable but leaves the agent to infer usage.

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

getOrganizationNetworksB

List the networks that the user has privileges on in an organization

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoAn optional parameter to filter networks by tags. The filtering is case-sensitive. If tags are included, 'tagsFilterType' should also be included (see below).
perPageNoThe number of entries per page returned. Acceptable range is 3 - 100000. Default is 1000.
endingBeforeNoA token used by the server to indicate the end of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
productTypesNoAn optional parameter to filter networks by product type. Results will have at least one of the included product types.
startingAfterNoA token used by the server to indicate the start of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
organizationIdYesOrganization ID
tagsFilterTypeNoAn optional parameter of value 'withAnyTags' or 'withAllTags' to indicate whether to return networks which contain ANY or ALL of the included tags. If no type is included, 'withAnyTags' will be selected.
configTemplateIdNoAn optional parameter that is the ID of a config template. Will return all networks bound to that template.
isBoundToConfigTemplateNoAn optional parameter to filter config template bound networks. If configTemplateId is set, this cannot be false.

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 carries the full burden of behavioral disclosure. It mentions that the networks are limited to those the user has privileges on, but it does not disclose pagination behavior, filtering capabilities, or whether this is a read-only operation beyond the verb 'list'. Significant behavioral details are left to the schema.

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 sentence that is front-loaded with the verb and resource. It is concise and free of fluff, though it could be slightly more informative about the tool's scope without becoming verbose.

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 having an output schema and a fully documented input schema, the high-level description is too bare. It does not mention that the tool supports filtering by tags, product types, or config templates, nor does it hint at pagination. For a tool with 9 parameters, the description fails to set expectations about its capabilities.

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 100%, so the baseline is 3. The description itself adds no parameter semantics, but the schema thoroughly documents all 9 parameters including filters, pagination tokens, and defaults. The tool description does not need to repeat this.

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 uses a clear verb ('List') and a specific resource ('networks') within an organization, which distinguishes it from sibling tools like getOrganizationDevices or getOrganizations. It unambiguously states what the tool does.

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 about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or cross-references to sibling tools, leaving the agent to infer usage from the name alone.

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

getOrganizationsA

List the organizations that the user has privileges on

ParametersJSON Schema
NameRequiredDescriptionDefault
perPageNoThe number of entries per page returned. Acceptable range is 3 - 9000. Default is 9000.
endingBeforeNoA token used by the server to indicate the end of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.
startingAfterNoA token used by the server to indicate the start of the page. Often this is a timestamp or an ID but it is not limited to those. This parameter should not be defined by client applications. The link for the first, last, prev, or next page in the HTTP Link header should define it.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the tool lists organizations but does not mention pagination behavior, read-only nature, or any side effects. This is a minimal disclosure for a list 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?

The description is a single, front-loaded sentence with no unnecessary words. Every component contributes to understanding the tool's purpose.

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, the presence of an output schema, and comprehensive parameter descriptions, the description is largely complete. It lacks explicit pagination context, but the schema covers the parameters. Overall, sufficient for a straightforward list tool.

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 100%, so parameters are fully documented in the schema. The description adds no additional meaning to the parameters, so baseline score of 3 is appropriate.

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 the organizations that the user has privileges on' uses a specific verb ('List') and resource ('organizations'), and clearly distinguishes from sibling tools like getOrganizationNetworks and getOrganizationDevices. The scope 'that the user has privileges on' adds clarity.

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?

The description implies when to use the tool (to list organizations the user can access) but does not explicitly state exclusions or alternatives. Usage context is clear from the description and sibling names, but no explicit guidance is given.

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

updateNetworkFirmwareUpgradesC

Update firmware upgrade information for a network

ParametersJSON Schema
NameRequiredDescriptionDefault
productsNoContains information about the network to update
timezoneNoThe timezone for the network
networkIdYesNetwork ID
upgradeWindowNoUpgrade window for devices in network

Output Schema

ParametersJSON Schema
NameRequiredDescription
productsNoThe network devices to be updated
timezoneNoThe timezone for the network
upgradeWindowNoUpgrade window for devices in network

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the burden of disclosing behavior. It only says 'Update firmware upgrade information', which implies mutation but does not mention required permissions, whether changes are additive or destructive, reversibility, or what the response contains. This is insufficient for a mutation tool with complex nested parameters.

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, concise sentence that clearly states the tool's purpose. It is not wordy, and every word contributes value. However, it is slightly under-specified (e.g., 'information' could be more concrete), so it does not earn a 5.

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 complexity (nested objects for 10 product types, upgrade windows, timezone) and the presence of only 'get' siblings, the description is far too minimal. It does not mention that products, timezone, and upgradeWindow can be configured, nor does it relate to getOrganizationFirmwareUpgrades. An output schema exists, but the description still lacks the contextual completeness expected for such a rich tool.

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 100%, and the schema itself provides detailed descriptions for parameters such as products (with per-device nextUpgrade and beta release settings), timezone, upgradeWindow, and networkId. The description adds no parameter semantics beyond the schema, but since the schema is comprehensive, a baseline score of 3 is appropriate.

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 (update) and resource (firmware upgrade information) for a network. It is distinct from the sibling tools, which are all 'get' operations, so the purpose is unambiguous. However, 'firmware upgrade information' is somewhat generic and could be more specific about the settings involved (e.g., products, upgrade window, beta participation).

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 sibling tools include getOrganizationFirmwareUpgrades, which could be a prerequisite for choosing an upgrade version, but the description does not mention this or any other usage context.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: organizations, devices, firmware upgrades at org/network level, licenses, and networks. The only potentially confusing pair (get vs update firmware) is clearly separated by verb and scope, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb-first camelCase pattern: 'get' for read operations and 'update' for the single write operation. The pattern is uniformly applied across resources, with no mixing of conventions.

Tool Count5/5

The server has 6 tools, which is well within the ideal 3-15 range. Each tool covers a meaningful aspect of the Meraki domain, and the set feels neither sparse nor bloated.

Completeness4/5

The server covers core organization-level reads (orgs, networks, devices, firmware, licenses) and one update for network firmware. Minor gaps exist, such as no per-network device listing or create/delete operations, but these are acceptable for a focused read-heavy server.

Maintenance

ActivityMaintained
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

    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/dipeshmaindolia001/meraki-mcp-server-testing'

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