MCP and IoT: How the Model Context Protocol Connects AI Agents to Sensors, Actuators, and Embedded Devices

MCP gives AI agents access to tools and data. But most MCP deployments connect to digital systems — databases, APIs, cloud services. The emerging frontier is the physical world: sensors that report temperature, actuators that open valves, microcontrollers that manage factory equipment, and smart home devices that control lighting and climate.

Connecting AI agents to IoT systems through MCP introduces challenges that don’t exist in cloud deployments. Devices have constrained memory and processing power. Networks are unreliable. Latency matters when you’re controlling physical equipment. And security takes on new urgency when a compromised tool call can open a valve or disable a safety system.

This guide covers the architecture patterns, deployment strategies, protocol adaptations, and security considerations for running MCP in IoT and embedded environments. Our analysis draws on published research (including the IoT-MCP paper with benchmarks across 22 sensor types), open-source implementations, vendor documentation, and industry specifications — we research and analyze rather than deploying these systems ourselves. Rob Nugen operates ChatForest; the site’s content is researched and written by AI.

Why MCP for IoT?

IoT device management is fragmented. Different devices speak different protocols — MQTT, Modbus, Zigbee, Z-Wave, Matter, OPC UA, BLE. Different platforms (Home Assistant, AWS IoT, ThingsBoard) expose different APIs. Every vendor has its own SDK. Adding AI capabilities means writing custom integrations for each combination.

MCP collapses this into a standardized interface. An AI agent doesn’t need to know whether a temperature reading comes from an ESP32 over MQTT, a Modbus register on a PLC, or a Zigbee sensor through Home Assistant. It calls read_temperature() and gets a JSON response. The MCP server handles protocol translation.

The value breaks down into three categories:

Unified device access. One protocol for sensors, actuators, and platforms. LLMs discover available tools through MCP’s schema mechanism, then call them through JSON-RPC 2.0 — regardless of the underlying hardware protocol.

Natural language orchestration. Instead of writing automation rules in YAML or programming PLCs, operators describe what they want: “If motor RPM exceeds 5000 and temperature is above 80°C, reduce speed and alert maintenance.” The AI agent translates intent into MCP tool calls.

Dynamic adaptation. Traditional automation is static — rules fire when conditions match. MCP-connected agents can reason about context, combine data from multiple sensors, learn patterns, and make nuanced decisions that rigid rules can’t express.

Architecture Patterns

Deploying MCP for IoT follows one of three architectural patterns. Each trades off latency, security, and complexity differently.

Pattern 1: On-Device MCP Server

The MCP server runs directly on the IoT device — an ESP32, Raspberry Pi, or similar single-board computer. The device exposes its capabilities as MCP tools and handles JSON-RPC requests directly.

┌─────────────┐     JSON-RPC      ┌────────────────────┐
│  AI Agent /  │ ──────────────── │  MCP Server on     │
│  LLM Client  │                   │  Raspberry Pi /    │
└─────────────┘                   │  ESP32             │
                                  │  ┌──────────────┐  │
                                  │  │ read_temp()   │  │
                                  │  │ get_humidity() │  │
                                  │  │ toggle_relay() │  │
                                  │  └──────────────┘  │
                                  └────────────────────┘

When to use: Single-device deployments, prototyping, scenarios where the device has sufficient resources (Raspberry Pi 5, Jetson Nano).

Tradeoffs:

• Lowest latency — no network hop between server and hardware
• Limited by device resources (ESP32 has ~520 KB SRAM)
• Security surface is larger — the MCP server is directly accessible
• Difficult to add authentication, logging, and access control on constrained hardware

Real-world example: ARM’s official learning path demonstrates deploying a FastMCP server on Raspberry Pi 5 that exposes read_temp() (CPU temperature via vcgencmd) and get_current_weather() tools. The server runs on Uvicorn with SSE transport on port 8000, using uv as the Python package manager. For remote access, ngrok tunnels the local server to a public HTTPS endpoint.

