Loading ToolBench
A simple MCP server that rolls dice with a specified number of sides
Single tool 'getDiceRoll' has a clear verb-noun name and basic schema with type and minimum constraint. However, the description is only 82 characters (below the 194-char baseline for A+ tools) and lacks context on when/why to use it. No output schema is documented, LLMs cannot predict the response structure. No error handling guidance. Parameter description is minimal. Tool is READ_ONLY but lacks explicit annotation. Overall: functional but sparse, typical of template-quality servers.
Roll a dice with a specified number of sides and return the result.
Output schema not documented. LLMs cannot infer response structure (is it {roll: number}? {content: [...]}? {result: string}?). Agents cannot plan downstream operations or extract fields reliably.
Tool description is 82 characters, below the 194-char baseline. Lacks WHEN to use it, WHAT it returns, and any prerequisites. LLMs cannot distinguish this from other random-number tools or understand its purpose in a multi-tool context.
Parameter 'sides' description is minimal ('Number of sides on the die'). Does not specify valid range beyond minimum=1. What is the maximum? Can sides be 0.5? Unbounded numeric parameters invite invalid LLM inputs.
No error handling guidance. What if sides is negative after validation? What if Math.random() fails? LLMs receive no recovery hints, they cannot self-correct or retry intelligently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Tool is READ_ONLY but lacks explicit readOnlyHint annotation in schema. Clients cannot programmatically determine safety without parsing the description.