AppMatic Tech engineers MCP (Model Context Protocol) servers that let AI agents send controlled commands to physical devices, wrapping each actuation in typed action schemas, human confirmation, allowlists, and append-only audit logging over Node.js, TypeScript, and the device's BLE or MQTT command API. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
There is a growing appetite to put an AI agent in front of the connected devices around a business, not just to ask them questions but to tell them what to do. Turn that valve down, unlock that door, set that machine to standby, dim those lights. Reading a device through an MCP server is a query problem that is largely solved. Letting an agent command the device is a different problem, and treating it like a bigger query is how hardware gets damaged and people get hurt.
This article covers the architecture that makes agent-driven device control safe: what the MCP server actually does, how unsafe commands are stopped, how commands stay reliable on real radios, what must be logged, and where the line is that an AI agent should not cross. It is the control-side companion to MCP Server for IoT Device Management, which covers the read-only query architecture.
Key takeaways
Device control through an AI agent is an access-control and safety problem wearing an AI feature's clothes.
| Point | Detail |
|---|---|
| Control is not a bigger read | Reading returns data. Commanding changes physical state, which is irreversible in a way a query never is. |
| The MCP server is a governed boundary | The agent sees only typed action tools, never the raw device API, so it can issue defined commands and nothing else. |
| Safety is layered, not trusted to the model | Allowlists, hard parameter bounds, rate limits, and state interlocks sit between the agent and the device. |
| Safety-critical actions need a human gate | For anything that can cause harm, the model proposes and a person or a deterministic rule authorises. |
| Reliability reuses BLE discipline | Idempotency keys, command acknowledgement, and queueing prevent double-execution and lost commands. |
| Every command is audited | An append-only log records who requested what, when, and what the device did, for replay and accountability. |
Why is commanding a device different from reading one?
A read query is safe to get wrong. If an agent misreads a request and returns the wrong sensor value, the cost is a confusing answer, and the next query corrects it. A command is not safe to get wrong. If an agent sends the wrong command to a physical device, the state has already changed, and no follow-up query undoes it.
The difference shows up across three properties.
| Property | Reading a device | Commanding a device |
|---|---|---|
| Effect | Returns data, changes nothing | Changes physical state |
| Reversibility | Fully reversible, just query again | Often irreversible once executed |
| Failure cost | A wrong or stale answer | Damaged hardware, lost work, or physical harm |
This is why an MCP server built for control cannot be a read-only server with a few write tools bolted on. The read-only architecture optimises for query throughput and freshness. The control architecture optimises for making sure the only commands that reach the device are ones that were defined in advance, validated at the moment, authorised where required, and recorded after. Those are different design centres, and AppMatic Tech scopes them as different builds.
Pro tip: Before designing any agent-driven control, list every command the agent could issue and mark each one reversible or irreversible. The irreversible list is the real specification. It defines where confirmation, interlocks, and human authorisation are mandatory rather than optional.
What does an MCP device-control server actually do?
An MCP device-control server sits between the AI agent and the device's command interface as a governed boundary. The agent never holds the device credentials and never calls the raw device API. It sees only a set of typed action tools the MCP server exposes, and each tool maps to one specific, permitted command.
Concretely, the server does four things on every action.
- Exposes commands as typed tools. Each device command is defined as an MCP tool with a typed input schema, so "set thermostat" accepts a temperature within a declared range and nothing else. The agent cannot invent a command that has no tool.
- Validates before executing. The server checks the request against an allowlist, the parameter bounds, the current device state, and the calling user's permissions before it forwards anything to the device.
- Executes through the device's own command path. The validated command is sent over the device's real interface, BLE, MQTT, or a device management API, using credentials the server holds and the agent never sees.
- Records and returns the result. The command, its outcome, and the device acknowledgement are written to an append-only log, and a structured result returns to the agent.
The design principle is least authority. The agent is given the smallest possible set of actions that satisfy the use case, each as narrow as the task allows, rather than a general ability to control the device. This is the same governed-boundary pattern AppMatic Tech uses for MCP servers that reach sensitive business data, described in MCP Server Security, applied to a device instead of a database.
How do you stop an AI agent from sending an unsafe command?
The wrong answer is to trust the language model to be careful. Models are useful at proposing actions and unreliable as the last line of defence, so the safety guarantees live in deterministic code between the agent and the device, not in the prompt. AppMatic Tech layers the following controls, and a command must pass all of them.
| Guard | What it enforces |
|---|---|
| Command allowlist | Only explicitly defined commands exist as tools; anything else is impossible, not just discouraged. |
| Typed parameter bounds | Each argument has a hard minimum and maximum, so an out-of-range value is rejected before execution. |
| State interlocks | A command is refused when the device is in a state that makes it unsafe, such as actuating while a guard condition is unmet. |
| Rate limiting | Command frequency is capped, so a runaway agent cannot flood the device with actions. |
| Human confirmation | Safety-relevant actions require an explicit approval step before the command reaches the device. |
| Scoped credentials | The calling user's permissions are enforced, so an agent cannot act on a device the user may not control. |
The human confirmation step deserves emphasis, because it is what changes the model's role from actor to proposer. For a low-risk action, such as dimming a light, the agent can execute directly within its bounds. For a consequential action, the agent proposes the command and a person authorises it, or a deterministic rule authorises it automatically only when a defined, verifiable condition holds. The language model never has the final say on an action that can cause harm.
Pro tip: Put the safety bounds in the MCP server, never only in the tool descriptions. A bound that lives in the prompt is a suggestion the model can misread. A bound that lives in validation code is a rule the model cannot cross, no matter what it is asked.
How are commands made reliable on real hardware?
Software integrations can assume the network mostly works. Device control cannot. Radios drop, devices go to sleep, and a command sent into a dropped connection has an unknown fate. Reliable control reuses the same discipline AppMatic Tech applies to Bluetooth Low Energy, documented across six shipped integrations in BLE Mobile App Development.
Three patterns carry over directly.
Idempotency. Every command carries an idempotency key, so if a dropped acknowledgement causes a retry, the device recognises the repeat and does not execute the action twice. Without this, a lost acknowledgement on an "unlock" or "dispense" command becomes a double action.
Acknowledgement before the next command. Commands are not fired and forgotten. Each waits for explicit acknowledgement from the device before the next is sent, which on BLE means an ordered queue rather than concurrent writes. Concurrent writes drop packets and, on Android, surface as GATT error 133, a failure mode AppMatic Tech designs out with a FIFO queue and explicit acknowledgement.
Disconnection as a normal state. A dropped link is expected, not exceptional. The control path defines what happens to an in-flight command when the connection drops, reconnects silently, and reports the true device state rather than assuming the last command succeeded.
The reliability question an agent-controlled device must answer is not "did I send the command" but "did the device do the thing, and do I know its state now." That distinction is the difference between a demo and a system that can be trusted to act on hardware.
What must be logged when an agent controls a device?
Every command an agent issues is an action taken on physical hardware, which means it needs the accountability of an action, not the light touch of a query log. AppMatic Tech writes an append-only audit record for every command, capturing enough to answer, after the fact, exactly what happened and why.
Each record captures:
- The calling user or agent identity, so every command is attributable to a principal.
- The command and its parameters, exactly as validated and sent.
- The timestamp and the device's state at the moment of the command.
- Whether a human confirmation was required and who gave it.
- The device's acknowledgement and the resulting state.
The log is append-only because an audit trail that can be edited is not an audit trail. This record is what makes an agent-controlled device operable in a regulated or high-value setting, because it turns "the AI did something" into a precise, replayable account of who authorised what and how the device responded. It is the same audit discipline AppMatic Tech builds into MCP servers for clinical and financial data, applied to a physical actuator.
Pro tip: Log the device's acknowledged state after the command, not just the command sent. The gap between "command issued" and "device confirmed in the new state" is where the hard failures hide, and only the acknowledged-state log surfaces them.
When should an AI agent not control a device?
Not every device command belongs behind an AI agent. The line AppMatic Tech draws is physical safety: when a wrong or mistimed command can cause harm, the write path stays behind deterministic logic and human authorisation, and the agent is limited to reading and proposing.
This is a lesson from shipping a safety-critical BLE write path, not a theoretical position. The Ebike Companion App included writing commands to a moving electric vehicle, covering vehicle control, the battery management system, and anti-theft locking. Writing a command to moving hardware is a different risk class from reading a value off a sensor, and that build was architected as native iOS with tight control over connection state and command acknowledgement precisely because the write path could not tolerate the uncertainty an agent would introduce.
The decision rule that follows:
- If the action is reversible and low-consequence, an agent can execute it within hard bounds.
- If the action is consequential but not safety-critical, an agent can propose it and a human authorises it.
- If the action is safety-critical, keep it behind deterministic control and human authorisation, and use the agent to inform, not to actuate.
An honest MCP device-control architecture is as much about the commands it refuses to expose to the agent as the ones it does.
What does an MCP device-control build cost and take?
An MCP device-control server is scoped as a read-only build plus a control layer, because the safety and reliability work is what separates the two. AppMatic Tech finds the control layer, meaning the action schemas, validation, confirmation flows, and audit logging, adds roughly two to three weeks to the timeline of an equivalent read-only MCP deployment, and more when the write path is safety-critical and requires formal validation against failure modes.
The variable is the consequence of the commands, not their count. A handful of irreversible, safety-relevant commands takes more engineering than a long list of reversible, low-risk ones, because each irreversible command needs its own interlocks, confirmation path, and failure handling. For the base figures an MCP engagement starts from, see MCP Server Development Cost; the control layer is an increment on top of that, sized during discovery once the reversible and irreversible command lists are drawn.
Pro tip: Price the control build from the irreversible-command list, not the total command list. Ten reversible commands and one irreversible one is a one-command safety project with ten conveniences attached, and the one command is where the cost and the timeline live.
How AppMatic Tech approaches an MCP device-control engagement
AppMatic Tech has shipped 330+ products since 2017 with an 83% client retention rate and a 5.0 Clutch rating, and the two disciplines an agent-controlled device demands, MCP server engineering and safe hardware command paths, are both proven in shipped work rather than assembled for the first time on this build.
On the hardware-command side, the Ebike Companion App shipped a safety-critical BLE write path for a moving vehicle, and Trackwel shipped a factory-level device integration with a custom GATT layer and zero app-side BLE errors. On the MCP side, the read-only query architecture for connected fleets is covered in MCP Server for IoT Device Management, and the governed-boundary and audit patterns in MCP Server Security. An agent-controlled device build is the intersection of those two bodies of work.
The engagement follows a fixed-scope pattern: a discovery phase draws the reversible and irreversible command lists and defines the safety and audit requirements, the control layer is built and validated against the failure modes for each irreversible command, and the server ships with the append-only audit log and a documented recovery state for dropped commands. For the underlying protocol work see MCP Server Development, and for the device and firmware-facing side see IoT Application Development.
Contact AppMatic Tech at contact@appmatictech.com to scope an MCP device-control server for a connected product.
Related automotive guide from AppMatic Tech: MCP servers for vehicle, fleet, and dealer data, which applies the same approval rules to remote vehicle and charger commands.
Sources
| Claim used in this article | Source |
|---|---|
| Read-only IoT MCP architecture and the read-write boundary | MCP Server for IoT Device Management |
| Safety-critical BLE write path to a moving vehicle | Ebike Companion App case study |
| BLE reliability discipline: idempotency, acknowledgement, queueing, GATT error 133 | BLE Mobile App Development |
| Governed-boundary, allowlist, and audit patterns for MCP servers | MCP Server Security |
Frequently Asked Questions
- Can an AI agent control a physical device through an MCP server?
- Yes, but control is a different architecture from reading. AppMatic Tech builds MCP servers that expose device commands to an AI agent as typed action tools, each wrapped in an allowlist, bounds checking, optional human confirmation, and an append-only audit log. The MCP server is the governed boundary between the agent and the device command API, so the agent can only issue commands that are explicitly defined, validated, and recorded, never arbitrary access to the hardware.
- What stops an AI agent from sending an unsafe command to a device?
- A layered guard, not the model's own judgement. AppMatic Tech constrains each action tool with an allowlist of permitted commands, typed parameters with hard minimum and maximum bounds, rate limits, and interlocks that reject a command when the device is in a state that makes it unsafe. Safety-critical actions require an explicit human confirmation step before the command reaches the device, so the language model proposes an action and a person or a deterministic rule authorises it.
- How is device control made reliable over BLE or MQTT?
- Through command acknowledgement, idempotency, and queueing, the same discipline AppMatic Tech applies to Bluetooth Low Energy integrations. Every command carries an idempotency key so a retry after a dropped connection does not execute twice, each command waits for explicit acknowledgement from the device before the next is sent, and commands are queued rather than fired concurrently. A dropped link is treated as a normal condition with reconnection and a defined recovery state, not as a command failure.
- When should an AI agent not be allowed to control a device?
- When the command affects physical safety and a wrong or mistimed action causes harm. AppMatic Tech keeps safety-critical write paths, such as vehicle control or medical actuation, behind deterministic logic and human authorisation rather than model discretion. The lesson from shipping a safety-critical BLE write path for an electric vehicle is that writing a command to moving hardware is a different risk class from reading a value, and the architecture must reflect that.
- What does an MCP device-control build cost compared to a read-only one?
- The control layer adds to a read-only MCP build rather than replacing it. AppMatic Tech finds that the action schemas, confirmation flows, and audit logging required for command and control add roughly two to three weeks to the timeline of an equivalent read-only deployment, and more when the write path is safety-critical and needs formal validation. The read-only query layer and the read-write control layer are scoped separately for this reason.