ai-rover-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROVER_BRIDGE_PORT | No | The WebSocket bridge port. If you change it, the page needs ?mcpPort=<port> (open_simulator adds this for you). | 8765 |
| ROVER_SIMULATOR_URL | No | The page open_simulator opens instead of the hosted one. A URL (http://localhost:5173 while developing) or a path to a local build (dist/index.html, relative to the working directory). | |
| ROVER_ALLOWED_ORIGINS | No | Extra comma-separated https:// origins the bridge accepts (for a self-hosted copy of the simulator). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| open_simulatorA | Open the AI Rover Studio page in the default browser and wait (up to 15 s) for it to connect to this MCP server. |
| connection_statusB | Report whether the simulator page is connected to this MCP server. |
| get_observationA | Current robot pose (x, y, heading_deg), velocity, every enabled sensor reading, face display state, plus simulation status (running, autopilot, power, lamp position). |
| read_sensorsA | Fresh readings from all enabled sensors, with their mounting position, angle, range and unit. |
| driveA | Move the rover for a fixed time: forward / backward, or turn left / right in place. Turns autopilot off and starts the simulation. Rotation speed is about 2 rad/s (≈115°/s), so turning 90° takes ≈0.8 s. Forward speed is 65 % of max speed (≈61 px/s at the default 55 % power; backward ≈51 px/s). With wait=true (default) it returns the observation after the move finishes. The rover stops on collisions. |
| turnA | Turn the rover in place by an exact angle (+ = right / clockwise, − = left) at ≈115°/s, then return the observation. Unlike drive left/right there is no 0.2 s minimum, so small corrections (e.g. 7°) are exact. |
| run_programA | Run JavaScript on the robot with the |
| stop_programA | Stop the running rover program (its worker is terminated, the wheels stop). |
| get_programA | The current/last rover program: code, status (idle, running, listening, done, stopped, error), error { message, line } and the last 50 console lines. |
| stopA | Emergency stop: cancel any movement, turn autopilot off and pause the simulation. |
| set_simulationA | Start (running=true) or pause (running=false) the physics simulation. |
| set_autopilotA | Enable the built-in rule-based autopilot (seeks the light, backs away from obstacles; also starts the simulation) or disable it. |
| set_powerA | Set motor power in percent (10–100). Max speed is 170 px/s at 100 % (drive uses 65 % of it forward, 55 % backward). |
| set_emotionA | Show an expression on the robot's face display (emulated SSD1306 128×64 OLED); the message appears in the top text line and scrolls if long. Held ~5 s before sensor-driven emotions resume. |
| display_textA | Make the rover "say" a text on the Face Display module (128×64 OLED): a small rover face with a talking mouth and the text typed out in a speech bubble (Thai supported, ~11 characters per line, 2 lines per bubble, extra bubbles follow). Returns to the big face after |
| set_displayA | Fit a different Face Display module: "ssd1306" (0.96" 128×64 monochrome OLED, I²C; default), "ssd1331" (0.95" 96×64 colour RGB OLED, SPI) or "st7789" (1.3" 240×240 colour IPS TFT, SPI). Faces and text adapt to the resolution; colour modules show a colour per emotion. |
| draw_displayA | Show a picture on the Face Display module for |
| read_displayA | Read back what the Face Display module is showing: mode (face/text), text lines, module stats (frames, fps, bytes) and the actual 128×64 pixels from the module's GDDRAM as ASCII art (█▀▄, 2 pixel rows per line). |
| move_lightB | Move the light source to world coordinates (clamped to 42–758 × 42–478). |
| reset_worldA | Put the rover back at its start pose (120, 265, heading 0°) and the light at (690, 70). Turns autopilot off. |
| send_chatA | Send a message to the in-page Agent Chat (offline Thai/English command parser, e.g. "ไปหาแสง", "อ่านเซนเซอร์", "เดินหน้า 2 วินาที") and return the rover's reply. It shows up in the chat panel. |
| get_manifestB | The Robot Capability Manifest (ai-cartridge/body-v1): motors, installed sensor modules and display. |
| list_sensorsA | All configured sensors (enabled or not) with id, type, mounting position, angle and range. |
| add_sensorB | Install a new sensor on the rover body. Unspecified fields use the type defaults (centre of the body, facing forward). |
| update_sensorB | Change a sensor's name, type, mounting position, angle, range or enabled flag. Use list_sensors to find ids. |
| remove_sensorC | Uninstall a sensor by id. |
| set_moduleA | Install or remove a body module: "wheels" (drive motors + wheels; without them the rover cannot move), "head" (pan servo that turns the face and the light sensors), "display" (AI Face Display OLED) or "camera" (forward-facing camera). |
| set_headA | Control the Head module (pan servo, needs set_module head first). angle_deg turns the face to −90…90° relative to the body (+ = right, servo ≈180°/s) and switches to manual. track_light=true makes the head find and follow the light with its own light sensors: it sweeps the full range, settles on the brightest angle and keeps hill-climbing (rescans if the light is lost). Light sensors are directional (brightest when facing the lamp) and ride on the head. Starts the simulation. |
| press_buttonA | Press a push-button module (a sensor of type "button") for |
| get_button_eventsA | Button presses since the last call (oldest first, then cleared): { id, name, press: "short" | "long", seconds, at (ms epoch) }, plus every button and whether it is held right now. People press buttons in the simulator page; poll this to react to them. |
| get_headA | Head module status: angle_deg, target_deg, mode (manual / track_light), tracking phase and the head light brightness. |
| capture_cameraA | Take a picture with the rover's forward-facing camera (needs the camera module). Returns a 320×240 first-person PNG (walls, colored obstacles, colored floor tape, the light source) and a JSON list of what is in view: type (obstacle / tape / light), id, color, bearing_deg (0 = straight ahead, + = right) and distance_cm. |
| get_sensor_mapA | The map the rover has built from its own sensors only (not the true layout): an occupancy grid of 10 px cells as ASCII rows ("#" occupied by a sonar/IR echo or bumper hit, "." free, " " unknown, "@" rover, a capital letter = floor color read by a color sensor), camera landmarks with estimated world x/y, bumper hit points, the pose and exploration stats. clear=true wipes the map first. |
| get_wiringA | How the fitted rover body wires to a real microcontroller (the Wiring page): for each part (TB6612FNG motor driver, each enabled sensor, the display module, the camera) every pin and where it goes (MCU pin or 5V / 3V3 / GND / VBAT rail), the power budget per rail, issues found (pin conflicts, missing pins, 5 V signals into 3.3 V pins, duplicate I²C addresses, ESP32 strapping / ADC2 pins) and a ready-to-use pin file (Arduino pins.h, or pins.py with BCM numbers on the Pi). |
| get_bomA | Bill of materials for building the fitted rover body for real (the parts tab on the Wiring page): the board, motor driver, every enabled sensor, display, camera and head servo, plus the parts the circuit needs around them (chassis, battery, buck converter, voltage-divider resistors, level shifter …), each with quantity, approximate price in THB and shop links when known, and a plain-text list to copy. |
| get_firmwareA | A complete program for the real robot, generated from the fitted body and the wiring pin map: an Arduino sketch (rover_firmware.ino) for "esp32" / "uno", or a Python script (rover.py) for "raspberrypi". It drives the TB6612FNG wheels, reads every enabled sensor, turns the head servo (with light tracking), draws faces on the display and runs the same auto emotions / rule-based autopilot as the simulator. Text commands over Serial 115200 / stdin: READ, F|B|L|R , AUTO 0|1, POWER <%>, HEAD , TRACK 0|1, EMO [text], SAY , STOP. Returns { name, text }. |
| list_worldB | World size, light position, all obstacles (id, kind, shape, position, size, color) and colored floor tapes. |
| add_obstacleA | Place an object in the world to test sensors, collisions or the camera. Kinds: cylinder / ball (circle, radius r), box / wall (rectangle w × h, rotated by angle°). Unspecified size and color use the kind's defaults. Refused if it would overlap the rover. |
| remove_obstacleB | Remove an obstacle by id (see list_world). |
| add_color_tapeA | Stick a strip of colored tape on the floor (for the color sensor, line following and the camera). A color sensor over the tape reads its color name. |
| remove_color_tapeB | Remove a floor tape by id (see list_world). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 41 tools
Most tools have clearly distinct resource/action boundaries, and the descriptions disambiguate subtle pairs such as read_sensors vs get_observation and set_emotion vs display_text. Some overlap remains among the face/display tools and among stop, stop_program, and pausing the simulation, which could cause occasional misselection.
The surface is predominantly consistent snake_case with verb_noun names like list_sensors, add_obstacle, and get_wiring. Minor deviations such as the bare verbs drive, turn, stop, and state-style names like connection_status keep it from being perfect, but the pattern remains predictable.
With 41 tools, the server is far above the typical well-scoped range and creates significant selection overhead for an agent. The simulator is genuinely broad, so many tools earn their place, but the overall surface is too large for comfortable tool selection.
The set covers an unusually full lifecycle: simulation control, movement, sensor CRUD, obstacles, floor tape, display output, programs, camera, buttons, wiring, BOM, and firmware generation. No obvious operational dead ends are apparent for the stated robotics-simulator domain.