Loading ToolBench
MCP server exposing Yu-Gi-Oh! card RAG search as tools. Provides semantic card search and card lookup via the Model Context Protocol. Compatible with Pi, Claude Code, and any MCP-compatible host.
Two tools with complete input schemas and descriptions. search_cards has a detailed, LLM-optimized description (280 chars) explaining hybrid search, ATK constraint parsing, and parameter merging behavior, excellent for agent reasoning. get_card is simpler but adequate (95 chars). Both tools have properly typed parameters with descriptions. However, output schemas are not documented in the source code, LLMs cannot see what fields to expect from results. No error handling guidance, no recovery hints, and no tool annotations (readOnlyHint, idempotentHint). Parameter descriptions are good but could be more prescriptive about constraints (e.g., 'limit: 1-50, default 30' is stated but not in a machine-parseable enum). Both tools are READ_ONLY and idempotent, but this is not declared via annotations.
Retrieve a specific Yu-Gi-Oh! card by its ID. Returns full card details including name, type, ATK, DEF, level, attribute, effect text, and properties.
Hybrid search over Yu-Gi-Oh! cards: vector + lexical fusion + reranking. Combines pgvector cosine similarity, pg_trgm lexical name matching (via Reciprocal Rank Fusion), and cross-encoder reranking. Returns raw card data — the host AI (Pi, Claude Code) does its own reasoning on the results. IMPORTANT: ATK constraints written in the query text ARE now detected and enforced automatically — no need to extract them yourself. Examples: "more than 2500 ATK", "2500+", ">= 2500", "between 1000 and 2000", "exactly 2500 ATK" (PT-BR equivalents like "mais de 2500 de ataque" and "entre 1000 e 2000" work too). The explicit min_atk/max_atk parameters are still accepted and merge (tighten) with the parsed bounds: effective min = max of the two, effective max = min of the two. DEF, level, attribute and card_type are still NOT parsed from the query text — pass them explicitly (e.g. card_type="Dragon", level=8).
Output schemas not documented. LLMs cannot see what fields search_cards and get_card return, forcing them to guess at response structure and breaking downstream tool chaining.
No tool annotations (readOnlyHint, idempotentHint). Both tools are READ_ONLY and safe to retry, but this is not declared. Agents cannot optimize caching or retry logic.
No error handling guidance. If search_cards returns no results or get_card receives an invalid card_id, the response does not guide the agent on recovery (e.g., 'Try a broader query' or 'Card not found, use search_cards to find valid IDs').
Parameter 'limit' lacks enum constraint. Description says '1-50, default 30' but no JSON Schema enum or minimum/maximum. LLMs may pass invalid values like 0 or 1000.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
search_cards parameter descriptions do not explain when to use min_atk/max_atk vs. parsing from query text. The description mentions 'explicit min_atk/max_atk parameters are still accepted and merge (tighten) with the parsed bounds' but parameter descriptions do not clarify this interaction.