Gear MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GEAR_URL | Yes | The URL of your Gear instance, for example https://gear.cloud.studio or your own domain. | |
| GEAR_EMAIL | No | Email used together with GEAR_APP_TOKEN and GEAR_PASSWORD to log in at start. | |
| GEAR_TOKEN | No | A Gear access token for the user the assistant will act as. | |
| GEAR_PASSWORD | No | Password used together with GEAR_APP_TOKEN and GEAR_EMAIL to log in at start. | |
| GEAR_APP_TOKEN | No | Application token used together with GEAR_EMAIL and GEAR_PASSWORD to log in at start with a token that lasts 12 hours. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_facilitiesB | Facilities (sites) the user can see, with their client and location. |
| list_devicesA | 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. |
| get_deviceB | One device with the current value of each of its endpoints (number and display text with unit), battery and open alarm count. |
| get_endpoint_historyA | Readings of one endpoint between two dates, oldest first, with min/max/avg. Up to 5000 points; for long ranges ask for a shorter one or accept the truncated flag. |
| list_alarmsA | Alarms of exactly one client, facility, device or endpoint. state: open (default), closed or all. Newest first, up to 500. |
| find_devicesA | Find devices by name, network address (DevEUI, IMEI...) or serial number, across all facilities the user can see or within one. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools are clearly distinct: facilities, device details, endpoint history, alarms, and device search each target a different resource or action. The main overlap is between list_devices and find_devices, both returning device information, though their descriptions clarify facility-scoped listing versus cross-facility identifier search.
All tool names follow a consistent snake_case verb_noun pattern: list_facilities, list_devices, get_device, get_endpoint_history, list_alarms, find_devices. The verbs are predictable and the nouns map cleanly to domain resources.
Six tools is well-scoped for a read-oriented monitoring server covering facilities, devices, endpoints, and alarms. Each tool has a clear purpose and there is no apparent redundancy requiring removal.
The surface covers the core monitoring workflow: discovering facilities and devices, inspecting current device state, retrieving endpoint history, and listing alarms. Minor gaps exist, such as no dedicated facility detail or endpoint listing and no alarm lifecycle actions, but these are not severe for a read-focused server.