Particle IoT MCP. Control Actuators and Read Live Sensor Telemetry.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
Just plug in your AI agents and start using Vinkius.
Particle IoT connects your AI agent directly to physical hardware. You read real-time sensor data (temp, moisture), check device status, and run remote functions on actuators—all through natural conversation.
It’s a fleet manager for your entire connected device setup.
What your AI agents can do
Call function
Runs pre-written firmware commands on a specific device, such as activating a pump or starting a calibration cycle.
Get device info
Retrieves the specific capabilities and variables for a single device so you know what it can actually do.
Get devices
Lists all connected devices, including their IDs, names, firmware versions, and last connection time.
Retrieves IDs, names, and connection status for every Particle IoT device registered to your account.
Gets the current value of any defined cloud variable, like temperature or soil moisture, from a specific unit.
Executes pre-defined firmware functions on a device—for instance, turning an irrigation pump on or triggering a system calibration.
Pings a single unit to confirm its current online status and last reported time. Essential for troubleshooting.
Sends structured events (e.g., 'low moisture alert') that external systems can listen for, triggering webhooks or logging.
Ask AI about this MCP
Supported MCP Clients
OAuth 2.0 Compatible Gemini Waiting for input…
Particle IoT MCP Server: 8 Tools for Device Monitoring
Use these tools to discover devices, read sensor data, run remote functions on hardware, and publish system events.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using Particle IoT on Vinkius019d75efcall function
Runs pre-written firmware commands on a specific device, such as activating a pump or starting a calibration cycle.
019d75efget device info
Retrieves the specific capabilities and variables for a single device so you know what it can actually do.
019d75efget devices
Lists all connected devices, including their IDs, names, firmware versions, and last connection time.
019d75efping device
Checks if a specific device is currently online and responsive by returning its latest status heartbeat.
019d75efpublish event
Sends a custom, named event to the cloud for logging or triggering alerts in external systems.
019d75efread variable
Gets the current measured value (e.g., 68%) of any sensor variable defined on a specific device.
019d75efrename device
Changes the user-facing name of a device for better organization in your fleet management console.
019d75efunclaim device
Permanently removes an owned device from your account, typically used during asset transfer or decommissioning.
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 Particle IoT, then connect any of our 4,800+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 4,800+ 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
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by Particle IoT. 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.
Manual device checks slow down field ops.
Today, checking a remote facility means jumping between the cloud dashboard and the API documentation. You check status via one tab, read sensor data in another, and then write separate code to trigger an action. It's clicks, copy-pasting credentials, and switching mental context.
With this MCP server, you simply ask your agent: 'Check the humidity at Unit 4, and if it drops below 60%, turn on the dehumidifier.' The agent handles listing devices (`get_devices`), reading the variable (`read_variable`), and then running the function (`call_function`). You just get the result.
Particle IoT MCP Server: Control device functions from chat.
Before, controlling a pump required knowing the exact API endpoint, the required parameter structure (e.g., '900' for 15 minutes), and handling potential authentication errors—all before you could even ask it to run. Now, your agent handles all that complexity behind the scenes. You just say what needs to happen, and the server routes the command through `call_function` and executes it.
What you can do with this MCP connector
Listen up. This Particle IoT MCP Server connects your AI client directly to physical hardware, giving you full remote control over any connected device setup. You're not just reading data; you're managing an entire fleet of machinery through plain conversation. It handles everything from checking a single sensor reading to running complex firmware cycles on multiple units.
When you use this server, your AI agent can immediately get the layout of your hardware with get_devices, listing every connected unit by its ID, name, current firmware version, and when it last checked in. You'll also find that for a deeper dive into a specific machine's parameters, running get_device_info pulls up all its unique capabilities and variables right away.
If you need to quickly check if a single unit is alive or responsive, use ping_device. It runs a simple heartbeat check on any specified device, giving you an instant status report. If the connection seems spotty, you can also get granular details about connectivity using get_device_info.
For monitoring actual sensor data, your agent calls read_variable, which pulls the live measurement—like temperature or soil moisture percentages—from any cloud variable defined on a particular device. You don't have to guess what it measures; you just ask for the specific variable and get the number back.
When you need to make something do stuff, call_function runs pre-written firmware commands directly on the hardware. This means activating an irrigation pump or kicking off a system calibration cycle with a single command. You've got total control over the physical actuators.
For keeping your data clean and organized, you can use rename_device to change the user name of any device in the fleet management console. If a piece of gear is retired or sold off, running unclaim_device permanently removes it from your account.
To send alerts that outside systems need to listen for—say, 'low battery' or 'overheat detected'—you use publish_event. This sends a custom, named event directly to the cloud, triggering webhooks or logging in whatever external system you run. Finally, if you just want to make sure your AI client is aware of all connected units and their current IDs, names, and status, running get_devices gives that full inventory list.
019d75ef-aa24-722f-998c-b79a2c6537b0 
How Particle IoT MCP Works
- 1 Subscribe to the Particle IoT MCP Server and provide your unique Particle Access Token.
- 2 Your AI client uses natural language (e.g., 'What is the temperature at Sensor X?').
- 3 The server maps the request to the appropriate tool (
read_variable) and returns the raw sensor data or execution result.
The bottom line is, your agent handles all the networking plumbing so you talk to physical hardware like it's a database query.
Who Is Particle IoT MCP For?
Anyone dealing with physical infrastructure. This isn't for developers writing simple scripts; this is for the ops engineer who needs real-time telemetry and remote control from a chat interface, or the agronomist running fieldwork checks without driving to the site.
Monitors soil moisture levels across multiple fields and triggers irrigation pumps remotely based on read sensor data.
Reads environmental sensors (temp, humidity) in a building's HVAC system and runs diagnostic checks when equipment fails unexpectedly.
Tests device functions and prototypes complex interactions—like reading variable A then calling function B—without writing repetitive API glue code.
What Changes When You Connect
- Read live data without boilerplate. You don't need to write complex API calls to know what the soil moisture is; just ask, and
read_variablegives you the current percentage. - Full remote control of physical hardware. Need to turn on the main pump? Use
call_function. The agent handles sending the command directly to the device firmware. - Immediate health checks. Instead of guessing if a unit is dead, run
ping_device. It confirms connectivity and tells you when it last checked in. - Structured alerting. When conditions change (e.g., water level drops), use
publish_eventto send an alert that external systems can immediately act on. - Manage the fleet easily. Use
get_devicesto see every unit connected, and userename_deviceso your reports read 'Greenhouse Pump' instead of 'Particle-XYZ123'.
Real-World Use Cases
Diagnosing a stalled pump
The agent first runs get_devices to list all pumps. It notices the main pump is offline, so it calls ping_device. The failure confirms network trouble, saving hours of troubleshooting.
Automating crop monitoring
A user asks for a status check: 'Is the field ready?' The agent runs read_variable for soil moisture and temperature. If levels are low, it uses call_function to activate the irrigation pump.
Transferring assets
You're selling a sensor node. Instead of logging into the console, you ask your agent to run unclaim_device. The server handles the permanent removal from your inventory.
System reporting and logging
When the main valve status changes, instead of just reading it, the system uses publish_event with a custom 'ValveOpen' event name. This feeds into a separate dashboard for historical tracking.
The Tradeoffs
Polling everything constantly
Trying to monitor 50 devices by repeatedly calling get_devices every minute. This burns bandwidth and hits API rate limits.
→
Instead, rely on targeted reads or events. Use a combination of ping_device for status checks, and have the device proactively send state changes via an external system that listens for publish_event.
Treating it like a simple database query
Assuming every variable is available everywhere. You might try reading 'SoilMoisture' from a weather station, which doesn't have the sensor.
→
Always start with get_device_info to confirm what variables and functions are actually exposed by that specific device before you try to read or write anything.
Manually updating names
Having to log into the Particle console just to change 'Sensor 1' to 'North Field Sensor'. This is slow and requires context switching.
→
Use rename_device via your agent. It handles the API call in a single chat step, keeping your workflow entirely within the AI client.
When It Fits, When It Doesn't
Use this server if your core problem involves physical state: reading sensors, operating pumps, or tracking hardware assets. You need to talk to things that exist outside of traditional IT infrastructure.
Don't use it if you just need to query user data (like a CRM) or run code logic based solely on text input; those systems require different tools. If your task is purely about sending messages between people, don't bother—use a dedicated messaging service instead. This tool is for the physical layer. It works best when you combine get_device_info first (to understand what’s possible), then use read_variable or call_function (to act on it).
Common Questions About Particle IoT MCP
How do I find out what sensors a specific device can read using Particle IoT MCP Server? +
You use the get_device_info tool. It returns detailed information about the unit, including all available variables and functions you can interact with.
Can I check if my whole fleet is connected using Particle IoT MCP Server? +
Yes, use get_devices. This lists every single device ID in your account, along with its current online status and firmware version.
What's the difference between `read_variable` and `ping_device`? +
ping_device only checks if the unit is alive (online/offline). read_variable actually pulls a specific piece of data—like temperature or soil moisture—from that live sensor reading.
How do I make sure my AI agent sends an alert when something happens? +
You use the publish_event tool. This allows you to broadcast a structured message (an event) that external systems can listen for, triggering webhooks or logging immediately.
What if I need to change the name of one device? +
Run the rename_device tool. It updates the friendly display name in your console and API responses, making it easier to identify for future commands.
What's the process if I need to transfer or remove a device using `unclaim_device`? +
It permanently removes the device from your account. You must use unclaim_device when you intend to sell it or decommission it entirely. The action is irreversible, so confirm ownership changes before running this tool.
Before I call a function on a specific gadget, how do I check its capabilities using `get_device_info`? +
Run get_device_info first. This tells you exactly what variables and functions the device supports. Check this output to find the correct method name and required arguments for your task.
Can I use `publish_event` to send an alert that isn't read by a physical sensor? +
Yes, publish_event sends data to all subscribed listeners. You can configure external webhooks or logging systems to catch these events. This lets you trigger actions outside the IoT network.
Can my AI read sensor data from my Particle devices? +
Yes! Use the read_variable tool with your device ID and the variable name (e.g., temperature, humidity, soilMoisture). Your device must expose this variable in its firmware using Particle.variable(). The AI will return the current sensor value in real-time. You can find available variables using get_device_info.
How do I remotely turn on a pump or actuator connected to a Particle device? +
Use the call_function tool with your device ID and the function name (e.g., pumpOn, valveOpen). The function must be exposed in your device firmware using Particle.function(). You can pass an optional argument (like duration or intensity) to control the actuator behavior. Check available functions with get_device_info.
Can I check if my IoT device is online and responding? +
Yes! Use the ping_device tool to instantly check the online status of any Particle device. You can also use get_devices to see the online status of all your devices at once. If a device shows as offline, it may be powered off, disconnected from Wi-Fi, or experiencing firmware issues.
Use it with your favorite AI tools
Connect this server to Cursor, Claude, VS Code, and more.