Azure IoT Hub MCP Server

Servidor MCP para Azure IoT Hub: registro de dispositivos, gemelos, métodos directos, trabajos y mensajería.

Documentación

Servidores MCP de IoT

Servidores MCP (Model Context Protocol) para plataformas IoT — que brindan a los agentes de IA acceso completo de lectura/escritura a registros de dispositivos, gemelos digitales y telemetría.

Python License: MIT CI MCP Registry

Servidores

ServidorPlataformaHerramientasPaquete
eclipse-dittoEclipse Ditto gemelos digitales (código abierto; también compatible con Bosch IoT Things y otras implementaciones basadas en Ditto)48PyPI
mqttMQTT 5.0 — el protocolo estándar de publicación/suscripción para IoT (cualquier broker: Mosquitto, EMQX, HiveMQ, AWS IoT Core, etc.)7PyPI
aws-iot-coreAWS IoT Core — registro de dispositivos, sombras, trabajos, reglas, mensajería48PyPI
azure-iot-hubAzure IoT Hub — registro de dispositivos, gemelos, métodos directos, trabajos, mensajería25PyPI
sparkplug-bSparkplug B — convención MQTT + protobuf para datos industriales/SCADA (nacimiento/muerte, métricas secuenciadas, comandos)13PyPI

Cada fila enlaza al README de ese servidor para su lista completa de herramientas, variables de entorno requeridas y notas de configuración/pruebas.

Estructura

Cada servidor es un directorio independiente dentro de este repositorio — su propio pyproject.toml, uv.lock, Dockerfile y mcp.json de configuración de ejemplo. No hay capa de biblioteca compartida: cada servidor es ejecutable y dockerizable de forma independiente.

<server-name>/
├── <server-name>mcpserver.py   # FastMCP server (single file)
├── pyproject.toml              # own dependencies
├── uv.lock
├── Dockerfile
├── mcp.json                    # example MCP client config
└── README.md                   # tools, env vars, setup for this server

Requisitos

  • Python 3.12+
  • uv para gestión de dependencias y ejecución de servidores
  • Docker, solo si quieres ejecutar el conjunto de pruebas de un servidor contra una instancia real/emulada (consulta el README de ese servidor)

Inicio rápido

Instala directamente desde PyPI con uv o pipx — no necesitas clonar:

uvx eclipse-ditto-mcp-server      # or: mqtt5-mcp-server / aws-iot-core-mcp-server / azure-iot-hub-mcp-server / sparkplug-b-mcp-server

O ejecuta desde un clon de este repositorio:

git clone https://github.com/nagarjunr/iot-mcp-servers.git
cd iot-mcp-servers/<server-name>
uv sync
uv run <server-name>mcpserver.py

Cada servidor lee su configuración de variables de entorno (cadenas de conexión, host del broker, credenciales, etc.) — consulta el README de ese servidor para la lista completa.

Uso con un cliente MCP

Cada directorio de servidor tiene un mcp.json con un ejemplo de configuración de cliente listo para usar (Claude Desktop / VS Code / cualquier cliente MCP). Copia el bloque relevante en la configuración de tu cliente, completando las variables de entorno descritas en el README de ese servidor. Todos los servidores también están listados en el registro oficial de MCP bajo io.github.nagarjunr/<server-name>.

Principios de diseño

  • Solo lectura por defecto, escrituras explícitas. Las herramientas por defecto son operaciones de lectura/listado. Cualquier herramienta de escritura se indica explícitamente en el README de ese servidor. Las herramientas de crear/reemplazar por defecto son solo de creación (overwrite=False) — sin condiciones de carrera mediante cabeceras condicionales donde la API de destino las soporte (p. ej. If-None-Match de Ditto), de lo contrario una comprobación documentada de describir-luego-crear. Las herramientas de eliminación, donde un servidor las necesite, requieren un confirm=True explícito — no hay eliminación masiva/en cascada.
  • Sin dependencia de proveedor. Los conectores apuntan al protocolo/API abierto (p. ej. la API HTTP de Eclipse Ditto, el protocolo de cable MQTT), no a una extensión propietaria de un solo proveedor, por lo que funcionan con cualquier implementación compatible. Excepción: los servicios de proveedores de nube como AWS IoT Core son inherentemente específicos del proveedor — no se aplica la afirmación de no dependencia allí, pero tampoco se inventa una abstracción entre proveedores.
  • Probado contra el producto real, con excepciones documentadas donde no existe una instancia real gratuita. Cada servidor se verifica contra una instancia real de la plataforma objetivo (generalmente mediante Docker), no con mocks hechos a mano. mqtt y sparkplug-b se ejecutan contra un broker real de Eclipse Mosquitto (las pruebas de sparkplug-b simulan el lado del "dispositivo" con la misma biblioteca de protocolo real que usa el servidor, por lo que ambos extremos del cable son genuinos). aws-iot-core se prueba contra moto (AWS IoT Core no tiene emulador local gratuito; el soporte de IoT de LocalStack requiere un plan de pago). azure-iot-hub se prueba contra respx para sus herramientas REST; su única herramienta solo-AMQP (send_c2d_message — el envío de nube a dispositivo de Azure IoT Hub no tiene enlace REST) se prueba contra un endpoint AMQP falso local construido para este repositorio, ya que no existe un equivalente de moto para Azure y no hay ningún emulador gratuito de Azure IoT Hub. Estos son emuladores genuinos/falsos a nivel de protocolo, no mocks ingenuos — consulta el README de cada servidor para detalles y advertencias.

Contribuciones

¿Agregando un nuevo servidor? Sigue la estructura y los principios de diseño anteriores, agrega su fila a la tabla Servers y asegúrate de que su conjunto de pruebas se ejecute contra una instancia real o fielmente emulada de la plataforma objetivo (documenta cualquier excepción, como hacen aws-iot-core y azure-iot-hub). Se aceptan issues y PRs.

Licencia

MIT — consulta LICENSE.