IoT-MCP hits 100% tool-call success at 205 ms across six MCU families

We talk a great deal about large language models and the smart home, but the conversation rarely reaches actual hardware. In IoT, every microcontroller, sensor and protocol plays by its own rules. An LLM will answer questions about them readily enough, yet it has no painless way to negotiate with devices that keep dropping off the network or returning data in unexpected formats. The authors of IoT-MCP propose the missing bridge — tidy, standardized and fast. It lets an LLM talk to IoT hardware without a pile of custom scripts and brittle integrations.

What the authors built

The foundation is the Model Context Protocol. It describes tools and their context so that an LLM can pick and invoke the action it needs. IoT-MCP carries that idea into the physical world of sensors: the architecture splits into three clear layers — a Local Host, a Datapool & Connection Server, and the IoT devices themselves. That split of responsibilities is the main engineering win. One layer thinks and chooses, the second holds connections and queues requests, the third reads the sensors and returns the data.

How it works under the hood

• On the local host, next to the LLM, sit narrowly scoped MCP servers. Each one owns a single group of sensors, so the LLM picks the right tool without confusion. The server emits a compact JSON instruction carrying the command, a duration and an interval.
• The Datapool & Connection Server sits between the brain and the hardware. It assigns unique IDs to requests, buffers them, smooths over dropped links and scales parallel operations. That keeps heavy logic off the MCU and keeps conversations with the LLM from timing out.
• On the devices themselves run lightweight microservices: they connect over Wi-Fi, Bluetooth or I2C, poll the peripherals and return a response with timestamps, sensor type and data. Adding a new sensor means extending the set of microservices rather than rewriting everything from scratch.

What they tested, and how

The authors did not stop at a demo. They also propose a benchmark of their own, IoT-MCP Bench: 114 base tasks and 1,140 harder variants. The scenarios run from plain reads up to compositions that require joining, filtering and interpreting data, and coping with ambiguously worded prompts. Three headline metrics: tool-call success rate, mean response time and peak memory on the MCU. Plus tests of robustness, request concurrency and deployment stability.

What the experiments showed

• A 100% tool-call success rate on the base tasks. That is a meaningful signal: the MCP layer and the binding to hardware are wired up reliably.
• Mean latency of 205 ms. Most of it goes on the trip through the Connection Server and the exchange with the MCU. At idle, the network alone costs about 128 ms.
• Peak memory on the devices averages 74 KB, against roughly 51 KB at idle. That leaves headroom for parallel requests without sudden stalls.
• Prompt robustness on the hard tasks: 99%. The usual stumbling blocks are the LTR390 and MPU6050 sensors, in multi-read scenarios and in read-everything mode.

Across models, and under concurrency

The system was tested with several LLMs: Claude 3.5 (Haiku and Sonnet) held up best. Move to DeepSeek V3 and GPT-4.1 and the success rate drops noticeably — to roughly 77% and 84% of the Claude level — which the authors put down to differences in how parameters are interpreted and in tool-calling conventions. Under parallel load, latency on some sensors rises gradually, and scaling holds up to four simultaneous tasks with no sharp drop-offs.

Field deployment

The most valuable part is the real deployment. Six ESP32-S3 controllers with seven sensor types ran for 12 hours. Connections re-established themselves automatically after power and network cuts, and the data kept coming. This already looks like a mature engineering system rather than a lab prototype.

The bottom line

As it stands, IoT-MCP is aimed at sensors, not actuators. Controlling devices and closing the loop is the next step. Another direction is automatic workflow composition: the LLM not simply calling a tool but building a plan, choosing fault-tolerance strategies and optimizing for cost and latency. And then security: at scale you need authorization, throttling and graceful degradation.

In short, IoT-MCP removes the central pain of integration work: it breaks the monolith into clear roles, standardizes the tools an LLM sees, and makes it easier to scale across different microcontrollers and sensors. It also offers one way to evaluate the result, from call semantics through to system metrics. A 100% tool-call success rate, 205 ms of latency and a 74 KB memory peak are numbers you can already build production monitoring on, and move toward control from there.

💾 Code