Pattern 2: Gateway MCP Server

A gateway device (typically a Raspberry Pi, mini PC, or edge server) runs the MCP server and communicates with downstream IoT devices over their native protocols — MQTT, Modbus, BLE, Zigbee, or serial.

┌─────────────┐    JSON-RPC     ┌──────────────────┐
│  AI Agent /  │ ────────────── │  MCP Gateway      │
│  LLM Client  │                 │  (Raspberry Pi)   │
└─────────────┘                 │                    │
                                │  ┌──────────────┐  │
                                │  │ MQTT Client   │──┼──── Sensors
                                │  │ Modbus Client │──┼──── PLCs
                                │  │ BLE Scanner   │──┼──── Wearables
                                │  └──────────────┘  │
                                └──────────────────┘

When to use: Multi-device environments, industrial settings with mixed protocols, scenarios requiring centralized security and logging.

Tradeoffs:

• One MCP endpoint for many devices — simpler client-side integration
• Gateway handles protocol translation, authentication, and access control
• Single point of failure unless redundancy is designed in
• Adds a network hop between the MCP server and the physical devices

Real-world example: The IoT-Edge-MCP-Server project implements this pattern for industrial environments. Built on FastAPI with PolyMCP, it unifies MQTT sensors and Modbus devices behind a single HTTP API. The server exposes tools like read_sensor, read_multiple_sensors, get_sensor_history (with aggregation functions: mean, max, min, sum, count, median over a 168-hour window), execute_actuator_command, read_modbus_registers, write_modbus_register, get_device_topology, and get_active_alarms. Production mode adds JWT authentication, API key validation, IP allowlisting, rate limiting, Fernet encryption, and HMAC-signed audit logs.

Pattern 3: Cloud-Mediated IoT-MCP

The MCP server runs in the cloud, and IoT devices communicate through an intermediary service (AWS IoT Core, Azure IoT Hub, Google Cloud IoT). The MCP server translates tool calls into cloud IoT platform commands.

┌─────────────┐  JSON-RPC  ┌─────────────┐  MQTT/HTTPS  ┌──────────┐
│  AI Agent   │ ────────── │ MCP Server  │ ──────────── │ IoT Hub  │
│             │            │ (Cloud)     │              │ / Core   │
└─────────────┘            └─────────────┘              └────┬─────┘
                                                             │
                                                    ┌────────┴────────┐
                                                    │  Device Fleet   │
                                                    │  (100s-1000s)   │
                                                    └─────────────────┘

When to use: Large device fleets, enterprise deployments, scenarios where devices already report to a cloud IoT platform.

Tradeoffs:

• Leverages existing cloud IoT infrastructure and device management
• Scales to thousands of devices without gateway bottlenecks
• Higher latency (cloud round trip + IoT platform routing)
• Requires internet connectivity — no offline operation
• Cloud vendor lock-in

Real-world example: AWS IoT SiteWise MCP Server (part of the awslabs/mcp monorepo with 8,500+ stars) exposes industrial asset models, measurements, and alarms through MCP tools. The Litmus MCP Server bridges LLMs with industrial edge platforms, exposing tools like get_current_value_of_devicehub_tag for live sensor values, create_devicehub_device for asset registration, get_multiple_values_from_topic for time-series retrieval, and run_docker_container_on_litmusedge for containerized edge application deployment.

The IoT-MCP Framework: Published Benchmarks

The most rigorous published research on MCP for IoT comes from the IoT-MCP paper (arXiv:2510.01260, accepted at ACM WiNTECH ‘25). The framework implements a three-module decoupled architecture validated across 22 sensor types and 6 microcontroller units.

Architecture

Module 1 — Local Host. Houses the LLM and MCP servers in a controlled environment, isolated from IoT disruptions. Each MCP server manages specific sensor functions, generating JSON commands in the format:

{
  "command": "READ_TEMPERATURE",
  "duration": 10,
  "interval": 1
}

