Iot Mcp Servers MCP Server

IoT MCP Servers

MCP (Model Context Protocol) servers for IoT platforms — giving AI agents full read/write access to device registries, digital twins, and telemetry.

Servers

Each row links to that server's README for its full tool list, required environment variables, and setup/testing notes.

Structure

Each server is a standalone directory under this repo — its own pyproject.toml, uv.lock, Dockerfile, and mcp.json example config. No shared library layer: every server is independently runnable and dockerizable.

<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

Requirements

• Python 3.12+
• uv for dependency management and running servers
• Docker, only if you want to run a server's own test suite against a real/emulated instance (see that server's README)

Quick start

Install straight from PyPI with uv or pipx — no clone needed:

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

Or run from a clone of this repo:

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

Each server reads its configuration from environment variables (connection strings, broker host, credentials, etc.) — see that server's README for the full list.

Using with an MCP client

Each server directory has an mcp.json with a ready-to-use client config example (Claude Desktop / VS Code / any MCP client). Copy the relevant block into your client's config, filling in the environment variables described in that server's README. All four servers are also listed on the official MCP registry under io.github.nagarjunr/<server-name>.

Design principles

• Read-only by default, writes explicit. Tools default to read/list operations. Any write tool is called out explicitly in that server's README. Create/replace tools default to create-only (overwrite=False) — race-free via conditional headers where the target API supports them (e.g. Ditto's If-None-Match), otherwise a documented describe-then-create check. Delete tools, where a server needs them, require an explicit confirm=True — there is no bulk/cascading delete.
• No vendor lock-in. Connectors target the open protocol/API (e.g. Eclipse Ditto's HTTP API, the MQTT wire protocol), not a single vendor's proprietary extension of it, so they work against any compatible deployment. Exception: cloud-provider services like AWS IoT Core are inherently vendor-specific — no lock-in claim applies there, but no cross-vendor abstraction is invented either.
• Tested against the real thing, with documented exceptions where no free real instance exists. Each server is verified against a real instance of the target platform (usually via Docker), not hand-rolled mocks. aws-iot-core is tested against moto (AWS IoT Core has no free local emulator; LocalStack's IoT support requires a paid plan). azure-iot-hub is tested against respx for its REST tools; its one AMQP-only tool (send_c2d_message — Azure IoT Hub's cloud-to-device send has no REST binding) is tested against a local fake AMQP endpoint built for this repo, since no moto-equivalent exists for Azure and no free Azure IoT Hub emulator exists at all. Both are genuine emulators/protocol-level fakes, not naive mocks — see each server's README for specifics and caveats.

Contributing

Adding a new server? Follow the structure and design principles above, add its row to the Servers table, and make sure its test suite runs against a real or faithfully-emulated instance of the target platform (document any exception, as aws-iot-core and azure-iot-hub do). Issues and PRs welcome.

License

MIT — see LICENSE.