Pokémon TCG Pocket MCP Server

Overview Schema Source Related Servers Discussions Admin

Search Pokémon TCG Pocket cards

search_cards

Read-only

Search Pokémon TCG Pocket cards by name, type, rarity, set, evolution stage, attack, or effect, with fuzzy and semantic matching across languages.

Instructions

Search Pokémon TCG Pocket cards. All fields except language are optional; omitted or null fields match everything. Enum fields filter exactly, name and set filter fuzzily, effect and attack rank by meaning. Enum values are English in every language. Results with fallbackLanguage exist only in that language.

Input Schema

TableJSON Schema

Name	Required	Description
`set`	No	Set id (e.g. "A1") or fuzzy set name.
`name`	No	Card name, fuzzy matched.
`type`	No	Pokémon type.
`limit`	No
`stage`	No	Evolution stage, name or 0-2.
`attack`	No	Semantic search over attacks (name, energy cost, damage, effect).
`effect`	No	Semantic search over ability and trainer effect texts.
`offset`	No	Number of results to skip, for paging. Use nextOffset from the previous call.
`rarity`	No
`category`	No
`language`	Yes	Language of card texts and of name/set queries.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.0.4Sep 20, 2026

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Number of results to skip, for paging. Use nextOffset from the previous call.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

First observedv1.0.0Sep 19, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description significantly extends the annotations (readOnlyHint=true): it discloses query interpretation behavior (fuzzy, exact, semantic ranking), null-field semantics, and the fallbackLanguage quirk. This gives the agent a strong model of what to expect beyond the safety hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each carrying distinct information: scope, optionality, matching behavior, and language/fallback. No filler or redundancy; the most important usage rule (all fields optional) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential behavioral aspects: filtering semantics, null handling, and language fallback. Pagination is left to the schema (offset/limit descriptions). With no output schema, it doesn't state the return shape, but 'search cards' makes that largely inferable; minor gap only.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 73%, and the description adds group-level semantics not explicit in the schema: name/set are fuzzy, effect/attack are semantic, enum fields are exact. It does not cover rarity/category specifics, but the 'enum fields filter exactly' rule applies to them, and the schema carries most parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Search Pokémon TCG Pocket cards' – a specific verb and resource that unambiguously defines the operation. With no sibling tools, there is no risk of confusion, and the rest of the description reinforces scope by describing the filtering model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on how to query: optional fields, null semantics, exact vs fuzzy vs semantic matching, and English-only enum values. Since there are no sibling alternatives, there are no 'use instead' conditions to state, so the guidance is clear and sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools

search_cardsA