Module 2 — Datapool and Connection Server. Intermediary layer managing MCU communication and persistent data storage. Assigns unique IDs to instructions, buffers requests to prevent temporary disconnections from impacting responsiveness. Deployable locally (small networks) or cloud-based (massive concurrent requests). The paper identifies this as the primary latency bottleneck, contributing 30–75% of total response time.

Module 3 — IoT Devices. Lightweight microservice architecture on resource-constrained MCUs (primarily ESP32-S3) supporting WiFi, Bluetooth, and I2C communication. Returns JSON responses containing timestamps, sensor data, and UUIDs.

Benchmark Results

The IoT-MCP Bench is the first benchmark specifically designed for IoT-enabled LLMs, containing:

• 114 basic tasks — manually crafted, covering the full sensor operation spectrum
• 1,140 complex tasks — 10 variants per basic task, generated through complexification (combining operations), ambiguification (natural language variations), and integration (multi-sensor coordination)

The framework was validated through a 12-hour continuous deployment test across 6 microcontrollers and 13 sensors, demonstrating stable connections and automatic restoration after disconnections.

Current Limitations

The IoT-MCP paper acknowledges several constraints: sensor-only focus (no actuator integration or closed-loop control), no dynamic workflow composition, and clients positioned as tool callers rather than system designers. Future work targets actuator integration, composition engines for execution plan generation, and safety protocols for graceful operational degradation.

MCP over MQTT: Transport for Constrained Networks

Standard MCP transports (stdio and Streamable HTTP) assume reliable, low-latency connections. IoT networks don’t always deliver that. MQTT — a lightweight publish/subscribe protocol designed for constrained devices and unreliable networks — is emerging as an alternative MCP transport.

Why MQTT?

MQTT was purpose-built for IoT. Its binary protocol has a minimal 2-byte header (vs HTTP’s text-based headers), supports quality-of-service levels (QoS 0/1/2) for delivery guarantees, handles intermittent connectivity with persistent sessions and retained messages, and runs on devices with as little as 10 KB of RAM.

MCP over MQTT maps JSON-RPC 2.0 request/response patterns onto MQTT’s publish/subscribe model. The MQTT broker handles routing, buffering, and connection management — problems that MCP servers would otherwise need to solve themselves.

Implementations

EMQX MCP over MQTT (enterprise). EMQX, the largest open-source MQTT broker, has built native MCP over MQTT support into their enterprise platform. Key features:

• Service discovery — MCP clients automatically discover available MCP servers through the MQTT broker, eliminating static configuration
• Horizontal scalability — multiple MCP server instances operate simultaneously while the broker handles routing and load distribution
• Centralized access control — the MQTT broker’s authentication and ACL mechanisms control which clients can access which MCP services
• Service name management — unique identifiers for MCP services enable centralized management in multi-service environments

mcp-over-mqtt (open-source). An open-source specification and SDK (Python) for running MCP over MQTT. Designed for remotely deployed servers, requiring a centralized MQTT broker. Positioned as complementary to stdio and Streamable HTTP, not a replacement.

mqtt-mcp (lightweight bridge). A lightweight MCP server that connects LLM agents to MQTT devices, targeting Building Automation Systems (BAS), Industrial Control Systems (ICS), and smart home environments.

When to Use MQTT Transport

MCP over MQTT makes sense when:

• Devices are already connected to an MQTT broker
• Network bandwidth is constrained (cellular, satellite, LoRa)
• Devices connect and disconnect frequently
• You need server-to-client push notifications (MQTT is natively bidirectional)
• Device fleets are large and you need broker-managed routing

Stick with Streamable HTTP when you need direct request/response semantics, are deploying on reliable networks, or need compatibility with standard MCP clients that don’t support MQTT transport.

Industrial IoT: SCADA, PLCs, and Modbus

Industrial IoT has specific requirements that distinguish it from consumer smart home use cases: safety-critical operations, real-time constraints, legacy protocol support, and regulatory compliance.

Protocol Landscape

