# myDevices MCP > 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. ## Overview - **Category:** cloud-infrastructure - **Price:** Free - **Tags:** device-management, telemetry-monitoring, sensor-data, remote-control, iot-connectivity, real-time-data ## Description 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. ## Tools ### 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_alerts Retrieves a list of active and past IoT system alerts or notifications. ### list_applications Lists all configured applications within the myDevices account structure. ### list_devices Provides a comprehensive list of every device connected to your system. ### list_sensors Lists all available sensors attached to a specific target device. ### send_command Sends an immediate, actionable command (like 'ON' or 'OFF') to a connected actuator. ## Prompt Examples **Prompt:** ``` List all my connected IoT devices. ``` **Response:** ``` Retrieving devices... I've found 5 active devices, including your Raspberry Pi and ESP32 nodes. ``` **Prompt:** ``` What is the current temperature reading from 'Sensor #1'? ``` **Response:** ``` Checking telemetry... The current temperature for Sensor #1 is 24.5°C. ``` ## Capabilities ### Device Discovery List all connected IoT devices, applications, and specific sensors associated with your deployed network. ### Telemetry Monitoring Retrieve current sensor values or historical data points to analyze the operational status of field assets. ### System Control Send direct, programmatic commands to connected actuators and hardware modules (e.g., turn a relay on/off). ### Alert Management Check the system for active alerts or notifications indicating device failures or anomalous readings. ## 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. ## Benefits - 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_data` lets 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_history` tool 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_command` lets 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. ## How It Works The bottom line is: you feed your AI client credentials, and it uses those credentials to talk directly to your hardware. 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. ## Frequently Asked Questions **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.