Skip to main content
Glama

organizations-list-availabilities

Retrieve device availability data for an organization, with optional filters for network, product type, serial, tags, and status.

Instructions

List the availability information for devices in an organization. (read-only)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationIdYesOrganization ID
perPageNoThe number of entries per page returned. Acceptable range is 3 - 1000. Default is 1000.
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 parame
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 paramete
networkIdsNoOptional parameter to filter device availabilities by network ID. This filter uses multiple exact matches.
productTypesNoOptional parameter to filter device availabilities by device product types. This filter uses multiple exact matches. Valid types are wireles
serialsNoOptional parameter to filter device availabilities by device serial numbers. This filter uses multiple exact matches.
tagsNoAn optional parameter to filter devices by tags. The filtering is case-sensitive. If tags are included, 'tagsFilterType' should also be incl
tagsFilterTypeNoAn optional parameter of value 'withAnyTags' or 'withAllTags' to indicate whether to return devices which contain ANY or ALL of the included
statusesNoOptional parameter to filter device availabilities by device status. This filter uses multiple exact matches.
fieldsNoReturn only these top-level fields; omit for all. Available: mac, name, network, productType, serial, status, tags.
Behavior2/5

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

The description only notes '(read-only)', which is a behavioral trait. With no annotations provided, the description carries the burden, but it fails to disclose pagination behavior, filtering nuances, data freshness, or any side effects. The minimal transparency is insufficient for a tool with 11 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 sentence with no fluff. However, it is almost too concise given the tool's complexity, lacking any hint about common filters or usage patterns. Still, it avoids unnecessary verbiage.

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 11 parameters, no output schema, and no annotations, the description provides only the bare minimum. It does not explain return values, pagination behavior, or how to combine filters effectively. For a list tool, this is notably incomplete.

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% according to context signals, so the input schema already documents all parameters thoroughly. The description adds no additional parameter meaning beyond the schema, resulting in a baseline score.

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 ('List'), resource ('availability information'), and scope ('devices in an organization'). It is specific enough to distinguish from sibling tools like 'get-organization-devices-statuses' which cover statuses, not availabilities. However, it does not explicitly differentiate itself from similar list tools.

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. It lacks any context about prerequisites, typical use cases, or when not to use it. The description is purely operational.

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

Install Server

Other Tools

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/Flagler-County-BoCC/mcp-meraki'

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