Loading ToolBench
FastMCP 3.1.0 MCP for Noetix Bumi humanoid — hero specs, OSS links, fleet virtual-twin guidance, optional robot bridge
Critical deficiencies across all dimensions. The bumi-mcp server exposes three tools via a static manifest in tools_manifest.py, but the implementation has severe quality gaps: (1) Parameter descriptions are completely absent, the manifest only declares parameter names and types (e.g., 'operation': 'str'), with no descriptions explaining what values are valid or when to use them. (2) Schema definitions are minimal, only type names, no JSON Schema structures with constraints, enums, or format specifications. (3) Tool descriptions are vague and unhelpful for agent selection: 'bumi' says 'info, specs, sdk_links, market, robot_status, virtual_twin, fleet_peers' but never explains what operation= accepts or when to call it instead of a similar tool. (4) No output schemas are documented, agents cannot plan multi-step workflows without knowing what fields are returned. (5) One tool ('bumi_agentic_workflow') references 'SEP-1577 sampling' in its description, which is a deprecated MCP pattern; this suggests the implementation may be out of sync with current MCP spec. Tool definitions are inferred from a static dict, not from explicit MCP tool registration visible in the source, which caps individual tool scores at 50. Overall, this server reads like an early prototype with placeholder tooling.
Noetix Bumi — info, specs, sdk_links, market, robot_status, virtual_twin, fleet_peers.
LLM-planned goals over Bumi + fleet (SEP-1577 sampling).
Operator brief: Bumi specs, OSS repos, and virtual twin via fleet MCPs.
Parameter descriptions completely missing. The tools_manifest.py declares parameter types (e.g., 'operation': 'str') but provides zero guidance on valid values, constraints, or what each value does. For 'bumi' tool, 'operation' parameter has no description explaining that valid values are 'info, specs, sdk_links, market, robot_status, virtual_twin, fleet_peers'. Agents cannot select correct values without guessing.
No input JSON Schema structures provided. The manifest only lists bare type names ('str', 'str', 'physical|virtual|fleet') without formal JSON Schema definitions (type, enum, description, required fields). This prevents agents from understanding constraints and LLM-side validation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Tool descriptions are vague and lack selection guidance. 'bumi' description lists operations but does not explain when to call it (e.g., 'Call to retrieve robot specifications and market info' would be clearer). 'bumi_agentic_workflow' says 'LLM-planned goals over Bumi + fleet (SEP-1577 sampling)' which references a deprecated MCP sampling pattern and does not explain what the tool returns or what 'goal' parameter expects.
No output schemas documented. Agents have no way to know what fields the tools return, preventing downstream composition. For example, if 'bumi robot_status' returns a status dict, what fields are in it? Can agents chain the result to other tools?
Tool naming ambiguity. 'bumi' is a noun, not a verb, it does not convey action (get_, list_, search_, etc.). The actual operations (info, specs, status, etc.) are buried in a free-form 'operation' parameter rather than being separate tools. This forces agents to guess which operation to pass. Better design: separate tools like 'get_bumi_specs', 'get_robot_status', 'list_fleet_peers'.
'bumi_quick_start' marked as 'kind: prompt' in manifest but no actual MCP prompt definition is visible in the source. This suggests the tool is partially implemented or the manifest is inaccurate.