Loading ToolBench

Reading the current corpus…

ptcg-mcp MCP server · D · ToolBench

ptcg-mcp

A Pokémon Trading Card Game (PTCG) search and information server that provides tools to search for cards, retrieve detailed card information, and look up pricing data

2026-07-28+STDIO1 tools

59/100

Definition Quality85

Protocol Readiness40

Supportability28

Spec posture

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

Static source inference · medium confidence

Current-spec patterns detected

Summary

Single tool with well-structured schema and detailed parameter descriptions. The pokemon-card-search tool has a comprehensive input schema with 14 parameters, all properly typed and described. Naming follows verb_noun pattern (search_). Descriptions are detailed and include field-specific guidance. However, output schema is not documented in the source, only the Card interface is defined internally. The server lacks error handling patterns, recovery guidance, and confirmation steps for potentially expensive operations. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The extensive field descriptions in FIELD_DESCRIPTIONS constants show good intent but are verbose and somewhat redundant.

Tools (1)

pokemon-card-searchread onlysource verified85/100

Searches for Pokemon cards

Issues (5)

HIGHtool ↗

Output schema not documented for the LLM. The Card and PtcgResponse interfaces are internal TypeScript types, not exposed in the tool registration. LLMs cannot know what fields to expect in the response, preventing proper downstream planning and field extraction.

pokemon-card-search

MEDIUMtool-annotations ↗

No tool annotations present. Missing readOnlyHint, destructiveHint, and idempotentHint in the tool registration. Since this is a read-only search, it should be annotated with readOnlyHint=true to indicate safety for retry and caching.

pokemon-card-search

HIGHrecovery-guide ↗

No error handling or recovery guidance. If the PTCG API returns 404, rate limit, or invalid filter combinations, there are no error messages guiding the LLM on what to do next (retry, simplify query, check parameter values).

pokemon-card-search

MEDIUMpaginated-result ↗

Result limiting not enforced or documented. The tool accepts page and pageSize parameters but the description does not state the maximum page size or default result cap. Large unbounded queries could exhaust context window.

Recommendations

Add explicit output schema documentation to the tool registration. Document the PtcgResponse and Card structures (fields, types) so the LLM knows what to expect. At minimum: return type is object with data (array of Card), page (number), pageSize (number), count (number), totalCount (number).
Add tool annotation 'readOnlyHint': true to pokemon-card-search to signal it is safe for retry and caching.
Implement error handling with actionable recovery messages. For example: 'Invalid query syntax. Check that attacks, weaknesses, and set filters use dot notation (e.g., "set.id:sm1", "attacks.name:Spelunk").' Or: 'Too many results (10000+). Refine your query with name, type, or set filters, or increase pageSize.'
Document maximum page size and default limit in the pageSize and page parameter descriptions. E.g., 'Optional page size (1-250, default 20).'
Consolidate verbose field descriptions. Replace repetitive FIELD_DESCRIPTIONS snippets with a single, concise description per parameter. The current approach burdens the LLM context with redundant instructions.
Add a total_count field to the response (likely present in PtcgResponse.totalCount) so the LLM knows whether more results are available and can paginate intelligently.
Consider adding a dry_run or validation parameter if the API supports it, allowing the LLM to preview results before committing expensive queries.

Score history

Overall score trend

↑ 59 points across a rubric change (v1 → v2)

59/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	D	59	2026-07-28+	v2
2026-03-09	F	0	-	v1