# How to Query Your IoT Data in Natural Language

> Grounded natural-language querying for IoT: why a fluent guess is worse than an error, the two routes on TagoIO (TagoAI in the Admin and the MCP server for the assistant you already use), and the permission and privacy controls that make it deployable.

![How to Query Your IoT Data in Natural Language](https://tago.io/og/blog/query-iot-data-natural-language-ai.png)

Every IoT platform now promises that you can ask your data questions in plain language, and the promise is worth chasing. An operations manager who types "which freezers went out of range last week" gets more from that one sentence than from a query builder they were never going to learn.

But most of what gets demoed as natural-language querying is a language model producing what a plausible answer looks like, not reading your devices. A fluent guess is worse than an error message, because the guess ends up in a report. The best way to query IoT platform data in natural language is an assistant grounded in your account: one that fetches the real readings, runs the real calculation in code, and can show you exactly what it looked at.

## Grounding is the whole game

A trustworthy answer to a data question has three properties. It comes from a live query against your account, not from training data or numbers pasted into a prompt. The arithmetic happens in code, because language models are unreliable calculators. And the basis is checkable: you can see which devices and which time range produced the result. Miss any of the three and you have a demo, not a tool you would put in front of a client.

This is the gap [the Model Context Protocol closes](https://tago.io/blog/what-is-model-context-protocol-mcp-for-iot). Rather than pasting data into a prompt, the assistant calls a tool that queries your platform directly and computes on the real values.

![From a plain-English question to a grounded answer via the MCP server.](https://tago.io/images/blog/query-iot-data-natural-language-ai/natural-language-query-flow.svg)

The pattern is spreading across the industry for good reason. ThingsBoard ships an MCP server for its platform, hyperscaler AI services are being wired into device data, and open-source bridges exist for most message brokers. The protocol is the easy part now. What separates one setup from another is how much the assistant can do once it is connected, and how much configuration stands between you and the first useful answer.

On TagoIO the grounding comes in two forms, built to work together.

## TagoAI: the assistant already inside your platform

For most questions, the shortest path is the assistant that lives where your data lives. TagoAI sits in the TagoIO Admin behind the star icon in the sidebar. Open it and ask: "list every device that has not reported in 24 hours," "what was the average cold-chain temperature per route last week," "which sites used the most energy this month." The answers come from live queries against your devices, not from a cached export.

It is also context-aware. Open it from a dashboard or an Analysis script and it sees what you are viewing, so "why is this widget empty" is a complete question. No IDs to paste, no schema to describe. Beyond querying, it answers architecture questions grounded in the official documentation, inspects your Devices, Dashboards, Actions, and Analysis scripts, and runs data analysis operations across your fleet.

And it crosses a line that pure query tools cannot: it acts. When "which tanks dropped below 20 percent this week" reveals a gap in your alerting, the same conversation can draft the Analysis script that flags those tanks, written against your real variable names and payload formats rather than as a generic stub. Asking and fixing stop being separate jobs done by separate people.

For the question shapes that work best and the habits worth building around them, there is a [step-by-step walkthrough](https://tago.io/blog/use-ai-assistant-query-live-iot-device-data).

## MCP: bring the assistant you already use

The second form exists because much of your work does not happen inside an IoT platform. You write code in an editor, investigate incidents in a chat thread, and build reports wherever the conversation already is. The [TagoIO MCP server](https://docs.tago.io/docs/tagoio/tago-ai/tagoio-mcp-ai-powered-iot-data-integration) connects an external assistant such as Claude to your TagoIO account, with tools for devices, data, analyses, and dashboards.

Once connected, "pull last week's readings for the Austin site and compare them against the contract baseline" is a question you ask mid-conversation, and the answer comes from a live query rather than from whatever you last exported. For developers, this is the difference between an assistant that talks about your system and one that reads it. Setup is a one-time step, covered in [connecting Claude and other AI assistants to your IoT platform](https://tago.io/blog/connect-claude-ai-assistants-iot-platform-mcp).

## Choosing between them is the wrong question

The two are complementary, not competing. TagoAI fits work that happens in the platform: exploring data, debugging a script, building a dashboard, tightening an [Action](https://docs.tago.io/docs/tagoio/actions/). MCP fits questions that come up somewhere else: in your editor, in a longer analysis, in a workflow that spans systems beyond TagoIO.

![Two grounded paths to the same live data: a plain-language question routed either through TagoAI inside the Admin or through Claude and the MCP server, both running live queries against your TagoIO account](https://tago.io/images/blog/query-iot-data-natural-language-ai/natural-language-two-paths.svg)

Teams that run both settle into a pattern quickly. Operations people stay in TagoAI because there is nothing to install, and developers add the MCP server because their assistant is already open in another window.

## The part that makes it deployable: permissions and privacy

Natural-language tools win adoption on convenience and lose it on trust, which is why the controls matter as much as the answers.

TagoAI starts every session in read-only. It can fetch, inspect, and analyze, but it cannot change anything until you raise its permission for that session, and it never creates, edits, or deletes silently. It also acts within your own account permissions, so it cannot reach anything you could not reach yourself. Every action it takes is recorded in the Audit Log, with who ran it, when, and what changed.

On the privacy side, the default providers operate under agreements that prevent your data from being used to train their models. If you want direct control, bring your own AI provider: OpenAI, Anthropic, AWS Bedrock, Google Gemini, or OpenRouter, with your keys stored encrypted in TagoIO Secrets. Bringing your own provider also lifts the monthly prompt limit. TagoAI can be disabled per profile, and on EU-region profiles it is off by default, so the decision to send data to a model is always yours.

On the MCP side, the server acts with the token you give it. Scope that token to the use case and keep sensitive accounts on read-only tokens. The design keeps everything local except the API calls, but good token hygiene is still on you.

Two habits keep the whole thing trustworthy. Treat the assistant as a fast analyst, not an oracle: ask it to show which devices and time range it used, so you can sanity-check the basis of the answer. Grounded does not mean infallible; it means checkable. And stay in the lowest permission that fits the task.

## See it before you roll it out

The recorded webinar [AI Meets IoT: A Practical Experience with TagoAI](https://tago.io/videos/ai-meets-iot-a-practical-experience-with-tagoai) walks through this live: real questions against a real account, including the moments where checking the basis of an answer matters. Watching a session end to end is the fastest way to calibrate what to expect before you put an assistant in front of your team.

## The gate was never the data

Natural-language querying is not about replacing your dashboards. The dashboards are still the operational surface. It is about opening the data to the people who were locked out by the query language, and speeding up the people who were not. The operations manager gets their answer without waiting for a report. The engineer skips the CSV round-trip. And the integrator can offer this as a service, which is one of the clearest ways to [differentiate a managed service](https://tago.io/blog/how-to-differentiate-your-iot-managed-service) right now.

Your platform has held the answers all along. The gate was the query skill required to ask. Open TagoAI from the star icon in your Admin and ask the question your team has been routing through an engineer, or connect Claude over the MCP server and ask it from where you already work. [Start free](https://admin.tago.io) if you do not have an account yet, or [book a demo](https://tago.io/request-demo) to see it against your own use case.

[llms.txt](https://tago.io/llms.txt)