Loading ToolBench

Reading the current corpus…

tarot_mcp_server MCP server · D · ToolBench

← Browse

tarot_mcp_server

github.com/hwfish/tarot_mcp_server

A Model Context Protocol server that shuffles and draws tarot cards with preset spreads and card meanings

2026-07-28+STREAMABLE_HTTP3 tools

51/100

Definition Quality56

Protocol Readiness75

Supportability25

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (draw_*, list_*), which is good. However, descriptions are minimal (10-40 chars), parameter descriptions lack detail on constraints and formats, and output schemas are not documented. No error handling guidance. The server is functional but falls short of production-grade quality.

Tools (3)

draw_cardsread onlysource verified53/100

draw N random cards as JSON

draw_spreadread onlysource verified53/100

draw a preset spread with named positions

list_spreadsread onlysource verified63/100

list available preset spreads

Issues (5)

HIGHtool-description ↗

Tool descriptions are too short (10-40 chars). Rubric baseline is 194 chars average; descriptions under 20 chars score 0-20. Current descriptions ('draw N random cards as JSON', 'draw a preset spread with named positions', 'list available preset spreads') lack context on WHEN to use each tool, what the output structure is, and any prerequisites.

draw_cardsdraw_spreadlist_spreads

HIGHresponse-shaper ↗

Output schemas are not documented. LLMs cannot plan downstream calls or extract data without knowing the response structure. The code mentions 'draw N random cards as JSON' and 'a short keyword interpretation that ALREADY matches the card's orientation', but the actual JSON schema (fields, types, nesting) is not visible in the tool definitions.

draw_cardsdraw_spreadlist_spreads

HIGHconstrained-input ↗

Parameter descriptions lack constraint details. 'count' parameter has no min/max bounds (rubric baseline: specify 1 - 100 range). 'spread' parameter has no enum of valid spread names, LLMs will hallucinate invalid spread names. 'allow_reversed' is boolean but lacks explanation of what 'reversed' means in tarot context.

Recommendations

Expand tool descriptions to 100-200 chars. Example for draw_cards: 'Draw N random cards from a standard 78-card tarot deck. Each card includes its name, orientation (upright/reversed), and a meaning keyword. Use this to generate readings for divination or creative inspiration. Supports 1-78 cards.'
Document output schema for each tool. Example: 'Returns {"cards": [{"name": string, "orientation": "upright"|"reversed", "meaning": string}], "total": integer}'. Include this in the tool description or as a separate schema field.
Add enum constraint to 'spread' parameter. List all valid spread names (e.g. 'three_card', 'celtic_cross', 'horseshoe') in the parameter schema. This prevents hallucinated spread names.
Add min/max bounds to 'count' parameter: min=1, max=78. Update description: 'Number of cards to draw (1-78). Defaults to 1 if omitted.'
Add tool annotations to schema: set readOnlyHint=true and idempotentHint=true for all three tools. This signals to MCP clients that these are safe, repeatable operations.

Score history

Overall score trend

First recorded score · v2 rubric

51/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	51	2026-07-28+	v2