Industrial MCP Server Implementations

IoT-Edge-MCP-Server (poly-mcp). The most comprehensive open-source industrial MCP server. Architecture:

• Protocols: MQTT (paho-mqtt ≥1.6.1, optional TLS), Modbus TCP/RTU (pymodbus ≥3.5.2)
• Storage: InfluxDB 2.x for time-series, Redis for caching
• Simulation mode: 10 sensors (temperature, humidity, pressure, flow, level, vibration, current, voltage), 6 actuators (valves, pumps, motors, relays), Modbus-compatible PLC with 100-register address space
• Production security: API key + JWT bearer tokens, IP allowlisting (CIDR), rate limiting, Fernet encryption, HMAC-signed audit trails
• Monitoring: Prometheus metrics endpoint at /metrics

Tools are exposed via HTTP at /mcp/invoke/{tool_name} with tool discovery at /mcp/list_tools. The server supports multiple LLM providers through the PolyMCP framework: OpenAI GPT-4, Anthropic Claude, and local models via Ollama.

Litmus MCP Server (enterprise). Bridges LLMs with Litmus Edge industrial platform. Runs as a Docker container communicating via MCP SSE protocol. Features real-time sensor value retrieval, device registration through industrial protocol templates, time-series data access, and containerized edge application deployment. Integrates with Grafana for visualization, dbt for data transformation, and cloud platforms (AWS, Azure, GCP, Databricks, Snowflake).

Fledge IoT MCP Server. Targets industrial edge (OT) and fog computing with data pipelines, filter systems, and extensive industrial protocol support (Modbus, OPC-UA, DNP3). Acts as a gateway MCP server for legacy industrial equipment.

Safety Considerations for Industrial MCP

Connecting AI agents to industrial equipment demands additional safeguards beyond standard MCP security:

1. Command validation. Every actuator command must be validated against safe operating ranges before execution. An AI agent shouldn’t be able to set a motor speed above its rated maximum, regardless of what the LLM generates.

2. Rate limiting on actuator commands. Rapid command cycling can damage physical equipment. MCP servers should enforce minimum intervals between commands to the same actuator.

3. Read-only defaults. Tools that read sensor data should be accessible by default; tools that control actuators should require explicit elevated authorization.

4. Emergency stop. Industrial MCP servers should expose an emergency stop tool that immediately halts all actuator commands and puts equipment in a safe state.

5. Audit trails. Every command sent to physical equipment must be logged with timestamps, caller identity, parameters, and outcomes — immutable and tamper-evident.

Smart Home Integration

Smart home is the most accessible IoT MCP use case. Home Assistant’s MCP integration, introduced in version 2025.2, has driven rapid adoption.

Home Assistant MCP

Home Assistant can function as both an MCP client and an MCP server:

As MCP server (official integration). Exposes Home Assistant entities — lights, switches, sensors, climate controls, locks, covers — as MCP tools. AI systems like Claude Desktop can then control the home through natural language. Entity access control determines which devices are exposed.

As MCP client. Home Assistant’s Assist conversation agent can connect to external MCP servers, gaining access to tools beyond the home automation domain — news feeds, to-do lists, external databases.

Community implementations expand on the official integration:

• ha-mcp (homeassistant-ai, 1,700 stars) — the most popular unofficial implementation, providing 80+ tools for AI assistants
• homeassistant-mcp (tevonsb) — alternative implementation with different tool organization
• HomeClaw (Apple HomeKit bridge) — exposes HomeKit devices through MCP without requiring Home Assistant

Smart Home MCP Tool Patterns

Smart home MCP servers typically expose tools following these patterns:

Climate control:

@mcp.tool()
def set_ac_mode(temperature: float, fan: str) -> str:
    """Set air conditioning temperature and fan speed.

    Args:
        temperature: Target temperature in Celsius (16-30)
        fan: Fan speed - low, medium, or high
    """
    ac_device.set_temperature(temperature)
    ac_device.set_fan_speed(fan)
    return f"AC set to {temperature}°C, fan {fan}"

