SdrMcp.md

Comparison of SDR + MCP + LLM Proposals

This document compares three related proposals for integrating software-defined radio (SDR) systems with Model Context Protocol (MCP) interfaces and LLM-driven control.

Projects studied:

• SDRAngel driven by Ollama LLM using MCP
• gr-mcp
• AetherLink SDR-MCP

---

Project Summaries

Project	Purpose / Use Case	Primary Components / Features
SDRAngel + Ollama LLM + MCP	Natural language control of SDRangel via Ollama. User commands are interpreted by an LLM and mapped into SDRangel API calls.	SDRangel; Ollama; Node-RED MCP server/bridge; dashboard/chat UI; JSON schema registry of tools; man-in-the-middle confirmation before execution.
gr-mcp	MCP server for GNU Radio. Lets clients (including LLMs) generate, edit, and execute .grc flowgraphs to control SDR workflows.	Python MCP server; flowgraph editing and validation; exposes SDR controls as MCP tools; example flowgraphs.
AetherLink SDR-MCP	General MCP server for SDR hardware + decoding. Supports protocol decoders (ADS-B, AIS, NOAA, etc.), spectrum/waterfall display, and integration with Claude Desktop or other MCP clients.	MCP tools like sdr_connect, sdr_set_frequency, spectrum_analyze; protocol decoders; hardware support (RTL-SDR, HackRF); hosted via JuheAPI.

---

Common Core Design

Across all three efforts, a shared design pattern emerges:

1. SDR Control Plane
   Expose hardware/software SDR capabilities (frequency tuning, gain, decoding, scanning) via structured tools.

2. Model Context Protocol (MCP) Interface
   Use MCP to describe available tools, their parameters, and schemas in a way that AI agents or clients can discover and invoke.

3. Middleware / Bridge Layer
   Translate MCP tool calls into SDR software or hardware actions. Acts as a control gateway.

4. LLM or AI Agent Client
   Interpret natural-language user input into structured tool calls using the MCP schema.

5. Feedback and State Reporting
   Commands return status, results (decoded data, waterfall plots, etc.), or errors back to the client/LLM.

---

Differences Between Approaches

• Hardware Support

  • AetherLink: RTL-SDR, HackRF (explicit).
  • SDRangel: Broad device support.
  • gr-mcp: Tied to GNU Radio (supports many SDRs indirectly).

• Client Complexity

  • SDRangel + Ollama: Node-RED dashboard and chat.
  • AetherLink: Service with MCP client support (Claude, etc.).
  • gr-mcp: Minimal interface, flowgraph manipulation.

• Level of Abstraction

  • AetherLink: High-level tools (“decode ADS-B”).
  • gr-mcp: Low-level flowgraph building.
  • SDRangel + Ollama: Middle ground (direct SDRangel controls).

• Safety / Oversight

  • SDRangel project emphasizes user confirmation before action.
  • Others assume trusted commands.

• Deployment Style

  • SDRangel + gr-mcp: Self-hosted / local.
  • AetherLink: API / service model.

---

Strengths

• Natural language control lowers expertise barrier.
• MCP modularity allows hardware/software interchangeability.
• Automation of repetitive SDR workflows.

---

Challenges & Gaps

• Correctness / Safety: LLM errors can misconfigure SDR. Need constraints and validation.
• Latency: Real-time SDR demands may conflict with LLM/middleware overhead.
• Abstraction Balance: Too low-level = complexity; too high-level = loss of control.
• Data Handling: Large volumes (IQ streams, waterfalls) require efficient handling.
• Schema Maintenance: Tool definitions must evolve with hardware/software.

---

Conclusion

Yes, these proposals share a common core architecture:

MCP-based tool registry → SDR middleware bridge → LLM or AI client to interpret user intent → feedback/monitoring loop.

They differ mainly in scope (low-level vs high-level tools), deployment model (self-hosted vs service), and safety controls.

---