Loading ToolBench
An MCP server that exposes the dice library as tools for rolling tabletop RPG dice expressions and explaining them in plain English
Two tools with clear, detailed descriptions and basic input schemas. Tool names are action verbs (roll, explain) and descriptions are comprehensive (rollDescription ~400 chars, explainDescription ~120 chars). Input schemas present with type and description for the single 'expression' parameter in each tool. However, schemas lack formal JSON Schema structure (no explicit 'type', 'required', 'properties' blocks visible in registration). Output schemas documented in test code (RollOutput, ExplainOutput) but not formally declared in tool registration. Error handling returns IsError flag and text messages, but lacks recovery guidance or error categorization. No parameter constraints (enums, ranges, patterns) despite dice notation having strict syntax rules.
Translate a dice expression into a plain-English description. Useful to confirm interpretation before rolling, or to render help text. Does not roll.
Roll a tabletop RPG dice expression. Notation: XdY roll X dice with Y sides (e.g. 2d6, 1d20) +/- integer modifiers (e.g. 1d20+5) khN, klN keep highest/lowest N (e.g. 4d6kh3 — D&D 5e ability scores) dhN, dlN drop highest/lowest N x[N], xo[N] explode on max (or >=N); xo = once only r[N], rr[N] reroll on =N (or comparison); rr = recursive cs[>=N], cf[<=N] count successes/failures (World of Darkness style) adv(expr) roll twice, take higher (D&D 5e advantage) dis(expr) roll twice, take lower >= N, <= N, etc. trailing target number; sets hit/miss without changing total Examples: "2d6+3" basic damage "4d6kh3" ability score "adv(1d20)+5 >= 15" attack roll with advantage against AC 15 "5d10cs>=8" World of Darkness pool, count 8s and up
Input schemas lack formal JSON Schema structure. Tool registration uses mcp.Tool with Name and Description, but no explicit InputSchema with 'type', 'required', 'properties' visible. RollInput and ExplainInput structs exist in code but are not formally bound to tool definitions via schema registration.
Output schemas not formally declared in tool registration. RollOutput and ExplainOutput are returned as structured data in tests and handlers, but the tool definitions do not document what fields clients should expect. LLMs cannot plan downstream operations without knowing output structure.
Error messages lack recovery guidance. When expression parsing fails, the tool returns 'Error: <error>' but does not suggest next steps (e.g., 'Invalid syntax. Try: 2d6+3, 4d6kh3, adv(1d20)+5'). Errors are not categorized as retryable vs. user-fixable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
No input validation constraints. The 'expression' parameter accepts any string; no regex pattern, length limit, or character restrictions are declared. Dice notation has strict syntax rules (XdY, khN, etc.) that should be documented as constraints to guide LLM input.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only and idempotent, but these properties are not declared in the tool definitions. Clients cannot infer safety properties without explicit annotations.