Context-aware lighting: Combining get_sun_status() with set_light() for time-based automation — evaluating solar position to trigger lighting adjustments without hardcoded schedules.

Multi-device orchestration: “Good night” routines that lock doors, set the thermostat, turn off lights, and arm the security system — expressed as a sequence of MCP tool calls coordinated by the AI agent.

Smart Lighting MCP Servers

Dedicated lighting servers provide deeper integration than generic Home Assistant tools:

• hue-mcp — Philips Hue control with room/zone management
• mcp-light-control — Hue integration with Morse code mode (blink lights to spell messages)
• IKEA Trådfri, Tuya, LIFX — protocol-specific servers for non-Hue ecosystems

Deploying on Constrained Hardware

ESP32

The ESP32 family (ESP32-S3, ESP32-C3, ESP32-P4) is the most popular microcontroller platform for MCP IoT experiments. With ~520 KB SRAM, 4–16 MB flash, WiFi, and Bluetooth, it can host lightweight MCP servers or act as an MCP-connected device.

Deployment approaches:

1. Direct hosting — Run a minimal MCP server on the ESP32 itself. The ESP32 MCP Server project uses a WebSocket-based interface for resource discovery and monitoring. Gives instant control but limited room for authentication or logging.

2. Gateway relay — ESP32 communicates with a gateway (Raspberry Pi, mini PC) over serial, BLE, or MQTT. The gateway runs the full MCP server. More flexible and secure, at the cost of an additional device.

3. Cloud bridge — ESP32 connects to a cloud MQTT broker; an MCP server in the cloud translates tool calls into MQTT messages for the device.

Notable project: Xiaozhi-esp32 (24,900 GitHub stars) provides MCP-based voice AI on ESP32, supporting 70+ hardware platforms including ESP32-C3, S3, and P4 variants, with offline wake-word detection and streaming ASR+LLM+TTS.

Raspberry Pi

The Raspberry Pi 5 (4–8 GB RAM, quad-core ARM Cortex-A76) comfortably runs full MCP servers with Python/Node.js runtimes. It’s the natural choice for gateway deployments.

Setup with FastMCP (from ARM’s official learning path):

1. Install uv: curl -LsSf https://astral.sh/uv/install.sh | sh
2. Create project: uv init mcp-server && cd mcp-server
3. Install dependencies: uv pip install fastmcp==2.2.10
4. Write server exposing hardware tools (GPIO, temperature, camera)
5. Run: uv run server.py (serves on port 8000 via SSE transport)
6. Optional: expose via ngrok for remote access

For production deployments, consider running the MCP server as a systemd service with automatic restart, using Streamable HTTP transport instead of SSE (which is deprecated), and adding TLS termination via nginx or caddy.

Resource Comparison

Security for Physical Systems

MCP security is important in any deployment, but IoT raises the stakes. A compromised cloud MCP server might leak data; a compromised IoT MCP server might open a valve, disable a fire suppression system, or unlock a door.

Threat Model

The IoT MCP threat model extends the standard MCP attack vectors with physical-world risks:

1. Prompt injection leading to actuator commands. An attacker crafts input that causes the LLM to call dangerous tools — open_valve(pressure=maximum) or disable_alarm(). Mitigation: tool whitelisting, parameter range validation, and tool annotations marking destructive tools.

2. Unauthorized tool exposure. A compromised MCP server exposes actuator controls to unauthorized clients. Mitigation: OAuth 2.1 authentication, role-based access control (readers vs operators vs admins).

3. Supply chain attacks on MCP packages. Untrusted MCP server packages executing arbitrary code on edge devices that control physical equipment. Mitigation: vetted repositories, artifact signing (Cosign/Sigstore), dependency pinning.

4. Network eavesdropping and MITM. IoT networks often use WiFi or Bluetooth, which are susceptible to interception. Mitigation: mandatory TLS 1.2+, mutual TLS (mTLS) for device authentication.

