Loading ToolBench
Stack-chan cloud MCP server with patches for WebSocket keepalive, avatar size validation, opuslib binding, and systemd environment configuration. Includes OAuth 2.1 gateway, fake OTA server, and reflex daemon for device behaviors.
This server has 10 tools with basic schemas and descriptions, but significant quality gaps. All tools have descriptions (10-50 chars, mostly under the 50-200 char ideal), and input schemas are present with type definitions. However, descriptions are generic and lack actionable context for LLM selection. No parameter descriptions explain constraints, ranges, or when to use each tool. No output schemas documented. Error handling is absent, no recovery guidance, no categorization of failures. Tools lack composition guidance (e.g., which tool to call first, what IDs are returned for chaining). No tool annotations (readOnlyHint, destructiveHint). The server is STDIO-only, which is a hard cap at 50 for protocol readiness, but definition quality itself is weak due to missing parameter docs and output schemas.
Turn off all LEDs on the device
Get the current touch state of the device, including last event age and type
Re-upload the avatar archive and bring the face animation back online
Enable or disable automatic servo torque release after movement
Set the current avatar face to display on the device
Enable or disable blinking animation on the device
No parameter descriptions. All 10 tools have input parameters (archive_path, enabled, face, volume, brightness, yaw, pitch, speed, r, g, b, timeout_ms) with NO descriptions explaining what values are valid, what ranges are acceptable, or what the parameter controls. LLMs cannot infer constraints from names alone.
No output schemas documented. Tools return responses but no schema is visible for what fields are returned, what types they are, or what the LLM should expect. This prevents downstream tool chaining and forces LLMs to guess at response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Set the device screen brightness level
Set LED color on the device
Set servo position and speed for head movement
Set the device volume level
Tool descriptions are too short (10-50 chars) and lack actionable context. E.g., 'Set the device volume level' does not explain when to use this vs other tools, what happens on the device, or what the valid range is. Descriptions should be 50-200 chars and answer WHAT, WHEN, and WHY.
No error handling or recovery guidance. Tools have no documented error cases, no categorization of failures (retryable vs fatal), and no guidance for LLMs on what to do if a call fails. A timeout or device offline error gives the agent nothing to act on.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). 9 of 10 tools are WRITE operations that modify device state, but none are marked as destructive or non-idempotent. LLMs cannot distinguish safe reads from risky writes without explicit hints.