bumi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| YAHBOOM_IP | Yes | The Tailscale IP address of the Bumi robot |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bumi_toolA | BUMI — Noetix Bumi humanoid: hero product info, OSS links, fleet virtual-twin map. PORTMANTEAU RATIONALE: Single entry for discovery and setup; hardware control arrives when a documented local API or ROS bridge is wired (set BUMI_ROBOT_URL for optional ping). Operations: info — tagline + vendor + key specs (default) specs — full structured hero dict sdk_links — GitHub repos + opensource landing page robot_status — if BUMI_ROBOT_URL set, GET {url}/health or /api/health; else connected=false virtual_twin — how to drive virtual Bumi via resonite-mcp / robotics-mcp / worldlabs-mcp fleet_peers — yahboom-mcp / dreame-mcp / robotics-mcp narrative for RoboFang fleet market — Noetix story, China humbot wave, JD.com + tier-1 offline context (not legal advice) Returns: success, message, and operation-specific data. |
| bumi_agentic_workflowB | BUMI_AGENTIC_WORKFLOW — High-level goals: specs, SDK setup, virtual twin, fleet composition. Uses ctx.sample() so the host LLM can call bumi_tool and sibling MCPs (resonite, robotics). Args: goal: Natural language, e.g. "Summarize Bumi specs and how to show a virtual twin in Resonite" Returns: LLM summary string. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| bumi_quick_start | Operator brief: Bumi specs, OSS repos, and virtual twin via fleet MCPs. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| bumi-operator/SKILL.md | Operate bumi-mcp for Noetix Bumi specs, OSS links, optional robot bridge, and virtual twin composition via fleet MCPs. |
| bumi-operator/_manifest | File listing for bumi-operator |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: 'bumi_agentic_workflow' handles high-level orchestration by delegating to other tools, while 'bumi_tool' provides direct operations on the Bumi robot. There is no ambiguity or overlap.
Both tool names share the 'bumi_' prefix, but one uses a descriptive 'agentic_workflow' while the other uses the generic 'tool', lacking a consistent pattern. The naming is passable but not uniform.
With only 2 tools, the surface is thin but arguably appropriate for an early-stage MCP server that bundles many operations into a single 'bumi_tool' and provides an orchestration layer. It does not feel excessive, but more tools might be expected for a robot server.
The tool set covers information retrieval (specs, SDK, status) and conceptual guidance (virtual twin, fleet), but lacks actual robot control or modification operations. The server's stated scope is discovery and setup, which is partially met, but interactive features are missing.