Your devices are reporting. Temperatures, battery levels, locations, uptime, all of it is flowing into your TagoIO account and sitting there, queryable. And when someone on your team asks a simple operational question, the data to answer it already exists.
But getting the answer is rarely as simple as the question. “Which devices have not checked in since yesterday?” sounds like a one-liner. In practice it means opening the platform, filtering devices, checking last-input timestamps, maybe writing a small Analysis script or laying out a dashboard widget. The data is right there, but the path from question to answer still runs through query-building, scripting, or dashboard work.
Therefore: connect an AI assistant to your TagoIO data over the Model Context Protocol, and you can just ask. The TagoIO MCP server links assistants like Claude, ChatGPT, and Cursor directly to your deployment. You type the question in plain English, the assistant reads your actual devices and data, and it answers, or it generates the script or dashboard you would have built by hand. This post walks through what that looks like in practice.
This walkthrough assumes the MCP connection is already set up. If it is not, start with our setup guide, How to Connect Claude and Other AI Assistants to Your IoT Platform with MCP, then come back here.
Job 1: Quick status checks
The most common questions are also the simplest. You want to know the current state of your fleet without clicking through device lists.
Prompt: “Which devices have not reported in the last 24 hours?”
The assistant queries your devices through the MCP connection, checks each one’s most recent data timestamp against the last 24 hours, and returns the list. You get device names and how long each has been silent, in the chat, in a few seconds. No filter to configure, no widget to build.
This is where plain-English queries shine. The question changes slightly every time (“last 6 hours,” “only the gateways,” “in the warehouse group”), and you do not have to rebuild anything to ask the next version. You just type it.
Job 2: Summaries and aggregations
The next step up is asking for math across a range of data: averages, totals, counts grouped by some attribute.
Prompt: “Show me the average temperature per zone for last week.”
The assistant pulls the relevant device history, groups readings by zone, computes the average for each, and lays the result out as a small table. If you want it broken down by day instead of as a weekly average, you say so and it adjusts.
This is genuinely useful for exploration. You are poking at the data, forming a picture, deciding what matters. For a quick read on “how did last week go,” asking is faster than building a chart. Keep in mind that the assistant is summarizing what it pulls, so for anything you will report on or act on, it is worth spot-checking the numbers against the platform.
Job 3: Spotting anomalies
Sometimes the question is not “what is the average” but “what is wrong.” You are hunting for the outlier, the thing that should not be happening.
Prompt: “Which pallets in zone C have been stationary more than 72 hours?”
This is a harder question. The assistant has to look at location or movement data per device, work out how long each pallet has held its position, and filter to zone C and the 72-hour threshold. It reads your data, reasons through the condition, and gives you the list of pallets that match, with how long each has been parked.
For a one-off investigation, this beats writing a query by hand. You describe the condition in words instead of translating it into code. Just remember the assistant can make mistakes on logic like this, so if the answer drives a decision, verify a couple of the flagged items yourself before acting.
Job 4: Generating an Analysis script
Up to here the assistant has been answering questions. It can also build things. TagoIO Analysis scripts are serverless JavaScript that run on your account, and describing one in plain English is often faster than starting from a blank file.
Prompt: “Write an Analysis script that flags battery level under 15 percent.”
The assistant generates a JavaScript Analysis script that reads battery data from your devices, checks each reading against the 15 percent threshold, and flags the ones below it. It can wire the logic to an Action so a low battery triggers an alert, since Actions and alerts are part of the same platform it can see.
Here is the honest part: treat the generated script as a first draft, not a finished deployment. It gives you a working starting point and saves you the boilerplate, but you should read it, confirm it references your actual device and variable names, and test it before it runs against live data. The assistant can be wrong, and a script you have not reviewed is a script you do not trust.
Job 5: Building a dashboard
The assistant can also stand up a Blueprint Dashboard from a description, which is handy when you want a starting layout fast.
Prompt: “Build a dashboard for my cold-chain devices.”
The assistant looks at your cold-chain devices, picks relevant variables like temperature and battery, and generates a dashboard with widgets laid out for them. You get something to look at and adjust rather than an empty canvas.
This is a great way to get past the blank-page problem. But it leads straight into the most important honesty point in this whole post, so let us take that head on.
When to ask, and when to build
Natural-language queries are excellent for a specific set of jobs: ad hoc questions, exploration, one-off investigations, and generating a first draft of a script or dashboard. The strength is that you do not commit to anything. Every question can be different, and you never have to build infrastructure to ask the next one.
A saved dashboard is better for a different set of jobs. For a metric your team checks every single day, the same view every morning, a built dashboard is faster and more reliable. It loads instantly, it shows the same thing every time, it does not depend on an assistant phrasing a query correctly, and it does not cost you a round trip through a chat interface. If you find yourself asking the assistant the same question daily, that is your signal to build the dashboard once and stop asking.
So the rule is simple. Use plain English when the question is new, occasional, or exploratory. Build a dashboard or a saved Analysis when the question is recurring and operational. The two are not in competition. The assistant is often the fastest way to figure out what your daily dashboard should contain in the first place.
And on generated code: anything the assistant writes, an Analysis script or a dashboard configuration, is a draft you own. Review it, test it, confirm it matches your real device and variable names, then deploy. The assistant is a fast collaborator, not an unsupervised one.
What the assistant can reach
When connected over MCP, the assistant works against the same building blocks you use in the platform: Devices and their history and data, Analysis scripts, Blueprint Dashboards, Actions and alerts, and the REST API. That is why it can both answer questions about your deployment and generate the scripts and dashboards you would otherwise build by hand.
Wrapping up
The data to answer your operational questions is already in TagoIO. The friction was never the data; it was the query-building, scripting, and dashboard work between you and the answer. Connecting an AI assistant over MCP removes that friction for the questions that do not justify building anything. Ask in plain English, get the answer or a first-draft script or dashboard, and reserve your dashboard-building effort for the metrics you watch every day.
Use the assistant where it is strong, keep your saved dashboards for what they are best at, and review anything it generates before it goes live.
