If you have ever built an IoT product from scratch, you know the work is rarely the device. The device is the easy part. The hard part is everything that has to exist around it: ingestion endpoints, time-series storage that can survive a year of every-five-second uplinks, payload parsers for every firmware version you ever shipped, dashboards your customers will actually look at, alert rules that page the right person, user accounts, role-based access, white-label portals, audit trails, regional compliance, and the ten cron jobs nobody documented.
Building all that yourself is possible. Maintaining it for five years across a hundred device types is a different sport. This is where a platform like TagoIO earns its keep, and where a new piece of the stack changes how fast a single developer can move: the TagoIO MCP server, which lets Claude talk directly to your IoT account.
The “I will just build it myself” trap
Every IoT engineering lead has the conversation. The roadmap has fifty connected SKUs. Someone draws an architecture: a Kafka cluster here, Postgres with TimescaleDB there, Grafana for dashboards, Keycloak for auth, a small Node service to parse payloads, an alerts microservice, an admin UI on top, all glued together with Terraform.
Six months later, the device team is still arguing with the platform team about why ingestion drops 0.4% of packets when a region fails over. The dashboard service is on its third rewrite. Nobody can answer “what was the average humidity across the warehouse last Tuesday between 2 and 4pm?” without writing SQL. Customers are asking for a branded mobile app. The compliance team wants ISO 27001 evidence. Two engineers quit.
The platform was supposed to be a means to an end. It became the product.
A purpose-built IoT platform takes that work off your plate. Device provisioning, mutable and immutable storage, payload parsers, dashboards, actions, analysis scripts, white-label portals, multi-region, RBAC, audit logs, and the SDKs to talk to all of it ship as one product. You stop maintaining infrastructure and start shipping features.
That is the part of the story most IoT teams already understand. The newer part is what happens when you put an AI assistant on top of that platform.
What MCP actually is
Model Context Protocol (MCP) is an open standard from Anthropic that lets AI assistants like Claude talk to external systems through a defined tool interface. Instead of describing your IoT account in a long prompt, Claude calls real tools against the real system: list these devices, get this data, create this action, write this analysis script.
The TagoIO MCP server is a small program (or hosted endpoint) that exposes your TagoIO account to Claude as a set of typed tools. Claude reads the tool catalog, picks the right one for what you asked, fills in the parameters, and acts. You see the result in the chat, and the change appears in your TagoIO admin console.
The practical effect: most of the operational work you used to do by clicking around the admin UI or writing one-off scripts, you now do in plain English from your IDE.
Setup in two minutes
The TagoIO MCP server has two flavors. The remote server at https://mcp.ai.tago.io needs no install. The local option runs through npx if you want it on your machine. Both authenticate with a Profile Token from your TagoIO account at admin.tago.io/profile.
For Claude Code, one command:
claude mcp add-json @tago-io/mcp '{"type":"http","url":"https://mcp.ai.tago.io","headers":{"Authorization":"Bearer YOUR-TAGOIO-TOKEN"}}'For Claude Desktop, add this to claude_desktop_config.json:
{
"mcpServers": {
"@tago-io/mcp": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.ai.tago.io",
"--header",
"Authorization: Bearer YOUR-TAGOIO-TOKEN"
]
}
}
}Restart, and Claude can now reach your account. If you are on EU West or a dedicated TagoIO instance, add an x-tagoio-region header with eu-w1 or your full API URL.
A note on tokens: the Profile Token grants full account access and is the right pick while you are exploring. For production, switch to an Analysis Token tied to an Analysis with restricted scope. Same MCP server, narrower blast radius.
What the MCP server can actually do
The current server (v3) groups tools into a handful of services. The coverage is wide enough that most day-to-day work fits inside it.
Devices. device-operations handles lookup, create, update, delete, and configure. You can search by name (wildcard matching is built in), by tag, by connector, by network, by active state. device-data-operations runs queries with aggregations: avg, sum, min, max, count, and conditional. Time grouping goes from minute to year. device-delete-data removes data from a device when you need it.
Actions. action-operations covers the full CRUD on TagoIO Actions, the rules that trigger when a device sends data matching a condition. Email alerts, webhooks, analysis triggers, the lot.
Analysis. analysis-operations reads, writes, and updates Analysis scripts (the Node.js code TagoIO runs server-side for you). Paired with tagoio-code-search, Claude can generate Analysis code with the right TagoIO SDK calls instead of hallucinating an API shape. tagoio-documentation-search looks up TagoIO docs on demand.
Entities. entity-operations and entity-data work with TagoIO Entities, the relational layer for non-time-series data: customer records, asset hierarchies, configuration tables.
Integration, profile, RUN users. integration-lookup finds connectors and networks. profile-lookup and profile-metrics give account state and usage. user-lookup works against TagoRUN users for white-label deployments.
That is enough surface area to manage a fleet, debug a device, build an alert, write a server-side script, and check your account health, all from the same chat.
What this looks like in practice
A few examples of what an IoT engineer can now do without leaving their IDE.
Find a misbehaving device.
“Show me all devices in the warehouse-east connector that have not sent data in the last 24 hours and are still marked active.”
Claude calls device-operations with operation: lookup, filters by connector, then cross-checks last_input on each. You get the list back as a table.
Pull historical data without writing SQL.
“What was the average and max temperature for device Cold Storage 04 between November 1st and November 15th, grouped by day?”
Claude calls device-data-operations with the device ID, the variable temperature, aggregation avg and max, time bucket day, and the date range. The reply has the numbers. If you want a chart, ask for one.
Provision a new device with a parser.
“Create a new mutable device called Boiler Sensor 12, tag it region:north and type:boiler, attach the LoRaWAN connector we use for the boiler line, and set the payload parser to base64-decode the first four bytes as temperature in tenths of a degree.”
Claude resolves the connector through integration-lookup, calls device-operations with operation: create, and writes the parser inline.
Write an Analysis script that would normally take an hour.
“Write an Analysis script that runs every hour, looks at every device tagged type:boiler, and if the average pressure over the last hour is above 4.5 bar, sends an email to ops and creates a TagoIO Action with the device flagged as at-risk.”
Claude pulls the SDK shape via tagoio-code-search, drafts the script, and creates it through analysis-operations. You review the code in chat and ship it.
Audit before a customer demo.
“List every Action on the account, group by trigger type, and tell me which ones have not fired in the last 30 days.”
action-operations with lookup, then profile-metrics to cross-reference activity. Five seconds of work that used to be a thirty-minute manual review.
None of these are demos. They are the same operations IoT teams already do every week, compressed from clicks-and-tabs to a sentence.
Why the platform underneath still matters
The MCP server is impressive, but it is downstream of a more important point: it works because TagoIO already has typed APIs for every concept that matters in IoT. Devices, data, actions, analyses, entities, users, connectors, networks. The MCP server is a thin layer that exposes those APIs to an AI. If you had built your own platform, you would now also be building your own MCP server on top of your own undocumented internal services. That is another quarter of work before the AI helps you with anything.
This is the part to take seriously when planning an IoT product. The platform decision sets the ceiling on how fast everything else can move, including the AI tooling that is going to be standard within two years. A general-purpose cloud database plus a pile of microservices does not give an AI assistant anywhere clean to plug in. A purpose-built IoT platform does.
You do not need an AI to justify TagoIO. The full-stack IoT platform stands on its own: dashboards, RBAC, mobile, multi-region, the whole package, simple to start and affordable at scale. But once you add Claude on top through MCP, the daily work of running a fleet stops looking like ops and starts looking like conversation. That is the real shift.
Try it
If you already have a TagoIO account, generating a token and connecting Claude takes about two minutes. If you do not, the free tier is enough to see the loop end-to-end with a couple of test devices.
The TagoIO MCP server is open source at github.com/tago-io/mcp-server. The docs cover every IDE and AI tool that supports MCP today: VS Code, Cursor, Windsurf, Claude Code, Claude Desktop, JetBrains, Gemini CLI, Amazon Q, OpenAI Agents, Warp, Kiro. Pick one, paste the config, point Claude at your fleet, and ask it something you would normally have done by hand.
Build the product, not the platform.
