Skip to main content
Glama
Sign In
Gear MCP Server

Gear MCP Server

by CloudStudioIoT
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List devices of a facility

list_devices
Read-onlyIdempotent

Retrieves devices for a facility with online/offline status, hours since last data, and open alarms; use only_problems to show just offline, silent, or alarmed devices.

Instructions

Devices of a facility with online/offline status, hours since last data and open alarms. Use only_problems to get just the offline, silent or alarmed ones.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "facility_id": "<facility_id>"
    },
    "name": "list_devices"
  }
}

Input Schema

NameRequiredDescriptionDefault
facility_idYes
silent_hoursNoHours without data to call a device silent (default 24)
only_problemsNoOnly devices that are offline, silent or have open alarms

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare this a safe, idempotent, read-only, open-world operation, so the safety bar is low. The description adds that results carry status, staleness (hours since last data), and alarm state, but says nothing about result volume, ordering, or pagination behavior for a facility with many devices.

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?

Two short sentences, zero filler, with the returned fields stated first and the filter hint second. It is written as a compressed noun phrase rather than a full clause, which is terse but still readable and front-loaded.

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?

For a three-parameter read tool with no output schema, the description usefully covers both what comes back and the primary filtering lever. The remaining gap is sibling disambiguation against find_devices, plus no hint about result size or ordering.

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 67%: silent_hours and only_problems are documented in the schema, while facility_id has no description at all (only implied by 'of a facility'). The description ties the word 'silent' to the staleness concept, but adds no format, default, or range detail beyond what the schema already states.

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 names a specific resource (devices) and scope (of a facility), plus what the listing surfaces: online/offline status, hours since last data, and open alarms. It is clear what the tool returns, though the verb is only implicit and it never distinguishes itself from the sibling find_devices.

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?

It gives one concrete usage rule — set only_problems to narrow to offline, silent, or alarmed devices — which is real guidance for a key parameter. However, there is no guidance on when to prefer this over find_devices or get_device, so the agent must infer the choice between siblings.

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