Azure IoT Hub MCP Server

A Model Context Protocol (MCP) server for Azure IoT Hub — device registry, device twins, direct methods, jobs, and messaging.

Scoped to IoT Hub's service-side data plane (device management), not Azure Resource Manager. Microsoft's own official Azure MCP Server already covers the ARM-level "show me my IoT Hub resource" case — this server covers the actual device-management capability that Azure MCP doesn't.

Calls Azure IoT Hub's REST Service API directly via httpx with a hand-rolled SAS token generator, rather than the official azure-iot-hub PyPI package — that package hard-depends on uamqp, a C-extension that fails to build on modern Python/platforms (confirmed: it doesn't install on Python 3.12/arm64). Built with FastMCP.

Tools

Device registry

Modules

Device & module twins

Direct methods

Jobs (fleet-scale operations)

Messaging

Statistics

Important caveat: send_c2d_message is AMQP, not REST, and has no real-instance test coverage

Every other tool in this server wraps a documented REST endpoint. Cloud-to-device message sending is the one exception: Azure IoT Hub's REST API only exposes the feedback side of C2D messaging (delivery receipts); sending is AMQP-protocol-only (confirmed by reading the official azure-iot-hub SDK's source — it hands off to an AMQP client, not an HTTP call).

To support it without pulling in the broken uamqp dependency, send_c2d_message implements the CBS (Claims-Based Security) auth handshake and message send directly against python-qpid-proton (the standard AMQP 1.0 library, confirmed to install cleanly on modern Python). The protocol details (CBS field names, $cbs node, /messages/devicebound target address, to property format) were confirmed from Microsoft's own pure-Python AMQP implementation in azure-eventhub/azure-servicebus, not guessed.

This tool is not covered by real-instance testing. There's no free Azure IoT Hub emulator (see Testing below), and the test suite's respx HTTP mocking can't exercise AMQP at all. Tests instead run this against a local fake AMQP endpoint (also built with qpid-proton) that implements just enough of the CBS handshake and /messages/devicebound receiver to prove the wire protocol is well-formed — it does not validate genuine Azure IoT Hub business logic. Verify against a real hub before relying on this in production.

Safety conventions

Same as the rest of this repo: create_* defaults to overwrite=False (best-effort describe-then-create check — IoT Hub's If-Match header is for optimistic-concurrency on updates, not create-only semantics, so this isn't fully race-free like Ditto's If-None-Match). Every delete_*/cancel_* requires confirm=True.

Configuration

Running locally

uv sync
export AZURE_IOT_HUB_CONNECTION_STRING="HostName=my-hub.azure-devices.net;SharedAccessKeyName=service;SharedAccessKey=..."
uv run azureiothubmcpserver.py

See mcp.json for ready-to-use client configs (stdio and Docker).

Testing

This repo's design principles call for testing against a real instance rather than mocks. Azure IoT Hub has no official local emulator and no moto-equivalent exists for it. REST endpoints are tested with respx (httpx's dedicated mocking library, using realistic Azure response shapes); send_c2d_message is tested against a local fake AMQP endpoint (see caveat above).

uv run pytest -v

License notes

No bundled deployment artifacts here (unlike eclipse-ditto/mqtt) since there's no local broker/service to run — Azure IoT Hub only exists as an Azure-hosted service.