Loading ToolBench
A robot, or a flock of them, as MCP tools over stdio. Exposes robot control verbs, observation, memory, and task management through the Model Context Protocol.
quackd exposes 9 tools with basic schemas and descriptions, but falls short of production quality. All tools have descriptions (10-80 chars, mostly under the 194-char baseline), and input schemas are present with type definitions. However, descriptions are terse and lack actionable context for LLM selection. Parameter descriptions are minimal or absent (e.g., robot param repeated across tools with identical 'Robot name' text). No output schemas documented. Error handling is absent, no guidance on retryability, recovery steps, or invalid input correction. Tool naming follows verb_noun convention (robot_list, robot_run_verb) but 'robot_assess_task' conflates assessment with verdict submission in a single call. No pagination, no batch operations, no idempotent hints. STDIO transport caps protocol readiness at 50, further limiting production viability.
Assess whether a robot can perform a task based on its datasheet and capabilities
List all robots available in the fleet
List all verbs (actions) available for a robot
Load a .duck task file to adopt a task contract
Capture camera frames from a robot
Retrieve what a robot learned in earlier sessions (memory)
Store a short fact in a robot's memory for the next session
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and breaking tool chaining.
Descriptions are terse (10 - 80 chars, well below 194-char baseline) and lack context for LLM selection. E.g., 'List all robots available in the fleet' does not explain when to call this vs. other discovery tools or what structure is returned.
Parameter descriptions are generic or missing. The 'robot' parameter appears in 8 tools with identical 'Robot name (optional for single robot, required for fleet)' text. No guidance on format, valid values, or how to discover robot names.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
Execute a verb (action) on a robot
Send a text message to a robot's speaker
robot_assess_task conflates two concerns: assessing feasibility AND submitting a verdict. The 'verdict' parameter (enum: feasible/infeasible/uncertain) suggests the LLM must provide the assessment, not the tool. This violates single-responsibility and forces the LLM to reason about robot capabilities.
No error handling guidance. Tools lack descriptions of failure modes, retryability, or recovery steps. An LLM cannot distinguish between transient failures (retry) and permanent ones (ask user).