Ask any IoT vendor about AI today and you will get a confident yes. The product page has a new badge, the demo has a chat box, and the sales deck has a slide about working smarter. And the promise is appealing: type a question in plain language, get an answer about your fleet, your sensors, your alarms.
But most of what gets labeled “AI integration” is a chatbot bolted onto a dashboard. It can answer questions inside that one screen, and it stops there. The real question for a buyer is different: can an external assistant you already use, like Claude or ChatGPT, reach your live IoT data through an open standard and actually do something with it? That is a much narrower set of products than the marketing suggests.
Therefore this is a guide to the whole field. We will sort it into three honest categories, lay out the pros and cons of each, give you a checklist of questions to ask any vendor, and a short decision guide by buyer type. The goal is to help you tell real integration from a badge.
Three categories of “AI assistant integration”
Almost every claim you will read falls into one of three buckets. They are not equally capable, but each one is the right answer for some teams.
1. Native MCP server
The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data. When a platform ships its own MCP server, any MCP-compatible assistant can connect to your account and work with your data over that standard. No custom integration project required.
This is the category TagoIO sits in. The TagoIO MCP server works with Claude, ChatGPT, Cursor, and Windsurf. You can ask natural-language questions about your devices and data, and the assistant can generate Analysis scripts and build dashboards on your behalf. Version 3.0.0 added remote HTTP support, so the server does not have to run on your own machine.
The advantage is access without a build. The assistant you already use becomes a way to query and operate the platform. The trade-off is that you are committing to the open standard the platform supports, and you should confirm what the server is actually allowed to read and do on your behalf.
2. Open REST API you wire yourself
Plenty of platforms expose a documented REST API and nothing AI-specific on top of it. Cloud services like AWS IoT Core, or a self-hosted ThingsBoard instance, give you full programmatic access to your data. You can connect that API to an assistant yourself, either with custom glue code or by writing your own MCP wrapper around the endpoints you care about.
This works. If you have engineers and you want full control over exactly what the assistant can touch, it is a clean path. You decide the scope, the auth, and the behavior. The cost is that it is build-it-yourself. Someone has to write the wrapper, maintain it as the API changes, and own the security of the credentials it holds. For a team with the right people, that ownership is a feature, not a burden.
3. Built-in chatbot only
The third category is the one that gets the most marketing and the least scrutiny. A built-in chatbot lives inside the platform UI. It can answer questions, summarize a dashboard, sometimes draft a query, all from within that one screen.
For non-technical users this can be genuinely useful. It lowers the bar to getting an answer without learning the query language. The limit is structural: the assistant cannot be reached by your external tools. If your workflow lives in Claude, or in an agent you are building, or in a chat client your team already runs, the built-in bot does not connect to any of it. It is a feature of the dashboard, not an integration with your stack.
How the three approaches compare
| Native MCP server | Open REST API | Built-in chatbot | |
|---|---|---|---|
| External assistant access | Yes, over an open standard | Yes, after you build it | No |
| Build effort | None for the connection | Custom glue or your own wrapper | None |
| Who scopes credentials | The platform, by design | You | Not applicable |
| Best for | Teams wanting external AI access now | Engineering teams wanting full control | Non-technical users inside the UI |
| Main risk | Confirm what the server can read and do | Maintenance and credential ownership fall on you | Cannot leave the dashboard |
| Example | TagoIO MCP server | AWS IoT Core, self-hosted ThingsBoard | UI assistants across many platforms |
None of these is a trap. A built-in chatbot is fine if your users live in the dashboard. An API you wire yourself is fine if you have engineers and want control. A native MCP server is the shortest path to external, standards-based access. The mistake is buying one while believing you bought another.
A checklist to take into any vendor call
Vendor marketing will not draw these distinctions for you, so bring your own questions. Five of them will tell you which category you are actually looking at.
- Can an external assistant reach my data? This is the first cut. If the answer is “only inside our dashboard,” you are in category three. That may be fine, but now you know.
- Over what standard? If external access exists, ask how. An open standard like MCP means your existing assistants connect without bespoke work. A proprietary integration ties you to one vendor relationship.
- What can the assistant read, and what can it do? Read-only access to telemetry is very different from being able to create scripts, change dashboards, or trigger actions. Get the exact list.
- How are credentials scoped? Find out what token or key the integration uses, what it can touch, and whether you can limit it. Broad, unscoped access is a risk no matter how good the AI is.
- Does it run remotely or only on my machine? A server that requires a local process is harder to operate for a team. Remote support, like the HTTP mode TagoIO added in v3.0.0, makes shared use practical.
If a vendor cannot answer these clearly, that is itself an answer.
A short decision guide by buyer type
Non-technical team. If your people work inside the platform and rarely leave it, a built-in chatbot may cover the need with zero setup. If you also want answers from the assistant you already use elsewhere, look for a native MCP server.
Engineering team. If you have developers and care about controlling exactly what an assistant can do, both the native MCP and the API-you-wire-yourself paths fit. Choose native MCP to save the build; choose the API path when you need control the standard server does not give you, or when your platform offers no MCP server at all.
Integrator or solution builder. If you ship IoT solutions to clients, a native MCP server lets you give each client AI access without writing a new integration per project. An open API still matters as the foundation, but the standard connection is what scales across accounts.
The bottom line
The phrase “AI integration” covers three very different things. A native MCP server gives any compatible assistant access to your data over an open standard, with no integration project. An open REST API gives you the same outcome if you are willing to build and maintain the connection. A built-in chatbot helps users inside the dashboard but cannot be reached from outside it.
TagoIO chose the native MCP path so that the assistants your team already runs, Claude, ChatGPT, Cursor, Windsurf, can query your data, write Analysis scripts, and build dashboards directly. If that matches how you work, the checklist above will help you confirm any vendor’s claim, including ours.
Resources
- What Is the Model Context Protocol (MCP) for IoT, the explainer on the standard behind native integrations
- How to Connect Claude with MCP, a step-by-step how-to
- TagoIO MCP documentation
- TagoIO pricing
