Skip to main content
Glama
Gear MCP Server

Gear MCP Server

Gear MCP server

An MCP server for the Cloud Studio Gear IoT platform. It lets Claude, ChatGPT, Cursor, VS Code or any other MCP client read a Gear account: sites, devices and their status, live values, history and alarms. Ask "which freezers in the Madrid warehouse have been offline since yesterday?" and the assistant finds out on its own.

It only reads. No tool sends commands to devices or changes configuration, and every call to Gear carries the user's own access token, so the assistant sees exactly what that user sees in Gear and nothing else.

Tools

Tool

What it answers

list_facilities

Which sites do I have?

list_devices

Which devices are in this site, and which are offline, silent or alarmed? (only_problems)

get_device

What is this device reading right now? Values with units, battery, open alarms, time of last data.

get_endpoint_history

How did this temperature change between two dates? Points plus min, max and average, up to 5,000.

list_alarms

Open, closed or all alarms of a client, site, device or endpoint.

find_devices

Where is the device called "freezer 3", with address 70B3D57E… or serial SN-0042?

All six are marked read-only (readOnlyHint) for clients that ask before running a tool.

Related MCP server: intune-mcp

What you need

  • Node.js 20 or newer.

  • The URL of your Gear instance, for example https://gear.cloud.studio or your own domain.

  • A Gear access token for the user the assistant will act as. Ask your Gear administrator for:

    • an application with these API permissions: Accounts.Login, Accounts.Read, Facilities.Read, Facilities.ReadAlarms, Devices.Read and Endpoints.Read (Manager → Global → Applications);

    • a user limited to the client the assistant should see. Every answer is filtered by this user's permissions, so a user who sees one client gives an assistant that sees one client.

    With both, get a token with AdminService.LoginWithExpiration or a persistent access token. The Gear API skill explains the login in detail.

Instead of a token you can give the server GEAR_APP_TOKEN, GEAR_EMAIL and GEAR_PASSWORD: it logs in at start with a token that lasts 12 hours. This does not work for users with two-factor authentication.

Install

The package runs with npx; there is nothing to install by hand.

Claude Code

claude mcp add gear \
  --env GEAR_URL=https://gear.example.com \
  --env GEAR_TOKEN=<access token> \
  -- npx -y @cloudstudioiot/gear-mcp

Claude Desktop

Settings → Developer → Edit Config, and add to claude_desktop_config.json:

{
  "mcpServers": {
    "gear": {
      "command": "npx",
      "args": ["-y", "@cloudstudioiot/gear-mcp"],
      "env": {
        "GEAR_URL": "https://gear.example.com",
        "GEAR_TOKEN": "<access token>"
      }
    }
  }
}

Restart Claude Desktop. The six tools appear under the tools icon.

Cursor

The same mcpServers block as Claude Desktop, in ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project).

VS Code

In .vscode/mcp.json. VS Code asks for the token once and keeps it out of the file:

{
  "inputs": [
    { "type": "promptString", "id": "gear-token", "description": "Gear access token", "password": true }
  ],
  "servers": {
    "gear": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@cloudstudioiot/gear-mcp"],
      "env": { "GEAR_URL": "https://gear.example.com", "GEAR_TOKEN": "${input:gear-token}" }
    }
  }
}

Other clients

Any client that starts a local MCP server over stdio works: the command is npx -y @cloudstudioiot/gear-mcp with GEAR_URL and GEAR_TOKEN in its environment.

Running it as a remote server

The server also speaks Streamable HTTP, for a team that wants one shared server instead of one per laptop:

GEAR_URL=https://gear.example.com npx -y @cloudstudioiot/gear-mcp --http --port 3333 --host 127.0.0.1
  • Endpoint POST /mcp; health check GET /health.

  • Each request must carry the user's Gear token: Authorization: Bearer <access token>. Without it the answer is 401. The server is stateless: it keeps no sessions and no tokens, and each request runs with its own token, so two users on the same server never see each other's data.

  • It listens on 127.0.0.1 by default. To expose it, put it behind HTTPS (a reverse proxy). Tokens must never travel in clear text.

Cloud Studio does not host a public instance of this server.

Good to know

  • Times are UTC. Dates are accepted as 2026-10-01 or 2026-10-01T08:00:00Z.

  • last_data_utc is the newest reading of any of the device's endpoints, or null if it never sent data.

  • A battery's percentage is null when Gear has a voltage but no percentage for it; read voltage then. The server does not estimate one from the other.

  • Gear returns at most 500 rows per API call. get_endpoint_history pages for you up to 5,000 points and sets truncated when there is more. list_devices counts up to 500 open alarms per site (open_alarms_capped), and find_devices searches up to 200 sites.

  • Gear's errors come back as tool errors with Gear's code, for example Gear 8001: The access token is invalid or has expired, or Gear 8004 when the user has no access to what was asked.

Develop

git clone https://github.com/CloudStudioIoT/gear-mcp
cd gear-mcp
npm install
npm test          # 25 tests against recorded response shapes, no network
npm run build
GEAR_URL=... GEAR_TOKEN=... node dist/src/index.js

npm run test:isolation checks, against a real instance, that two users of different clients each see only their own data in all six tools, also when one passes the other's IDs by hand. It needs GEAR_URL, GEAR_TOKEN_A and GEAR_TOKEN_B, and only reads.

To build your own integration on the Gear API rather than through an assistant, see the Gear API skill and the API documentation.

Security

Report vulnerabilities as described in https://cloudstudioiot.com/.well-known/security.txt.

License

MIT © Cloud Studio IoT, S.L.

Available Tools

6 tools
find_devicesFind devicesA
Read-onlyIdempotent

Find devices by name, network address (DevEUI, IMEI...) or serial number, across all facilities the user can see or within one.

Inputs: query (required), facility_id.

get_deviceDevice with live valuesB
Read-onlyIdempotent

One device with the current value of each of its endpoints (number and display text with unit), battery and open alarm count.

Inputs: device_id (required).

get_endpoint_historyEndpoint historyA
Read-onlyIdempotent

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.

Inputs: date_from (required), endpoint_id (required), date_to, max_points.

list_alarmsList alarmsA
Read-onlyIdempotent

Alarms of exactly one client, facility, device or endpoint. state: open (default), closed or all. Newest first, up to 500.

Inputs: max, state, date_to, client_id, +4 more.

list_devicesList devices of a facilityA
Read-onlyIdempotent

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.

Inputs: facility_id (required), silent_hours, only_problems.

list_facilitiesList facilitiesB
Read-onlyIdempotent

Facilities (sites) the user can see, with their client and location.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 6 tools

    Disambiguation4/5

    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.

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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.

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      Enables read-only access to LCM2M Caddis VM2M API for equipment, runs, telemetry, alarms, etc., via MCP tools.
      31
      20 npm
      MIT
    • F
      license
      Not graded
      quality
      C
      maintenance
      Provides read-only access to Microsoft Intune through the Microsoft Graph API, enabling MCP clients to query managed devices, apps, compliance policies, and configuration profiles.
      -
    • A
      license
      B
      quality
      C
      maintenance
      Enables read-only access to Questrade accounts, portfolios, market data, transactions, technical analysis, and order history through MCP.
      11
      196 npm
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables authenticated, read-only access to mailbox folders, tags, message metadata, and message text via MCP, while preventing send, draft, delete, move, tag-change, contact/calendar changes, and attachment downloads.
      MIT