MCP-Edge
Enables cloud LLM agents to discover and invoke physical hardware on edge and IoT devices through standard MCP tools, bridging constrained device channels like UART, BLE, and Wi-Fi.
README
MCP-Edge
Extend the Model Context Protocol (MCP) to edge and IoT devices.
MCP-Edge lets cloud LLM agents discover and invoke physical hardware through the same tool interface they already use for software APIs. It provides:
- a gateway that bridges cloud-native MCP transports (SSE / HTTP) to constrained device channels (UART, BLE, local Wi-Fi), presenting every downstream device as a standard MCP tool provider;
- MCP-Lite, a lightweight MCP server for devices with as little as ~512 KB of RAM;
- a four-tier device taxonomy (constrained MCUs, smart IoT nodes, BLE-only wearables, Linux-class edge computers) that maps an MCP strategy to each tier;
- protocol adaptations for constrained links: CBOR encoding, schema caching, connection pooling, and offline request buffering.
Status: alpha, under active development. The public API is unstable and will change. This repository is a reference implementation of the framework described in the MCP-Edge paper (IEEE Cloud Summit 2026). Performance figures reported in the paper are projected estimates, not measurements taken from this codebase. The full gateway path is exercised against simulated devices. A serial/UART transport has landed in the codebase — validated in software against an in-memory fake, but not yet exercised on physical hardware or paired with example firmware; BLE and Wi-Fi transports arrive in a later version.
Installation
Requires Python 3.10+.
pip install mcp-edge
For development, install from source:
git clone https://github.com/jemsbhai/mcp-edge
cd mcp-edge
pip install -e ".[dev]"
Quickstart
Run a demo gateway — an MCP server exposing two simulated devices over stdio:
mcp-edge run --demo
This serves a simulated sensor (read_temp, read_humidity) and a simulated ring
(heart_rate), each tool namespaced by device (sensor-01/read_temp, ...). To drive it
from an MCP client such as the MCP Inspector or Claude Desktop, configure a stdio server
with command mcp-edge and arguments ["run", "--demo"]. The process logs to stderr and
waits for a client on stdin.
Use the gateway as a library:
import asyncio
from mcp_edge.client import MCPLiteClient
from mcp_edge.devices import SimulatedDevice
from mcp_edge.gateway import Gateway
from mcp_edge.registry import DeviceRegistry
from mcp_edge.tiers import Tier
from mcp_edge.transports import LoopbackTransport
async def main() -> None:
device = SimulatedDevice("sensor-01")
device.add_tool("read_temp", lambda args: {"celsius": 21.5})
transport = LoopbackTransport(device.handle)
await transport.open()
registry = DeviceRegistry()
registry.register("sensor-01", MCPLiteClient(transport), Tier.SMART_NODE)
gateway = Gateway(registry)
print([tool["name"] for tool in await gateway.list_tools()]) # ['sensor-01/read_temp']
print(await gateway.call_tool("sensor-01/read_temp", {})) # {'celsius': 21.5}
asyncio.run(main())
Connect your own device over serial (experimental) — install the serial extra
(pip install "mcp-edge[serial]") and point SerialTransport at the port your device is
on. It exposes the same Transport interface, so it drops into the example above in place
of LoopbackTransport:
from mcp_edge.transports import SerialTransport
# "COM3" on Windows, "/dev/ttyUSB0" on Linux/macOS
transport = SerialTransport("COM3", baudrate=115200)
Frames use a length-prefixed wire format — a 2-byte big-endian length followed by the CBOR
payload — documented in transports/serial.py. Device firmware must frame its replies the
same way; the exported encode_frame / decode_frame helpers make that straightforward.
This path is not yet validated on physical hardware, and example firmware is still in
progress.
Roadmap
- [x] v0.1 — gateway core, in-process (loopback) transport, protocol adaptations (CBOR, schema caching, connection pooling, offline buffering), device simulator, health monitor, CLI, hermetic CI
- [ ] v0.2 — real transports and Wokwi firmware-in-the-loop
tests (Arduino / ESP32 / RP2040). The serial/UART transport (
pyserial) has landed (software-tested); BLE and Wi-Fi/mDNS are still to come - [ ] v0.2+ — Edge Impulse (inference as an MCP tool) and Arduino IoT Cloud (properties as MCP) integration examples; Renode / QEMU backends
Development
pip install -e ".[dev]"
pytest -q
ruff check .
License
MIT — see LICENSE.
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
E2B
Using MCP to run code via e2b.
Neon Database
MCP server for interacting with Neon Management API and databases
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.