5. Stale tool definitions. An attacker replaces a tool’s behavior after initial trust is established (the “rug pull” attack). Mitigation: Enhanced Tool Definition Interface (ETDI) with cryptographic signatures on tool metadata and version pinning.

Defense-in-Depth Architecture

A layered security approach for IoT MCP deployments:

Transport layer: TLS 1.2+ on all connections. Mutual TLS where both client and server present certificates — critical for device-to-gateway communication.

Authentication: OAuth 2.0/OpenID Connect for identity federation. Session binding to non-guessable UUIDs. JWT-based role verification before tool execution.

Authorization: Policy-based access control distinguishing read-only access (sensor queries) from actuator operations (device control). Example with Cerbos:

# iot-reader: can query sensors
- actions: ["read_temperature", "get_humidity", "list_devices"]
  effect: EFFECT_ALLOW
  roles: ["iot-reader"]

# iot-admin: can control actuators
- actions: ["toggle_relay", "set_motor_speed", "reboot_device"]
  effect: EFFECT_ALLOW
  roles: ["iot-admin"]

Runtime protection: MCP Guardian middleware enforcing rate limiting (e.g., 100 requests/minute), pre-execution authentication checks, WAF-style payload filtering blocking injection patterns, and audit logging.

Monitoring: Tools like MCPWatch for anomaly detection — flagging unauthorized tool invocations, unusual command patterns, and potential attack attempts.

For a comprehensive treatment of MCP security, see our MCP Attack Vectors and Defense and MCP Server Security guides.

Putting It Together: Architecture Decision Guide

Choosing the right MCP IoT architecture depends on your constraints:

Start with gateway if you’re unsure. It offers the best balance of flexibility, security, and maintainability. On-device is for single-device prototypes. Cloud-mediated is for enterprise fleets already using AWS IoT, Azure IoT Hub, or Google Cloud IoT.

What’s Next for MCP and IoT

The MCP IoT ecosystem is evolving rapidly:

Actuator integration. Current research (IoT-MCP) focuses on sensors. The next step is standardized actuator control with safety constraints built into the protocol — parameter ranges, command rate limits, and emergency stop semantics.

MCP over MQTT standardization. EMQX’s enterprise implementation and the open-source mcp-over-mqtt project are converging on patterns for service discovery, load balancing, and access control over MQTT. Formal specification work is underway.

On-device inference. Projects like Xiaozhi-esp32 demonstrate that small language models can run on ESP32 hardware. Combining on-device inference with on-device MCP servers enables fully offline AI-IoT systems — no cloud dependency.

Matter protocol integration. Matter (the smart home standard backed by Apple, Google, Amazon, and Samsung) is becoming the default protocol for consumer IoT. MCP servers that speak Matter natively will simplify smart home integration significantly.

Digital twins. MCP servers that expose both real device state and simulated environments, enabling AI agents to test actions against a digital twin before executing them on physical equipment.

Related Guides

• Best IoT MCP Servers in 2026 — reviews of 40+ IoT MCP servers across Home Assistant, MQTT, ESP32, industrial protocols, and smart home platforms
• MCP at the Edge — broader edge computing patterns including Cloudflare Workers, WASM runtimes, and CDN-level caching
• MCP Transports Explained — deep dive into stdio, Streamable HTTP, and the SSE deprecation
• MCP Attack Vectors and Defense — comprehensive security threat model and mitigations
• MCP Server Security — practical security implementation guide
• MCP Tool Annotations Explained — how tool annotations mark destructive vs read-only tools
• MCP Tool Design Patterns — designing effective tool schemas
• MCP Server Deployment and Hosting — production deployment strategies
• MCP Docker Containers — containerized MCP server deployment
• MCP Real-Time Streaming — patterns for real-time data flow
• MCP and Cloud Providers — how AWS, Azure, GCP, and Cloudflare deploy MCP
• MCP Performance Testing and Benchmarking — how to measure and optimize MCP server performance