de en es ja ko ru zh

Meraki Magic MCP

Name: Meraki Magic MCP
Author: CiscoDevNet

by CiscoDevNet

Overview Schema Source Related Servers Discussions Admin

Python

Local

MCP mágico Meraki

Meraki Magic es un servidor MCP (Protocolo de Contexto de Modelo) basado en Python para Meraki Dashboard de Cisco. Meraki Magic proporciona herramientas para consultar la API de Meraki Dashboard y así descubrir, supervisar y gestionar su entorno Meraki.

Características

Descubrimiento de red
Descubrimiento de dispositivos
Descubrimiento de clientes
Implementación de servidor MCP simple y extensible

Related MCP server: Meraki MCP Server

Instalación

Clonar el repositorio:

git clone https://github.com/mkutka/meraki-magic.git
cd meraki-magic-mcp

Crea un entorno virtual y actívalo:

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

Instalar dependencias:

pip install -r requirements.txt

Configuración

Copie el archivo de entorno de ejemplo:

cp .env-example .env

Actualice el archivo .env con su clave API de Meraki y el ID de la organización:

MERAKI_API_KEY="Meraki API Key here"
MERAKI_ORG_ID="Meraki Org ID here"

Uso con el cliente de escritorio Claude

Configurar Claude Desktop para utilizar este servidor MCP:

Abra Claude Desktop
Vaya a Configuración > Desarrollador > Editar configuración
Agregue el siguiente archivo de configuración claude_desktop_config.json

{
  "mcpServers": {
      "Meraki_Magic_MCP": {
        "command": "/Users/mkutka/meraki-magic-mcp/.venv/bin/fastmcp",
        "args": [
          "run",
          "/Users/mkutka/meraki-magic-mcp/meraki-mcp.py"
        ]
      }
  }
}

Reemplace la ruta anterior para reflejar su entorno local.

Reiniciar Claude Desktop
Interactuar con Claude Desktop

Available Tools

22 tools

cache_clearB

Clear all cached data

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`section`	Yes
`method`	Yes
`parameters`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`older_than_hours`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`filepath`	Yes
`offset`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`serial`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`serial`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`section`	Yes
`method`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`networkId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`networkId`	Yes
`timespan`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`networkId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`networkId`	Yes
`productType`	No
`perPage`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`networkId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`organizationId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`organizationId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`organizationId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`section`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`keyword`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`serial`	Yes
`portId`	Yes
`name`	No
`enabled`	No
`poeEnabled`	No
`type`	No
`vlan`	No
`voiceVlan`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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.

22 tool updatesv0.1.0May 14, 2026
- 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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.4/5.0

Scored 2026-05-14 19:10 across 22 tools

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

ActivityMaintained

ResponsivenessSlow

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
2
KodyOAuth
io.github.kentcdodds
Your agents' cloud. MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2759
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23

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.
Updated a year ago (2025-07-16 14:41 UTC)
-
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.
Updated a year ago (2025-07-18 17:57 UTC)
-
meraki-dashboard-api
Networking & Infrastructure Cloud Platforms Monitoring
Flagler-County-BoCC
F
license
C
quality
D
maintenance
A read-only MCP server for the Cisco Meraki Dashboard API that exposes 50 GET endpoints for understanding network topology from organization down to individual devices and ports.
Updated 4 months ago (2026-06-18 14:15 UTC)
50
-
meraki-mcp
Networking & Infrastructure Observability
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.
Updated 3 months ago (2026-07-26 13:39 UTC)
MIT