I connected Cursor AI to a Raspberry Pi via MCP

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 i2c 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:

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.

Components

Component                 Details
Raspberry Pi 4            Any RAM variant
2-relay HAT               Relay 1 = GPIO5, Relay 2 = GPIO6, active-low
BMP280 sensor             I2C, address 0x77
I2C cable                 4-wire — SDA, SCL, VCC, GND
MicroSD card              8GB+ with Orbit OS installed

Software:

• Orbit OS Community Edition — orbit-os.org
• MCP Server app — Orbit OS Store
• Cursor AI

Step 1 — Install Orbit OS

Download and install Orbit OS Community Edition to a MicroSD card from orbit-os.org/downloads.html.

Boot the Pi and complete the initial setup via the Orbit OS web interface.

Step 2 — Install the MCP Server app

Open the Orbit OS App Store and search for MCP Server. Click install — no Docker, no SSH, no configuration files needed.

Once installed, the device exposes an MCP endpoint at:

http://DEVICE_IP:9999/mcp

Step 3 — Configure Cursor AI

Add the following to your Cursor MCP config file:

{ "mcpServers": { "orbit-os": { "url": "http://DEVICE_IP:9999/mcp" } }}

Replace DEVICE_IP with your Pi's IP address. That's the entire setup.

Step 4 — Run the Demo

Open a new chat in Cursor. The AI now has access to all MCP tools exposed by the Orbit OS device.

Get device info:

Me: Give me the device info

Cursor:
Device Name: rpi4:
Architecture: arm64
OS: Orbit OS 
OS version: 26

List GPIOs

Me: List all available GPIO lines

Cursor:
GPIO4          Line 4
GPIO5          Line 5
GPIO6          Line 6
GPIO7          Line 7
GPIO12         Line 12
...
18 lines total, all on gpiochip 0.

Get device status:

Me: What is the current status of the device ?

Cursor: 

System Status
⏱️ Uptime: 2h 18m
🔲 CPU: 7.7%
🌡️ SoC Temp: 51.6°C
🧠 RAM: 14% used
💾 Disk: 34.4% used

Network
📶 WiFi (wlan0) 192.168.1.217 — WPA2 — signal -58dBm
🔌 Ethernet (eth0)192.168.1.51

✅ Device is online, healthy, and connected on both WiFi and Ethernet.

Control the relays:

Me: Turn on all relays

Cursor: 
Both relays are ON - GPIO5 and GPIO6 set as outpuyts and driven low (active-low), Relay 1 and Relay 2 are energized.

Scan the I2C bus:

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

Cursor:
I2C Scan - bus 1

Address        Notes
0x38           Responding device 
0x77           Often a BMP280/BME280 (pressure/temp sensor)

2 devices found on /dev/i2c-1. Want me to probe either address to identify them?

Read the BMP280 sensor:

Me: Read the current temperature and pressure of BMP280 i2c sensor.

Cursor:
Reading temperature and pressure from BMP280 at 0x77 on I2C bus 1.

BMP280 @ 0x77 (bus1)

Pressure (reg 0xF7 - 0xF9)
TX: [0xF7] -> RX [0x56, 0x91, 0x20]
📊 961.2 hPa

Temperature (reg 0xFA - 0xFC)
TX: [0xFA] -> RX [0x83, 0x01, 0x00]
🌡️25.6ºC

Reboot the device:

Me: Turn off all relays and reboot the device

Cursor: 
Turning off both relays, them rebooting the device.

Both relays are OFF (GPIO5 and GPIO6 driven high), Reboot requested - the Raspberry Pi is restarting now.

What the MCP Server exposes

• 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
• Update — OTA install, factory reset
• And more — WiFi, Bluetooth, SPI, UART, PWM, Ethernet

Why This Matters

Traditionally, interacting with embedded hardware requires knowledge of GPIO numbering, I2C addresses, register maps, and custom scripts for every operation. With MCP + Orbit OS, the AI handles all of that.

The I2C sensor reading is a good example. I didn't tell the AI which registers to read, what the raw bytes meant, or how to convert them. I just asked for a reading. The AI knew the BMP280 by name, looked up the register map from its own knowledge, 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 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.

Community Edition supports Raspberry Pi 3, 4, 5, Zero 2W and Arduino UNO Q. Any ARM Linux device (armv6, armv7, arm64) can also be certified — Banana Pi, Orange Pi, BeagleBone, NVIDIA Jetson.

🔗 MCP Server: https://store.orbit-os.org/app/app-mcp-server🔗 Orbit OS: https://orbit-os.org🎥 Demo: https://youtu.be/PaKN3fWGJWk?si=nFGmwtecihj2VDOb🎬 YouTube: https://youtube.com/@orbit-os-edge💬 Forum: https://forum.orbit-os.org