The Platform ships an MCP server, so an AI assistant — Claude Desktop, Claude Code, or anything else that speaks the Model Context Protocol — can look through your robot's camera, find things in view, and drive it. It is a single Python file with no dependencies, and it talks to the same REST API you would use yourself.
The server lives in the Platform repo at mcp/burf_mcp.py. It needs Python 3 and nothing else — no pip install.
export BURF_API_KEY=<your API key> python3 mcp/burf_mcp.py
Then point your assistant at it. For Claude Desktop or Claude Code, add this to your MCP config:
{
"mcpServers": {
"burf-platform": {
"command": "python3",
"args": ["/path/to/BurfPlatform/mcp/burf_mcp.py"],
"env": { "BURF_API_KEY": "<your API key>" }
}
}
}
Get your API key from your profile page. It is the same key the REST API uses.
You start the sim, not the assistant — open Try a Robot and start one. It then registers like any real robot, and every tool below works on it identically. There is deliberately no tool for creating or deleting sims, so an assistant cannot spin up compute on your account.
Tools are matched to each robot's real capabilities, so only what your robot actually supports is offered.
| Tool | What it does |
|---|---|
| list_robots | Every robot online, with its type and capabilities. Start here. |
| robot_status | Battery, pose and live sensor readings. |
| camera_snapshot | A still frame from the robot's camera. |
| find_object | Look for things in view by plain description — "the yellow box", "a doorway". Open-vocabulary, so it is not limited to a fixed list, and it reports which third of the frame each hit is in. |
| list_maps list_locations | Saved SLAM maps and the named waypoints on them. |
| get_map | The map itself, as a picture — the occupancy grid the robot has built, so you can see coverage and find open floor. |
| speak | Say something out loud on the robot. |
| stop | Stop the robot. Always available. |
| drive | Short, bounded moves. Needs motion enabled. |
| goto_location | Send the robot autonomously to a named waypoint. Needs motion enabled. |
| explore | The robot drives itself and builds a map. Needs motion enabled. |
| dock | Return to the charging dock, or undock. Needs motion enabled. |
| save_map add_location set_active_map | Map a new building, then name spots on it so goto_location can be sent there. Needs motion enabled — these change what the robot will do next. |
So "go to the kitchen, take a photo, then come back and dock" is four tool calls, and "is there a yellow box in here?" is one.
Why it works that way, and what stays true even with motion enabled:
Your API key controls real hardware. An assistant that misreads a room should not be able to drive a robot into it, so you opt in deliberately rather than by default.
Every move is time-boxed — a few seconds at most, with speed clamped. The robot also stops by itself about a second after commands stop arriving, so nothing keeps rolling if the assistant stops talking.
stop is never gated. You should never discover a missing setting while a robot is moving.
A car is not asked to spin. On Ackermann (car-steering) robots, asking to turn on the spot returns an explanation instead of a command, because a car has to be moving to turn.
REST API - the same endpoints the MCP server wraps, if you would rather call them directly
Supported robots - what each robot family can do
Try a Robot - start a simulated robot with no hardware