Distributed AI-Controlled RF Sensing
The MCP integration covered in an earlier post demonstrated how an AI agent can configure and control a single SDR — telling Mycelium to tune to a frequency, decode a protocol, and return structured data to the LLM's context window. That's a significant step beyond a static CLI, but it still treats Mycelium as a single-node tool.
Combining MCP with Mycelium's native encrypted mesh removes that boundary entirely. The AI connects to one central Mycelium node. That node is a member of a live mesh of edge sensors — each running its own SDR on a different frequency band at a different physical location. From inside that single MCP session, the AI can reach every sensor in the mesh, configure tools on remote nodes, and pull decoded RF data from the entire fleet into a single context window.
The Scenario
Three edge nodes are already deployed across a facility: sensor_aero watching the 1090 MHz ADS-B band, sensor_acars monitoring 131.725 MHz, and sensor_iot covering the 433 MHz ISM band. A fourth node, soc, runs in the security operations center with an MCP server exposed to an AI agent. All four nodes discovered each other automatically when they came online.
Step 1: The AI Surveys the Mesh
Once connected, the AI's first move is to list the known nodes. This gives it the full topology — node names, connectivity status, and hop counts — before it touches any hardware.
Step 2: Configuring Remote Sensors via @NODE Routing
With the topology in hand, the AI configures each remote sensor using Mycelium's @NODE command routing. Every CLI command prefixed with @<node_name> is routed over the mesh and executed on the target node, with the response returned to the issuing node. The AI drives this the same way a human operator would — except it can configure all three sensors in parallel.
For the ADS-B sensor, the AI issues:
@sensor_aero tool create -p ModeS -n adsb_rx @sensor_aero tool set -n adsb_rx -r RTLSDR_0 -f 1090000000 -m PPM @sensor_aero directive create -t adsb_rx -n rx -c Null -a Receive @sensor_aero directive create -t adsb_rx -n fwd -c Any -a Send_To_Tool -T soc:collector @sensor_aero execute -n adsb_rx
It repeats the same pattern for sensor_acars (ACARS, 131.725 MHz) and sensor_iot (ISM_Generic, 433 MHz). Each tool is configured to forward decoded frames to soc:collector — a tool on the central node — using NODE:TOOL addressing over the mesh.
Step 3: The Central Collector
The SOC node runs a single collector tool with no SDR attached. Its only job is to receive data from any sensor node and queue it for the AI via MCP_Output.
tool create -p Raw -n collector directive create -t collector -n recv -c Null -a Receive_From_Tool -b directive create -t collector -n out -c Any -a MCP_Output -m "sensor data" execute -n collector
The -b flag on Receive_From_Tool makes the directive block until data arrives rather than spin. As decoded frames arrive from any of the three remote sensors, the collector wakes, tags the payload, and pushes it into the MCP output queue where the AI agent is waiting.
Step 4: The AI Synthesizes Findings
From the AI's perspective, it is calling receive_data on a single MCP tool and receiving a stream of structured events from across the entire sensor mesh. It can correlate aircraft position reports from ADS-B against ACARS datalink traffic from the same ICAO address, flag anomalous ISM activity, and surface findings in natural language — all without the operator manually moving between terminals or stitching together log files.
Why This Architecture Works
The separation of roles is what makes this composable. The AI doesn't need to understand SDR hardware or directive syntax — it issues the same CLI commands a human operator would, routed transparently over the mesh. The mesh handles encrypted transport, node discovery, and multi-hop routing. The collector tool handles fan-in from any number of sensors. And the MCP layer presents a clean, structured interface to the LLM.
Adding a fourth sensor to the mesh requires only deploying another Mycelium instance. The AI can discover it on the next node show call and configure it without any changes to the central node's setup.
Conclusion
Single-node MCP control gives an AI agent access to one SDR. Mesh-backed MCP gives it access to every SDR in the deployment — past subnets, across buildings, across geographic distances. The operator describes what they want to monitor; the AI handles the configuration, the data collection, and the analysis across the entire physical footprint from a single session.
← Back to Blog