Loading ToolBench
Palmimo SDK and DevKit software utilities for hexapod robot control, including MCP server for agent toolset exposure
Palmimo DevKit provides 12 tools with generally clear, domain-specific descriptions that explain robot motion and perception actions. Tool names follow verb_noun convention (look, dance, nod, capture, discover). However, schemas are incomplete: most tools lack explicit input parameter type definitions in the visible source (only pitch/yaw/seconds/name are shown with types; many parameters lack descriptions). Output schemas are not documented. Error handling and recovery guidance are absent. The descriptions are strong (100-200 chars, well-written for LLM reasoning), but parameter validation rules and constraints are underspecified. Composite tools (discover, investigate, eye_contact, rest) lack input schemas entirely.
Capture an image from the robot's head camera, optionally looking in a specified direction first. Extends the SDK's CaptureTool with a direction argument (look that way first, then capture, then recenter).
Sway the body rhythmically while showing the GROOVE dance face. No face argument (unlike every other motion tool): GROOVE is shown unconditionally for the whole dance, so any requested face would just be overwritten. say IS supported -- the inner SDK motion tool's say parameter is passed through.
Composite recipe tool: look around in multiple directions and capture images to discover what's in the environment.
Composite recipe tool: establish eye contact with a detected face by tracking it with the neck.
Shake the head while showing the BATSU (X/negation) glyph.
Composite recipe tool: look at a specific location and capture images to investigate it more closely.
Composite recipe tools (discover, eye_contact, rest) have empty input schemas ({}). Per HARD SCORING RULES, schema score must be 0 for tools with no input schema. These tools lack documented parameters, return types, and composition details.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., image data from capture, face coordinates from eye_contact).
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or actionable error messages. E.g., what happens if the robot cannot reach a gaze angle? If face detection fails in eye_contact?
Parameter descriptions lack validation rules and constraints. E.g., pitch/yaw angles have no documented range (degrees, -180 to +180?). seconds parameters lack min/max bounds. show_emoji's enum is comprehensive, but other tools lack similar constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
SDK look + an optional gaze-hold duration. Every other motion tool takes seconds, and the model reliably generalizes that onto look too -- real-robot runs showed repeated seconds validation rejections on an SDK LookTool that doesn't have the field. Accepting it (as 'hold the gaze there this long') turns that hallucination into a useful knob instead of an error round-trip.
Hand-rolled proportional neck-tracking loop that tracks a detected face. The SDK has no tracking mode of its own to delegate to.
SDK look_center + the same optional hold as Look.
Nod the head while showing the MARU (circle/approval) glyph.
Composite recipe tool: put the robot into a resting state.
SDK show_emoji with the display's closed vocabulary enforced in-schema. The SDK deliberately leaves name an open string (firmware may know more names than its docstring lists); this robot's firmware vocabulary is known exactly, and real runs showed the model inventing plausible names (WATER_WAVE for WAVE) that only fail at the display. The Literal turns those into schema-level choices the model picks correctly.
Composite tools (discover, investigate, eye_contact, rest) do not document what sub-steps they execute or what data they return. LLMs cannot reason about composition or plan alternatives if a sub-step fails.