Gear MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Gear MCP Server which devices are offline at the Madrid warehouse?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 |
| Which sites do I have? |
| Which devices are in this site, and which are offline, silent or alarmed? ( |
| What is this device reading right now? Values with units, battery, open alarms, time of last data. |
| How did this temperature change between two dates? Points plus min, max and average, up to 5,000. |
| Open, closed or all alarms of a client, site, device or endpoint. |
| 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.studioor 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.LoginWithExpirationor 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-mcpClaude 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.1Endpoint
POST /mcp; health checkGET /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.1by 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-01or2026-10-01T08:00:00Z.last_data_utcis the newest reading of any of the device's endpoints, ornullif it never sent data.A battery's
percentageisnullwhen Gear has a voltage but no percentage for it; readvoltagethen. The server does not estimate one from the other.Gear returns at most 500 rows per API call.
get_endpoint_historypages for you up to 5,000 points and setstruncatedwhen there is more.list_devicescounts up to 500 open alarms per site (open_alarms_capped), andfind_devicessearches 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, orGear 8004when 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.jsnpm 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 toolsfind_devicesFind devicesARead-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 valuesBRead-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 historyARead-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 alarmsARead-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 facilityARead-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 facilitiesBRead-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
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.
Related MCP Connectors
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
Read-only access to InfluSense influencer discovery, ratings, watchlists, and reports via MCP.
Managed MCP gateway with OAuth, per-agent permissions, shared accounts and activity logs.
Provides read access to your GKE and Kubernetes resources.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables read-only access to LCM2M Caddis VM2M API for equipment, runs, telemetry, alarms, etc., via MCP tools.3120 npmMIT
- FlicenseNot gradedqualityCmaintenanceProvides read-only access to Microsoft Intune through the Microsoft Graph API, enabling MCP clients to query managed devices, apps, compliance policies, and configuration profiles.-
- AlicenseBqualityCmaintenanceEnables read-only access to Questrade accounts, portfolios, market data, transactions, technical analysis, and order history through MCP.11196 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables 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