embodied-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_API_KEY | Yes | Required API key. Example: export ANTHROPIC_API_KEY=... | |
| EMBODIED_MCP_MODEL | No | Host and pixel-grounding / counting model. Default: claude-opus-5 | claude-opus-5 |
| XIAO_HEI_IMAGE_TOPIC | No | Camera topic. Default: /camera/image | /camera/image |
| EMBODIED_MCP_BUDGET_S | No | Seconds from process start. Default: 540 | 540 |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_viewA | Capture the robot's current 360° camera, split into four perspective faces (front, right, back, left), and return them with the current pose. Call this when you need to see the room. Do not guess what is around you. |
| groundA | Ground a referring expression in the live camera + lidar. Pass the object or place to go to, in the instruction's own words (e.g. 'the lantern closest to the fan decoration'). The tool asks a pixel-grounding model for a box, lifts metres from the registered scan, size-checks the range, and snaps the waypoint to where the platform converter will actually settle. Use publish_xy as the argument to drive_to. If committed is false, this is a step to a better viewpoint — drive there and ground again. If visible is false, drive to suggested_xy and look again. |
| drive_toA | Publish one waypoint (map-frame x, y) and wait until the vehicle arrives or settles. Arrival is decided from /state_estimation, not from a 'waypoint reached' topic. Prefer publish_xy from ground() over coordinates you invent. |
| stopA | Park at the current pose so the local planner stops chasing the last waypoint. Call this when the instruction is finished, or after you have published a numerical or object-reference answer. |
| parse_numericalA | Split a counting question into target, attribute, relation, and anchor. Use this first on numerical questions so you know what to ground and what to pass to count_in_view. |
| count_in_viewA | Count matching instances from the current vantage point only. The call is never told the running total — do not add previous looks yourself. Each instance is boxed and lifted with lidar so later looks can be de-duplicated. If sufficient is false, drive as next_view suggests (or ground the anchor) and count_in_view again. When you are done looking, call commit_count — that publishes the clustered integer. |
| commit_countA | Cluster every count_in_view look by lidar position and publish one integer on /numerical_response. Two views of the same four pillows become 4, not 8. You do not pass the number — geometry does. |
| publish_objectA | Publish a 3D cube marker on /selected_object_marker for the object you last grounded. Call ground() on the unique referred object first. The box centre and size come from the lidar cluster, not from a guess. |
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 8 tools
Each tool serves a distinct function: perception (get_view), grounding (ground), navigation (drive_to, stop), numerical parsing (parse_numerical), counting (count_in_view), finalizing counts (commit_count), and object publication (publish_object). There is no overlap or ambiguous boundaries between them.
All tool names follow a consistent verb_phrase pattern with snake_case (e.g., get_view, drive_to, commit_count). The verbs are imperative and descriptive, making the intent of each tool predictable from its name alone.
With 8 tools, the server is well-scoped for embodied navigation and counting tasks. Each tool covers a necessary step in the workflow without redundancy or excessive granularity, fitting within the ideal 3-15 tool range.
The tool surface fully covers the lifecycle of the domain: perceiving the environment, grounding references, moving, stopping, parsing questions, counting from multiple views, committing aggregated results, and publishing object markers. There are no obvious gaps or dead ends for the intended tasks.