Loading ToolBench
Minimal MCP server built with H3 v2 (beta) as a dedicated app or nested-app.
This server has 3 tools with minimal definitions. While schemas are present and valid, descriptions are extremely brief (10-14 chars each), parameter descriptions are entirely absent, and output schemas are undocumented. The naming convention is weak: 'test' and 'stream' do not follow verb_noun patterns and lack clarity about intent. No error handling guidance is provided. The server appears to be a reference implementation or playground rather than a production-ready MCP server.
Adds two numbers together
Streams the current time every second
An example tool that echoes back the input
Tool descriptions are far too brief (<20 chars). 'An example tool that echoes back the input' (41 chars) is minimal; 'Adds two numbers together' (25 chars) and 'Streams the current time every second' (36 chars) lack context for LLM selection. No description explains WHEN or WHY to use these tools.
No parameter descriptions provided. The input schemas define properties (e.g., 'input', 'a', 'b', 'maxSeconds') but none have description fields. LLMs cannot infer meaning from bare property names, a 'maxSeconds' parameter is ambiguous without context (max duration? max iterations?).
Output schemas are entirely undocumented. Tools return data, but the response structure is not declared anywhere. LLMs cannot plan downstream calls or extract results correctly without documented output schemas. This violates pattern:tool and pattern:response-shaper.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | 2025-06-18+ | v1 |
Weak tool naming: 'test' and 'stream' do not follow verb_noun conventions. 'test' is generic and ambiguous, is it testing the server, testing input, or testing something else? 'stream' lacks the resource being streamed. Recommended: 'echo_input' and 'stream_time' or similar action-specific names.
No error handling or recovery guidance. If a tool call fails, there is no indication of what went wrong or what the LLM should do next. Error responses should guide the agent: 'Invalid input type' vs 'Expected string for input parameter; got number.'
No pagination or result limits documented. The 'stream' tool may produce unbounded output over time; the description does not specify how many results are returned or if there are limits. This risks context window exhaustion.
Missing parameter constraints. 'maxSeconds' in stream tool has no type constraint (number, but min/max bounds?). 'a' and 'b' are number types but have no bounds. Unbounded numbers invite LLM errors (passing negative values, absurdly large values, etc.).