Loading ToolBench
A minimal MCP proxy that merges multiple backend servers behind one endpoint.
Four tools with minimal descriptions (10-30 chars each) and basic schemas. All tools lack parameter descriptions beyond type declarations. No error handling guidance, no output schema documentation, no tool annotations. Naming is acceptable (ping, server_name, add, multiply) but descriptions are too terse to guide LLM selection. Tools appear to be test/demo fixtures rather than production-grade definitions. No evidence of idempotency, composition, or chaining support.
Add two numbers
Multiply two numbers
Echo a message back with server name prefix
Return the server name
All tool descriptions are under 20 characters, violating minimum context requirement. 'Echo a message back with server name prefix' (47 chars) is the longest; others are 10-30 chars. LLMs cannot reliably select tools without 50-200 char descriptions explaining WHAT, WHEN, and WHY.
Parameter descriptions are missing entirely. 'message' param in ping has only type 'string' and description 'Message to echo' (14 chars). 'a' and 'b' in add/multiply have no descriptions at all. LLMs cannot infer parameter semantics from names alone.
No output schemas documented. Tools return strings or integers but LLMs have no formal specification of return types, structure, or fields. Prevents downstream tool chaining and forces LLMs to guess output format.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | <=2025-11-25 | v2 |
No error handling or recovery guidance. Tools provide no documentation of failure modes, error codes, or what the LLM should do if a call fails. No actionable error messages in implementation.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are marked READ_ONLY in metadata but this is not reflected in schema annotations. LLMs cannot determine idempotency or retry safety from definitions alone.