Loading ToolBench
MCP server — let any LLM agent identify an appliance and pull its grounded, safety-checked, robot-executable operation package from OPERANDI.
Four tools with clear, domain-specific purposes and well-structured schemas. Naming follows verb_noun convention (identify_, get_, list_, find_). Descriptions are substantive (100-250 chars) and explain WHEN to use each tool. Input schemas are complete with types and descriptions. However, output schemas are entirely undocumented, LLMs cannot plan downstream calls or extract structured data. Error handling is absent from descriptions. No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions lack format constraints and validation rules. Missing guidance on dependencies (e.g., 'Call identify_appliance first, then get_operation_package').
Find appliances by what they DO (e.g. 'heat', 'wash', 'brew', 'defrost') — useful when an agent has a goal but not a specific model in mind.
Get the robot-executable operation package for an appliance: model-exact ordered procedures, a control map with grounding (where each control is + how it is actuated), per-step verification signals, a recovery state machine, and a safety envelope (hazards / interlocks / never-do). This is the grounded knowledge a general model hallucinates without. Optionally target one procedure (e.g. 'defrost').
Resolve which appliance an agent/robot is looking at, from observed text or panel labels, to an OPERANDI catalog object. Call this first, then get_operation_package with the returned slug. Returns ranked matches with confidence.
Browse the appliances OPERANDI can operate, optionally filtered by category.
Output schemas completely undocumented. LLMs cannot infer what fields identify_appliance returns (e.g., does it return 'slug', 'model_id', 'confidence'?). Downstream tool calls (get_operation_package) require specific field names, missing output docs force agents to guess or fail.
No tool annotations. All four tools are read-only (no side effects), but readOnlyHint is missing. LLMs cannot distinguish safe tools from destructive ones, risking incorrect retry logic or safety assumptions.
Parameter descriptions lack format constraints. 'limit' accepts 1-20 but description says 'Max matches (1-20, default 5)', constraint is in prose, not machine-parseable. 'capability' has no enum of valid values (heat, wash, brew, defrost). LLMs cannot validate inputs before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
No error handling guidance in tool descriptions. What happens if identify_appliance finds no matches? If get_operation_package receives an invalid ref? Descriptions do not tell LLMs what to do on failure, forcing blind retries.
Missing tool-chaining guidance. identify_appliance and get_operation_package are tightly coupled (call first, then second), but descriptions do not state this dependency. LLMs may call get_operation_package without identifying first, causing failures.