Loading ToolBench
MCP server for controlling Pico2 GPIO pins via HTTP API
Critical gaps across all dimensions. Parameter descriptions are entirely missing (null values in schema). No output schema documentation. No error handling guidance. Tools lack context about what happens on failure, retry behavior, or prerequisites. The server proxies to a hardcoded localhost:8899 endpoint with no validation, error recovery, or user-facing guidance.
Init Pico2 GPIO output pin
Set Pico2 GPIO output pin
Parameter descriptions are null/missing. Both tools have 'pin' and 'value'/'state' parameters with no descriptions explaining what values are valid, what range is acceptable, or what happens if invalid input is provided.
Tool descriptions are too short (18-24 chars). 'Init Pico2 GPIO output pin' and 'Set Pico2 GPIO output pin' lack context about when to use each tool, what prerequisites exist, what the tool returns, or how it differs from the other. Descriptions must be 10-1024 chars with actionable context.
No output schema documented. Tools return plain text wrapped in content[].text. LLMs cannot infer what fields to expect or how to chain results to downstream tools. No documentation of success/failure structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 30 | 2026-07-28+ | v2 |
No error handling or recovery guidance. If the localhost:8899 endpoint is unreachable, times out, or returns an error, the tool returns raw text with no actionable guidance for the LLM. No distinction between retryable and fatal errors.
Parameter constraints not documented. 'pin' is a number with no min/max bounds, range, or valid values. LLMs may pass negative, fractional, or absurdly large pin numbers. 'value'/'state' are booleans but lack context about what true/false mean in GPIO context.