Skip to main content
Glama
AIops-tools

fabric-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

device_inventory

Read-only

Read organization inventory to get per-model-family device counts bucketed by Meraki prefixes (MX, MS, MR, MV, MG), with optional model filter.

Instructions

[READ] Org device inventory, optionally filtered by model family.

Buckets devices by Meraki model prefix (MX security appliance, MS switch, MR
wireless AP, MV camera, MG cellular gateway) and returns per-family counts.

Args:
    org_id: Meraki organization id; omit to use the target's default org.
    model: Model family/prefix to filter (e.g. 'MS', 'MR46'); omit for all.
    limit: Max rows in the returned list (default 500). The result carries
        'returned'/'limit'/'truncated'; re-run with a higher limit when
        'truncated' is true rather than treating the list as complete.
    target: Target name from config; omit for the default.

Input Schema

NameRequiredDescriptionDefault
limitNo
modelNo
org_idNo
targetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds genuinely useful behavior beyond that: how results are bucketed by model prefix and, importantly, that the result carries 'returned'/'limit'/'truncated' and how to react to truncation. That pagination contract is real behavioral disclosure, though return-field details remain limited without an output schema.

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?

Front-loaded one-line purpose followed by an Args block; every sentence carries information (bucketing behavior, defaults, truncation handling). No filler or restatement of the tool name.

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?

There is no output schema, yet the description compensates by describing the return shape (per-family counts, returned/limit/truncated flags) and the recovery path when truncated. Combined with per-parameter documentation, an agent has everything needed to call this correctly.

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?

Schema description coverage is 0%, so the description must carry the load, and it does: all four parameters are explained with semantics the schema lacks (org_id defaulting, model prefix with concrete examples like 'MS'/'MR46', limit default and truncation meaning, target defaulting). 'target' is explained only thinly ('Target name from config'), which keeps this from a 5.

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?

States a specific verb and resource ('Org device inventory'), the scope (organization-wide), and the optional filter dimension (model family). It also distinguishes itself from nearby siblings such as org_device_statuses and device_status by describing the bucketing-by-model-prefix behavior, so an agent can tell what this tool returns versus a status lookup.

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?

Gives clear context for the optional args ('omit to use the target's default org', 'omit for all') and operational guidance for the truncation case ('re-run with a higher limit when truncated'). It does not name sibling alternatives or when-not-to-use conditions, so it stops short of a 5.

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

Deploy Server

Other Tools