Si alguna vez construiste un producto de IoT desde cero, sabes que el trabajo rara vez está en el dispositivo. El dispositivo es la parte fácil. Lo difícil es todo lo que tiene que existir a su alrededor: endpoints de ingestión, almacenamiento de series temporales capaz de sobrevivir a un año de uplinks cada cinco segundos, parsers de payload para cada versión de firmware que enviaste, dashboards que tus clientes realmente vayan a mirar, reglas de alerta que avisen a la persona correcta, cuentas de usuario, acceso basado en roles, portales white-label, registros de auditoría, cumplimiento regional y los diez cron jobs que nadie documentó.
Construir todo eso por tu cuenta es posible. Mantenerlo durante cinco años a través de cien tipos de dispositivos es otro deporte. Aquí es donde una plataforma como TagoIO demuestra su valor, y donde una nueva pieza del stack cambia la velocidad a la que un solo desarrollador puede avanzar: el servidor MCP de TagoIO, que permite a Claude hablar directamente con tu cuenta de IoT. Para un recorrido rápido de lo que eso habilita en la práctica, consulta Crea soluciones IoT más rápido con Claude y el MCP de TagoIO.
La trampa del “lo construyo yo mismo”
Todo líder de ingeniería de IoT tiene esta conversación. El roadmap tiene cincuenta SKUs conectados. Alguien dibuja una arquitectura: un cluster de Kafka aquí, Postgres con TimescaleDB allá, Grafana para dashboards, Keycloak para autenticación, un pequeño servicio en Node para parsear payloads, un microservicio de alertas, una UI de administración encima de todo, y todo pegado con Terraform.
Seis meses después, el equipo de dispositivos sigue discutiendo con el equipo de plataforma sobre por qué la ingestión pierde el 0,4% de los paquetes cuando una región hace failover. El servicio de dashboards va por su tercera reescritura. Nadie puede responder “¿cuál fue la humedad promedio en el almacén el martes pasado entre las 2 y las 4 de la tarde?” sin escribir SQL. Los clientes piden una app móvil con marca propia. El equipo de cumplimiento quiere evidencia de ISO 27001. Dos ingenieros renuncian.
La plataforma debía ser un medio para un fin. Se convirtió en el producto.
Una plataforma de IoT construida con un propósito específico te quita ese trabajo de encima. El aprovisionamiento de dispositivos, el almacenamiento mutable e inmutable, los parsers de payload, los dashboards, las acciones, los scripts de análisis, los portales white-label, el soporte multirregión, el RBAC, los registros de auditoría y los SDKs para hablar con todo eso vienen como un solo producto. Dejas de mantener infraestructura y empiezas a entregar funcionalidades.
Esa es la parte de la historia que la mayoría de los equipos de IoT ya entiende. La parte más nueva es lo que ocurre cuando pones un asistente de IA encima de esa plataforma.
Qué es MCP en realidad
El Model Context Protocol (MCP) es un estándar abierto de Anthropic que permite a asistentes de IA como Claude hablar con sistemas externos a través de una interfaz de herramientas definida. En lugar de describir tu cuenta de IoT en un prompt larguísimo, Claude llama a herramientas reales contra el sistema real: lista estos dispositivos, obtén estos datos, crea esta acción, escribe este script de análisis.
El servidor MCP de TagoIO es un pequeño programa (o un endpoint alojado) que expone tu cuenta de TagoIO a Claude como un conjunto de herramientas tipadas. Claude lee el catálogo de herramientas, elige la correcta para lo que pediste, completa los parámetros y actúa. Ves el resultado en el chat, y el cambio aparece en tu consola de administración de TagoIO.
El efecto práctico: la mayor parte del trabajo operativo que antes hacías haciendo clic por la UI de administración o escribiendo scripts puntuales, ahora lo haces en español sencillo desde tu IDE.
Configuración en dos minutos
El servidor MCP de TagoIO tiene dos variantes. El servidor remoto en https://mcp.ai.tago.io no necesita instalación. La opción local corre con npx si lo quieres en tu máquina. Ambas se autentican con un Profile Token de tu cuenta de TagoIO en admin.tago.io/profile.
Para Claude Code, un solo comando:
claude mcp add-json @tago-io/mcp '{"type":"http","url":"https://mcp.ai.tago.io","headers":{"Authorization":"Bearer YOUR-TAGOIO-TOKEN"}}'Para Claude Desktop, agrega esto a 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"
]
}
}
}Reinicia, y Claude ya puede llegar a tu cuenta. Si estás en EU West o en una instancia dedicada de TagoIO, agrega un header x-tagoio-region con eu-w1 o tu URL completa de la API.
Una nota sobre los tokens: el Profile Token otorga acceso completo a la cuenta y es la opción correcta mientras exploras. Para producción, cambia a un Analysis Token vinculado a un Analysis con alcance restringido. El mismo servidor MCP, con un radio de impacto más estrecho.
Qué puede hacer el servidor MCP en realidad
El servidor actual (v3) agrupa las herramientas en un puñado de servicios. La cobertura es lo bastante amplia como para que la mayor parte del trabajo diario quepa dentro de él.
Dispositivos. device-operations se encarga de buscar, crear, actualizar, eliminar y configurar. Puedes buscar por nombre (la coincidencia con comodines viene integrada), por tag, por connector, por network, por estado activo. device-data-operations ejecuta consultas con agregaciones: avg, sum, min, max, count y condicional. El agrupamiento por tiempo va desde minuto hasta año. device-delete-data elimina datos de un dispositivo cuando lo necesitas.
Acciones. action-operations cubre el CRUD completo sobre las Actions de TagoIO, las reglas que se disparan cuando un dispositivo envía datos que cumplen una condición. Alertas por correo, webhooks, disparadores de análisis, todo.
Análisis. analysis-operations lee, escribe y actualiza scripts de Analysis (el código Node.js que TagoIO ejecuta del lado del servidor por ti). Junto con tagoio-code-search, Claude puede generar código de Analysis con las llamadas correctas al SDK de TagoIO en lugar de alucinar la forma de una API. tagoio-documentation-search consulta la documentación de TagoIO bajo demanda.
Entities. entity-operations y entity-data trabajan con las Entities de TagoIO, la capa relacional para datos que no son series temporales: registros de clientes, jerarquías de activos, tablas de configuración.
Integración, perfil, usuarios de RUN. integration-lookup encuentra connectors y networks. profile-lookup y profile-metrics dan el estado de la cuenta y su uso. user-lookup trabaja contra los usuarios de TagoRUN para despliegues white-label.
Eso es suficiente superficie para gestionar una flota, depurar un dispositivo, construir una alerta, escribir un script del lado del servidor y revisar la salud de tu cuenta, todo desde el mismo chat.
Cómo se ve esto en la práctica
Algunos ejemplos de lo que un ingeniero de IoT ahora puede hacer sin salir de su IDE.
Encontrar un dispositivo que se comporta mal.
“Muéstrame todos los dispositivos del connector warehouse-east que no han enviado datos en las últimas 24 horas y siguen marcados como activos.”
Claude llama a device-operations con operation: lookup, filtra por connector y luego verifica last_input en cada uno. Recibes la lista de vuelta como una tabla.
Extraer datos históricos sin escribir SQL.
“¿Cuál fue la temperatura promedio y máxima del dispositivo Cold Storage 04 entre el 1 y el 15 de noviembre, agrupada por día?”
Claude llama a device-data-operations con el ID del dispositivo, la variable temperature, las agregaciones avg y max, el bucket de tiempo day y el rango de fechas. La respuesta trae los números. Si quieres un gráfico, pídelo.
Aprovisionar un dispositivo nuevo con un parser.
“Crea un dispositivo mutable nuevo llamado Boiler Sensor 12, etiquétalo con region:north y type:boiler, conéctale el connector LoRaWAN que usamos para la línea de calderas y configura el parser de payload para decodificar en base64 los primeros cuatro bytes como temperatura en décimas de grado.”
Claude resuelve el connector con integration-lookup, llama a device-operations con operation: create y escribe el parser en línea.
Escribir un script de Analysis que normalmente tomaría una hora.
“Escribe un script de Analysis que se ejecute cada hora, revise cada dispositivo etiquetado como type:boiler y, si la presión promedio de la última hora supera los 4,5 bar, envíe un correo a operaciones y cree una Action de TagoIO con el dispositivo marcado como at-risk.”
Claude obtiene la forma del SDK con tagoio-code-search, redacta el script y lo crea mediante analysis-operations. Revisas el código en el chat y lo envías.
Auditar antes de una demo con un cliente.
“Lista todas las Actions de la cuenta, agrúpalas por tipo de disparador y dime cuáles no se han activado en los últimos 30 días.”
action-operations con lookup, y luego profile-metrics para cruzar la actividad. Cinco segundos de trabajo que antes era una revisión manual de treinta minutos.
Ninguno de estos es una demo. Son las mismas operaciones que los equipos de IoT ya hacen cada semana, comprimidas de clics-y-pestañas a una frase.
Por qué la plataforma de abajo sigue importando
El servidor MCP impresiona, pero está aguas abajo de un punto más importante: funciona porque TagoIO ya tiene APIs tipadas para cada concepto que importa en IoT. Dispositivos, datos, acciones, análisis, entities, usuarios, connectors, networks. El servidor MCP es una capa fina que expone esas APIs a una IA. Si hubieras construido tu propia plataforma, ahora también estarías construyendo tu propio servidor MCP encima de tus propios servicios internos sin documentar. Eso es otro trimestre de trabajo antes de que la IA te ayude con algo.
Esta es la parte que hay que tomarse en serio al planear un producto de IoT. La decisión de plataforma fija el techo de qué tan rápido puede moverse todo lo demás, incluido el tooling de IA que será estándar dentro de dos años. Una base de datos en la nube de propósito general más un montón de microservicios no le da a un asistente de IA ningún lugar limpio donde conectarse. Una plataforma de IoT construida con un propósito específico sí.
No necesitas una IA para justificar TagoIO. La plataforma de IoT full-stack se sostiene por sí sola: dashboards, RBAC, móvil, multirregión, el paquete completo, fácil de empezar y asequible a escala. Pero en cuanto sumas Claude encima a través de MCP, el trabajo diario de operar una flota deja de parecer operaciones y empieza a parecer una conversación. Ese es el cambio real.
Pruébalo
Si ya tienes una cuenta de TagoIO, generar un token y conectar Claude toma unos dos minutos. Si no la tienes, el plan gratuito es suficiente para ver el ciclo completo con un par de dispositivos de prueba.
El servidor MCP de TagoIO es de código abierto en github.com/tago-io/mcp-server. La documentación cubre todos los IDE y herramientas de IA que hoy soportan MCP: VS Code, Cursor, Windsurf, Claude Code, Claude Desktop, JetBrains, Gemini CLI, Amazon Q, OpenAI Agents, Warp, Kiro. Elige uno, pega la configuración, apunta Claude a tu flota y pídele algo que normalmente habrías hecho a mano.
Construye el producto, no la plataforma.
