DEV Community

Peter H
Peter H

Posted on

I connected Cursor IDE to a Raspberry Pi via MCP — controlled relays and read an I2C sensor in natural language

#raspberrypi #mcp #cursor #ai

If you've ever set up a Raspberry Pi project, you know the drill — SSH into the device, write custom scripts, debug GPIO issues, repeat. It works, but it's tedious.

I wanted to try something different: what if an AI assistant could talk directly to the hardware?

This is what I built — a Raspberry Pi with a 2-relay HAT and a BMP280 pressure sensor, controlled entirely via natural language through Cursor AI using the Model Context Protocol (MCP).

No SSH. No custom scripts. Just ask.

Here's the demo in action:

https://youtu.be/PaKN3fWGJWk?si=nFGmwtecihj2VDOb

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external tools and services. Think of it as a bridge between an AI client (like Cursor) and a system that exposes a set of tools the AI can call.

In this case, the "system" is a Raspberry Pi running Orbit OS — an Android-like platform for embedded Linux that exposes device capabilities as secure APIs.

The Setup

Hardware:

  • Raspberry Pi 4
  • 2-relay HAT (Relay 1 = GPIO5, Relay 2 = GPIO6, active-low)
  • BMP280 pressure/temperature sensor (I2C bus 1, address 0x77)

Software:

  • Orbit OS (Community Edition)
  • MCP Server app — installed from the Orbit OS Store in one click
  • Cursor AI with MCP configured

Installing the MCP Server

The MCP Server app is available on the Orbit OS Store. One click to install — no Docker, no SSH, no configuration files.

Once installed, the device exposes an MCP endpoint at:


http://<DEVICE_IP>:9999/mcp
Enter fullscreen mode Exit fullscreen mode

To connect Cursor, add this to your MCP config:

{
  "mcpServers": {
    "orbit-os": {
      "url": "http://<DEVICE_IP>:9999/mcp"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

That's the entire setup.

What the AI can do

The MCP Server exposes tools that the AI can call directly:

  • System — device info, OS/runtime info, live metrics
  • GPIO — list pins, set direction, read/write state
  • I2C — scan bus, transfer bytes directly
  • Apps — list, install, uninstall .orb packages
  • Power — reboot or shutdown the device
  • Update — OTA install, factory reset

And more — WiFi, Bluetooth, SPI, UART, PWM, Ethernet.

The Demo

Before starting the demo, I told Cursor the relay mapping and that there's an I2C device on bus 1 to be discovered. The AI was instructed to always call the MCP tools — never simulate hardware states.

Device Info 

Me: Give me the device info

Cursor: Device info — Raspberry Pi 4:
OS: Orbit OS | Kernel: Linux ARM64
CPU: Cortex-A72 | RAM: 1GB
Storage: 16GB | Architecture: ARM64
Enter fullscreen mode Exit fullscreen mode

System Health 

Me: Is the device healthy?

Cursor: Device health check:
✓ CPU temp: 42°C — normal
✓ RAM usage: 14% — normal
✓ Storage: 34% — normal
Device is healthy.
Enter fullscreen mode Exit fullscreen mode

GPIO Enumeration 

Me: List all available GPIO lines

Cursor: [fetches live GPIO list from the device via MCP]
GPIO5 — input, unused
GPIO6 — input, unused
GPIO17 — input, unused
...
Enter fullscreen mode Exit fullscreen mode

Relay Control 

Me: I have a 2-relay HAT. Relay 1 is GPIO5, Relay 2 is GPIO6. Both active-low. Take note.

Cursor: Understood.
Relay 1 = GPIO5 | Relay 2 = GPIO6 | Logic: active-low.
Ready when you want to control them.

Me: Turn on all relays

Cursor: Turning on all relays.
✓ GPIO5 low, GPIO6 low — active-low applied.
Relay 1 = ON, Relay 2 = ON.
Enter fullscreen mode Exit fullscreen mode

The relay LEDs light up physically on the HAT.

I2C Scan 

Me: Scan the I2C bus and tell me what you find

Cursor: Scanning I2C bus 1...
✓ Device found at 0x77 — BMP280 (temperature and pressure sensor).
Ready to read.
Enter fullscreen mode Exit fullscreen mode

The AI discovers the sensor on its own — no prior knowledge of the address.

Sensor Reading 

Me: Read the current temperature and pressure

Cursor: Reading BMP280 @ 0x77, bus 1:

TX: [0xF7] → RX: [0x56, 0x91, 0x20]
📊 Pressure: 961.2 hPa

TX: [0xFA] → RX: [0x83, 0x01, 0x00]
🌡️ Temperature: 25.6°C
Enter fullscreen mode Exit fullscreen mode

The raw I2C bytes are shown alongside the decoded values — the AI reads the registers directly using the MCP I2C transfer tool.

Remote Reboot 

Me: Turn off all relays and reboot the device

Cursor: Turning off all relays and rebooting.
✓ GPIO5 high, GPIO6 high — both relays OFF.
Rebooting now — device back online in ~30 seconds.
Enter fullscreen mode Exit fullscreen mode

Yes, it actually reboots.

Why This Matters

The interesting part here isn't just the demo — it's what it represents.

Traditionally, interacting with embedded hardware requires:

  • Knowledge of GPIO numbering, I2C addresses, register maps
  • Custom scripts for every operation
  • SSH access and terminal familiarity With MCP + Orbit OS, the AI handles all of that. You describe what you want in natural language, and the AI translates it into the correct hardware operations via the MCP tools.

The I2C sensor reading is a good example of this. I didn't tell the AI which registers to read, what the raw bytes meant, or how to convert them into temperature and pressure values. I just asked for a reading. The AI knew the BMP280 chip by name, looked up the register map from its own knowledge, transferred the bytes directly via the MCP I2C tool, and converted the raw values — all on its own.

This opens up embedded Linux hardware to a much wider audience — developers who know AI tools but don't have deep embedded experience can now interact with real hardware without the usual friction.

What is Orbit OS?

Orbit OS is a recent open-core platform for embedded Linux and edge devices — inspired by Android's architecture.

One of the core goals behind it is to accelerate embedded hardware development by removing the complexity of deployment, updates, and infrastructure — so developers focus only on their app logic. Just like Android lets you build mobile apps without knowing how the Linux kernel works underneath, Orbit OS lets you build applications and services for embedded Linux without needing any Linux knowledge at all.

It provides:

  • A lightweight runtime (Gravity RT) that manages app lifecycle, hardware access, and OTA updates
  • A multi-language SDK (Go, Python, Java, C++) for building apps
  • An App Store for one-click distribution of .orb packages
  • Built-in AI inference support (TFLite, ONNX) Community Edition supports Raspberry Pi 3, 4, 5, Zero 2W and Arduino UNO Q.

Beyond these officially listed boards, any ARM Linux device (armv6, armv7, or arm64) can be certified to run Orbit OS — for example, Banana Pi, Orange Pi, BeagleBone, and NVIDIA Jetson boards.

Try It

- 🎬 YouTube — @orbit-os-edge

*Have questions or want to build something on Orbit OS?

Top comments (0)