Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ROVER_BRIDGE_PORTNoThe WebSocket bridge port. If you change it, the page needs ?mcpPort=<port> (open_simulator adds this for you).8765
ROVER_SIMULATOR_URLNoThe 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_ORIGINSNoExtra 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 rover library (same as the Code page; it replaces any running program and starts the simulation). Top-level await works. Motion (await): rover.forward(s), backward(s), turn(deg), left(s), right(s); rover.drive(speed −1…1, turn °/s) keeps going; rover.stop(); rover.power(%). Readings (sync, 50 ms snapshots): rover.read(id), sensors(), distance() (nearest sonar/IR cm), light() (%), bumped(), pose(), time(). Head/face: await rover.head(deg), trackLight(on), headAngle(); rover.face(emotion, text), say(text, s). Buttons: pressed(id), onButton([id], fn(event)), await waitButton([id]). Time/output: await wait(s), await rover.until(fn, timeout), log(...). Customise: await rover.module(name, on), addSensor({type,name,x,y,angle,range}), updateSensor(id, fields), removeSensor(id), sensorList(). Returns immediately; poll get_program for status and the console.

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 seconds, or once every bubble has been shown if that takes longer.

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. panel changes the SSD1306 glass colour. Returns read_display.

draw_displayA

Show a picture on the Face Display module for seconds, then return to the face. Pass one string per pixel row, at most the module's resolution (SSD1306 128×64, SSD1331 96×64, ST7789 240×240; see read_display). Characters space . 0 - _ are dark. On colour modules (SSD1331, ST7789) these letters pick a colour: R red, O orange, Y yellow, G green, C cyan, B blue, P purple, M pink, W white, A grey, N brown, K black; any other character is white, and palette adds or overrides letters. On the monochrome SSD1306 every non-blank, non-black character is a lit pixel and colour comes from its panel variant (panel). The picture is centred; scale enlarges each pixel (e.g. 64×32 with scale 2 fills 128×64) and is lowered if it would not fit. Returns read_display, so the result shows what the module actually displays.

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 seconds and release it, like a person would. Held ≥ 0.8 s is a long press. The built-in program reacts: short press toggles the head's light tracking (happy face), long press stops everything (driving, autopilot, tracking; pauses the simulation). Returns the press event.

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). board switches the board first: "esp32" (ESP32 DevKit V1), "uno" (Arduino Uno R3) or "raspberrypi" (Raspberry Pi 4/5 40-pin header; analog sensors go through an ADS1115 on I²C, the camera on the CSI ribbon).

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. board switches the board first: "esp32", "uno" or "raspberrypi".

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 }. board switches the board first.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 41 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues