Skip to content
Port OS

MCP for IoT device control: where it fits alongside device protocols

Published November 2, 2026 · By Port OS Team

The Model Context Protocol (MCP) is the layer between an AI application and the tools it can call. Device protocols such as MQTT and Matter, and vendor cloud APIs, are the layer between software and the devices themselves. An MCP server that controls devices sits on top of one or more of them and translates an agent's tool call into the commands each device understands.

This article explains where each layer starts and ends, and how the picture changes between a household and an industrial fleet. It is based on the MCP specification, the MQTT project site, the Connectivity Standards Alliance's Matter page, AWS's published edge example and how Port OS is built, all checked on November 2, 2026.

Compare the layers

LayerWhat it connectsExamplesWho uses it
MCPAn AI application to tools and datatools/list, tools/call over stdio or Streamable HTTPAssistants such as ChatGPT and Claude, and agent frameworks
Device messagingSoftware to many devices through a brokerMQTT publish and subscribe on topicsDevice firmware, gateways, fleet platforms
Device standardsDevices to controllers on a local networkMatter over Wi-Fi or ThreadSmart-home hubs and apps
Vendor APIsSoftware to a brand's own cloudPhilips Hue, Sonos and Google Nest APIsIntegrations and apps for that brand

What MCP adds

The MCP specification uses JSON-RPC 2.0 messages between a host (the AI application), its clients and servers. Servers offer tools, resources and prompts. The specification defines two standard transports, stdio for a server running beside the client and Streamable HTTP for a remote server, and it allows custom transports that keep the same message format.

For device control, the useful part is the tool contract. A server describes each tool with a name and an input schema, so an assistant can discover what it can do at run time and call it with structured arguments. The specification also asks hosts to obtain explicit user consent before invoking a tool, and it treats tool descriptions from an untrusted server as untrusted.

MCP does not define how to reach a lamp or a sensor. That is left to whatever the server does when a tool is called.

What device protocols do

MQTT is an OASIS standard messaging protocol for IoT, a lightweight publish and subscribe transport. Devices and services exchange messages on topics through a broker, which suits many small devices on unreliable links. It carries messages; the meaning of each topic and payload is up to the system that uses it.

Matter, from the Connectivity Standards Alliance, is an open, IP-based smart-home standard that runs over Wi-Fi and Thread, so a controller from one brand can operate a certified device from another. Many households also depend on vendor cloud APIs, where each brand defines its own authentication, device model and rate limits.

An MCP server for devices therefore needs at least one of these underneath. It can publish to an MQTT broker, act as a Matter controller, or call vendor APIs, and it maps the results back into tool responses.

Household use

In a home, the hard part is usually breadth: lights, speakers and vacuums from different brands, each with its own app and account. A household MCP server is most useful when it hides those differences behind a small set of tools, so the same request works whichever brand answers it.

Port OS takes this approach. Its hosted MCP server at https://api.portoperatingsystem.com/mcp uses Streamable HTTP with OAuth sign-in, and it reaches devices through each provider's own cloud API, such as Philips Hue, Sonos and Roborock. An assistant finds devices with endpoint_query and sends commands with control. How the Port OS MCP integration works walks through one request end to end.

For a household, check three things in any device MCP server:

  • Which brands and models it supports, and which actions it exposes for each.
  • How it signs you in, and whether you can limit an assistant to reading state or to specific devices.
  • Whether it reports a fresh state after a command, so you can tell the command worked.

Industrial and fleet use

Industrial use cases tend to put the MCP server close to the equipment. AWS published an example on September 1, 2026, that deploys MCP servers with AWS IoT Greengrass for edge diagnostics. The server runs as a Greengrass component, exposes diagnostic tools such as ping, traceroute and SNMP queries to a local agent over stdio, and syncs results to the cloud through AWS IoT Core topics when a connection is available. The authors describe a workflow where "the system recommends, and the operator acts."

That pattern differs from a household one in a few ways. The agent often runs at the edge, the tools are diagnostics over a site's own network, and a human operator approves changes. Device messaging such as MQTT keeps doing the fleet's day-to-day work; MCP gives the agent a structured way to ask questions of it.

Choose where MCP goes

Put MCP where an AI application needs to discover and call device actions. Keep the device protocol you already have for the devices themselves, because MCP does not replace a broker, a Matter fabric or a vendor's API.

If you want an assistant to control household devices across brands without running a server, start with the smart home MCP overview. To compare hosted and self-run options for a home, read smart home MCP servers compared.

References

All posts