myDevices MCP. Monitor hardware state and run remote commands.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
Just plug in your AI agents and start using Vinkius.
myDevices MCP Server connects your AI agent directly to physical IoT hardware via Cayenne. It gives your client tools to list devices, read real-time sensor data, track historical trends, and send direct control commands to actuators in industrial settings.
What your AI agents can do
Get device
Retrieves specific details for an individual IoT device by ID.
Get sensor data
Gets the current, live reading from a specified sensor on a device.
Get sensor history
Pulls a time range of recorded data points for analysis.
List all connected IoT devices, applications, and specific sensors associated with your deployed network.
Retrieve current sensor values or historical data points to analyze the operational status of field assets.
Send direct, programmatic commands to connected actuators and hardware modules (e.g., turn a relay on/off).
Check the system for active alerts or notifications indicating device failures or anomalous readings.
Ask AI about this MCP
Supported MCP Clients
Gemini Waiting for input…
myDevices MCP Server: 8 Tools for Device Data Management
Use these tools to get device details, read current sensor values, fetch historical logs, list alerts, or remotely send commands to your entire IoT fleet.
019d75d9get device
Retrieves specific details for an individual IoT device by ID.
019d75d9get sensor data
Gets the current, live reading from a specified sensor on a device.
019d75d9get sensor history
Pulls a time range of recorded data points for analysis.
019d75d9list alerts
Retrieves a list of active and past IoT system alerts or notifications.
019d75d9list applications
Lists all configured applications within the myDevices account structure.
019d75d9list devices
Provides a comprehensive list of every device connected to your system.
019d75d9list sensors
Lists all available sensors attached to a specific target device.
019d75d9send command
Sends an immediate, actionable command (like 'ON' or 'OFF') to a connected actuator.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with myDevices, then connect any of our 4,700+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 4,700+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
What you can do with this MCP connector
You connect your AI agent directly to physical IoT hardware using this server. It's how you let your client read live data and send commands out to industrial gear. This isn't just a dashboard; your agent gets tools that talk straight to the devices.
Device Discovery & Mapping
To figure out what gear you've got running, you start with listing everything available. You can use list_devices to get a complete roster of every device connected to your system. If you need more detail on one specific unit, call get_device using its ID for granular specs. For the apps running on these devices, list_applications shows you all configured operational structures.
Furthermore, if you want to know what sensors are attached to a single piece of hardware, list_sensors pulls that list right up. When your agent knows which sensors exist, it can then use get_sensor_data to grab the current reading or get_sensor_history to pull back a time range of recorded data points for analysis.
Telemetry Monitoring & Analysis
Monitoring means more than just looking at a number. Your agent handles two main types of data retrieval. First, it grabs the live readings by executing get_sensor_data against any specified sensor on a device. Second, when you need to track trends or spot slow drifts over time, you run get_sensor_history.
This tool pulls back continuous records for deep analysis. For operational status checks, your agent also runs list_alerts, giving it immediate access to both active and past system notifications that signal problems or anomalies.
System Control & Action
This server lets your AI client act like a technician on site. You don't just read data; you control the environment. When you need an actuator—like a relay, pump, or valve—to change state, your agent executes send_command. This sends an immediate, actionable command (say, 'ON,' 'OFF,' or a specific value) straight to the connected hardware module.
It's direct control.
Basically, you let your client do this full loop: Use list_devices and list_sensors to map everything out; use get_device for specs; monitor with get_sensor_data or get_sensor_history; check system health via list_alerts, and finally, use send_command when it's time to make a change.
How myDevices MCP Works
- 1 First, subscribe to the myDevices server and provide your four required credentials: Client ID, Client Secret, Username, and Password.
- 2 Second, prompt your AI agent with a specific request (e.g., 'What is the temperature at Site B?').
- 3 Third, the agent runs the necessary tool (
get_sensor_data) and returns the current physical measurement or status update.
The bottom line is: you feed your AI client credentials, and it uses those credentials to talk directly to your hardware.
Who Is myDevices MCP For?
Field Operations Engineers who hate checking ten different web dashboards. Data Scientists building models that need real-world inputs, not just CSVs. Industrial Automation Specialists needing a single API layer for monitoring and command execution.
Checks device status and sends immediate commands using send_command when an alarm triggers.
Retrieves large sets of historical data using get_sensor_history to train predictive maintenance models.
Uses the agent to list all installed devices (list_devices) and verify their current status without visiting the site.
What Changes When You Connect
- Get instant device status by calling
list_devices. You don't have to navigate multiple screens just to know what hardware is active on site. This gives you a clean, immediate list of all connected units. - Stop guessing if the equipment works. Using
get_sensor_datalets your agent pull the live reading—like temperature or pressure—in seconds, letting you confirm real-time performance from anywhere. - Build trends without leaving the chat. The
get_sensor_historytool pulls structured data over time, giving you the raw numbers needed to spot drift or failure patterns months after they happened. - Take action immediately. Instead of having to manually log into a dashboard and click 'Activate',
send_commandlets your agent send an ON/OFF signal directly when it detects an issue. - Centralize monitoring. You can cross-check device health by running
list_alerts. This ensures that any failure or anomaly is flagged immediately, whether the sensor itself failed or the network dropped out.
Real-World Use Cases
The Pump Failure Check
A field manager notices a critical pump hasn't reported in an hour. They ask their agent to check the status. The agent first runs list_devices to confirm the device ID, then uses get_sensor_data on the pressure sensor. If the reading is zero, they immediately run send_command to cycle power, solving the issue without a truck roll.
Quarterly Efficiency Audit
A data scientist needs to prove that an HVAC system was overheating last quarter. They use their agent to call get_sensor_history, pulling temperature logs for the last 90 days. This bulk data bypasses manual dashboard exports and feeds directly into their analytics pipeline.
New Site Deployment Checklist
An ops engineer is setting up a new site. They run list_sensors on the primary device to confirm every required component (temp, humidity, power) is connected and available before they even turn it on.
Identifying System-Wide Failures
A user reports intermittent outages. The agent first calls list_alerts to see if the system flags any known issues across all devices, then uses get_device for specific units mentioned in the alerts to narrow down the source.
The Tradeoffs
Checking data point-by-point
The user tries to get a temperature reading by calling get_sensor_data five times in quick succession, which hits rate limits and gives incomplete information.
→
Don't call the tool repeatedly. If you need multiple data points over time, use get_sensor_history. This pulls the full dataset for analysis in one request.
Assuming device status
The user assumes a pump is running because it was on yesterday and skips checking alerts or live data.
→
Always check list_alerts first. Then confirm the current state using get_sensor_data. Only then should you decide if a command needs to be run via send_command.
Ignoring device structure
The user tries to get sensor data without knowing which sensors are available on the target unit.
→
You must first call list_sensors using the specific device ID. This tells you exactly what measurements are possible before you run get_sensor_data.
When It Fits, When It Doesn't
Use this server if your workflow requires interacting with physical, remote hardware—if the data point or action needs to exist outside of a database (e.g., 'Is the light on?' or 'Turn off the valve'). Don't use it if you only need to check internal records, like user permissions or billing history; for that, look for a dedicated CRM tool. If your goal is purely predictive analysis without any immediate action required, focus on get_sensor_history. But remember: this server gives you both the data and the ability to act on it using send_command.
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by myDevices. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This server provides 8 capabilities that interface natively with Claude, ChatGPT, Cursor, and any MCP client. No middleware. No custom integration required.
Available Capabilities
Checking equipment status shouldn't require three different tabs and a spreadsheet export.
Today, checking a remote system involves logging into the main dashboard, clicking 'Devices,' finding the specific unit ID, then opening another tab to view telemetry data. If you need historical context, you copy that data into Excel and manually check for gaps—it's slow and prone to copy-paste errors.
With this myDevices MCP server, your agent handles it all. You just ask, 'What was the average temperature over the last week?' The system uses `get_sensor_history` to pull structured data directly into your chat window. No tabs, no spreadsheets, just the answer.
myDevices MCP Server: Run remote commands instantly.
Before this server, if a warning came in—say, high humidity—you'd have to manually find the corresponding control panel and execute the reset sequence. This was slow, required human intervention, and often failed when people were running multiple tasks.
Now, your agent monitors the data stream. When `get_sensor_data` reports a critical threshold breach, it triggers the next step: calling `send_command`. The system reacts automatically, closing the loop from detection to correction in seconds.
Common Questions About myDevices MCP
How does myDevices MCP Server handle device credentials? +
You provide your Client ID, Secret, Username, and Password during setup. The agent uses these stored credentials when running any tool like list_devices or send_command to authenticate against the Cayenne system.
Can I get historical data for a whole site? +
Yes, you use the get_sensor_history tool. This allows you to specify date ranges and sensors across multiple devices to build large datasets for trend analysis.
What's the difference between `list_devices` and `get_device`? +
list_devices gives you a roster of every unit connected (the inventory). get_device lets you drill down into one specific device to read its unique details.
Is the command sent by `send_command` guaranteed to work? +
The tool sends the command programmatically. Success depends on the physical state of the actuator and whether it's powered on, so always verify results with a subsequent call to get_sensor_data.
If I use `send_command`, how does the server handle failed or unsupported device commands? +
The tool returns an explicit error status code upon failure. You must check the returned HTTP status and any included payload details to understand why the command failed—whether it's a timeout, invalid format, or hardware rejection.
When I run `list_sensors`, what key metadata do I get for each device sensor? +
You receive crucial identifiers and current status data. Specifically, the response provides the sensor's unique ID, its name, the type of data it measures (e.g., temperature), and sometimes a timestamp for the last reading.
Are there rate limits when repeatedly calling `get_sensor_data` across multiple devices? +
Yes, rate limiting is in effect to protect the telemetry service. You must manage your calls; exceeding the allowed requests per minute requires implementing an exponential backoff strategy in your agent's code logic.
What does `list_applications` show me, and how do these relate to my physical devices? +
This tool lists all configured software services or application layers tied to your IoT account. It shows the organizational structure—the high-level logic that runs alongside the data coming from your physical hardware.
How do I get my API credentials? +
Register a developer account at mydevices.com and create a new application in the developer portal to get your Client ID and Secret.
Does this work with Cayenne LPP? +
Yes, as long as the data is correctly indexed in the Cayenne dashboard, this server can retrieve it via the REST API.
Use it with your favorite AI tools
Connect this server to Cursor, Claude, VS Code, and more.
More in this category
Tyk
Manage your Tyk API Gateway and Dashboard — create keys, manage security policies, and list API definitions via natural language.
Cloudify
Orchestrate cloud infrastructure via Cloudify — manage blueprints, deployments, and monitor workflow executions directly from any AI agent.
Dotenv Parser Engine
Parse .env file content into structured JSON. Handles quotes, multiline values, and comments deterministically.
You might also like
Formilla
Chat with website visitors in real time and use AI chatbots to qualify leads and answer common questions automatically.
Flodesk
Design gorgeous email campaigns with intuitive templates that grow your audience and reflect your brand without design skills.
EmailListVerify
Equip your AI agent to verify email deliverability, manage bulk verification jobs, and track credits via the EmailListVerify API.