pokemon-tcg-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: card search vs. single-card fetch vs. effect search, collection management operations are clearly separate, and session tools are distinct. Even the two search tools (search_cards and find_similar_effects) have clearly differentiated purposes and inputs.
Naming Consistency3/5
The naming is split between verb-first (search_cards, get_card, check_deck, price_check, build_decks, resolve_scanned) and noun-first (collection_list, collection_add, session_list, session_save) patterns, with a few oddities like meta_snapshot and find_similar_effects. It's readable but not consistently predictable.
Tool Count5/5
14 tools is a solid, well-scoped count for a Pokemon TCG server covering card lookup, collection management, deck validation/building, meta info, and session persistence. Every tool earns its place with no obvious bloat.
Completeness4/5
The surface covers card discovery, detailed lookup, collection CRUD, deck validation/building, price checking, meta snapshots, and session persistence. Minor gaps exist—most notably no session delete or update—but agents can work around them, and the core workflows are well covered.
Average 4.2/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful behavioral traits: keywords are ORed and results are ranked by match count. It does not describe return format, limits, or authentication requirements, but as a read-only discovery tool the safety profile is reasonable to infer.
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?
The description is two concise sentences, front-loaded with the core purpose and immediately providing a usage example. Every word adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and only one parameter meaningfully described, the description leaves return values and important filtering behavior unexplained. It captures the core use case but is incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description only adds insight for effect_text with an example. The other parameters (supertype, max_results, standard_legal_only) are left undocumented, so the agent receives little guidance beyond raw defaults and enums.
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 clearly identifies this as a discovery tool for finding cards by plain-language effect descriptions, complete with a concrete example. It distinguishes itself from generic card search by emphasizing 'effect in plain words' and matching attack/ability/rules text.
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 'Discovery tool' framing and plain-words example establish when this tool should be used, and the ORed/ranking detail provides helpful context. It does not explicitly mention alternatives like search_cards or state when not to use it, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds valuable behavioral context by stating it fetches live data and returns a 'source unavailable' message rather than stale guesses. It does not mention read-only nature or side effects, but for a snapshot tool this is reasonably transparent.
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?
The description is two sentences, front-loaded with the primary purpose, and contains no fluff or repetition. Every sentence earns its place by conveying source, data content, and failure behavior.
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?
Given the low complexity (2 params, no output schema, no annotations), the description covers purpose, data source, return contents, and failure mode. It lacks parameter details and output structure, but is otherwise sufficiently complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain the 'format' or 'max_results' parameters. Although names are intuitive, the description fails to compensate for the lack of schema descriptions, which is required when coverage is low.
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 clearly states the tool provides 'current top archetypes from Limitless TCG' with 'tournament points and meta share', identifying a specific verb and resource. It distinguishes itself from sibling tools like search_cards and check_deck by focusing on competitive meta data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While sibling tools serve different functions, the description does not mention any exclusions or alternative choices, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It reveals the data sources (Cardmarket/TCGplayer) and the highlight behavior, which is useful. However, it does not mention whether prices are live/cached, error handling for unknown cards, or that this is a read-only operation.
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?
The description is a single, well-structured sentence that front-loads the core function (prices for every printing) and adds key details (markets and highlight). No redundant or filler content.
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?
For a 2-parameter tool with no output schema, the description provides a solid understanding of what the tool does and what to expect (multiple printings with prices, highlighted cheapest standard-playable). It could mention return format or pagination, but it is sufficiently complete for typical pricing lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters with examples (name and set), so the description adds no additional parameter semantics. Since schema description coverage is 100%, the baseline of 3 applies.
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 clearly states the tool provides Cardmarket (EUR) and TCGplayer (USD) prices for every printing of a card, with a specific highlight for the cheapest standard-playable version. This distinguishes it from sibling tools like get_card or search_cards, which likely focus on card data or search, not pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pricing inquiries by mentioning the sources and scope, but it does not explicitly say when to use this tool over alternatives. No exclusions or alternative tool references are given, so the suitability must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does list the validation checks performed, which is useful. However, it omits what happens on validation failure (e.g., error vs. report), the return format, and any permissions or side-effect details. This leaves gaps in understanding the tool's behavior.
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?
The description is a single sentence that front-loads the core purpose and then specifies all key validation rules. Every clause adds informative detail with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description covers purpose, input format, and validation rules. However, without an output schema, the description should explain what the tool returns (e.g., validation report, price estimate shape). This missing return-value information makes the description somewhat incomplete for an agent to fully anticipate the tool's output.
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 100% for the single parameter, giving a baseline of 3. The description adds value by providing an example format ('4 Slowpoke PBL 29') and clarifies the input as TCG Live export format, going beyond the schema's basic description.
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 clearly states the tool's purpose: 'Validate a TCG Live export decklist' and details specific validation rules (60-card total, max 4 copies per name, ACE SPEC limit, standard legality, price estimate). This distinguishes it from siblings like price_check or build_decks.
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 implies when to use the tool: when an agent has a TCG Live export decklist that needs validation and a price estimate. It provides clear context but does not explicitly mention alternatives or when-not-to-use scenarios relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of transparency. It discloses 'newest first' ordering and lists the fields returned, which implicitly suggests a read-only operation, but it doesn't explicitly state that no side effects occur, require permissions, or handle empty lists. Some behavioral detail is provided, but not exhaustive.
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?
A single concise sentence captures the resource, the returned fields, and sorting order without any filler or redundancy. Every word earns its place, making it highly efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool with no output schema, the description is fully complete: it names the resource, enumerates the return values, and specifies ordering. There is no missing information that an agent would need to confidently invoke this tool.
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?
The tool takes zero parameters, so schema coverage is trivially 100%. The description adds value by explaining what the returned list contains (name, save time, card count, deck names), which provides context beyond the empty schema. However, with no parameters, there is little to add, so the baseline of 4 is appropriate.
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 clearly states the tool's function: 'All saved kitchen-table sessions' with explicit mention of returned fields (name, save time, card count, deck names) and sort order ('newest first'). This distinguishes it from sibling tools like session_save and session_load, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided, but the listing behavior is implied by the verb 'List' and the resource 'saved sessions'. Sibling tools session_save and session_load exist, yet the description doesn't clarify when to use this tool over them, such as 'use session_load to load a specific session'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return contents (full text, image URL, prices) and the two identification modes, but doesn't mention error behavior, rate limits, or what happens if both id and name are provided. It's adequate but not rich.
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?
Two sentences, immediately front-loaded with the core action. Every clause earns its place—the first sentence states what it does, the second how to identify the card. No wasted words.
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?
Despite lacking an output schema, the description names the key return fields (text, image URL, prices). For a low-complexity single-card fetch, this is sufficient. It could be more complete with a note on not-found behavior, but that's a minor gap.
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?
The schema covers each parameter individually (100% coverage), so the baseline is 3. The description adds value by explaining the logical relationship: either id OR name+set, with examples. This goes beyond the schema's flat definitions.
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 'Fetch one card with full text, image URL and prices,' clearly stating the verb, resource, and scope. It distinguishes from siblings like search_cards by emphasizing 'one card' and requiring an exact identifier.
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?
Guidance is clear about needing either an id or an exact name plus optional set code, implying that partial/incomplete identifiers belong in search tools. However, it doesn't explicitly mention alternatives or exclusions like 'use search_cards instead when you don't have an exact name or id.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses non-obvious behavior: raw Lucene passthrough, ANDed filters, and compact summaries. It stops short of describing pagination, rate limits, or sorting, but the core semantic behavior is well covered.
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?
Two sentences with front-loaded purpose, a concrete example, and no wasted words. The structure clearly communicates the essential behavior in minimal space.
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?
There is no output schema, so the description's mention of 'compact card summaries' gives some idea of the return shape but lacks field details. It covers the main query mechanics well, and for a search tool with no required parameters, this is largely complete, though pagination/error behavior is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57% (4/7). The description adds meaningful semantics for 'query' (name or Lucene) and filter behavior (ANDed), but does not elaborate on max_results, standard_legal_only, or supertype beyond their schema names/enum. Partial compensation for the coverage gap.
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 clearly states the tool searches the pokemontcg.io card database, with a specific verb ('Search') and resource, and provides query syntax details and return type. This distinguishes it from siblings like get_card (specific card retrieval) and find_similar_effects.
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?
It gives clear context for when to use this tool: to search cards flexibly via name or Lucene query, with filters ANDed. It doesn't explicitly exclude alternatives or mention when to prefer other tools, but the usage context is well stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behavioral details: the name defaults to today's date, and a name collision appends -2 rather than overwriting. This is valuable context beyond a simple save statement, though return values and failure modes are not mentioned.
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?
The description is two sentences with no filler. The first sentence states the action and optionality, the second covers naming defaults and collision handling. It is front-loaded and every sentence earns its place.
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 core functionality, the required parameter, default behavior, and an edge case. However, with no output schema, it omits any mention of return value or storage location, which is a minor gap for a write operation. Overall, it is largely complete for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as each parameter has a description. The description restates the TCG Live format for lines and mentions decks are optional, but it adds no new semantics beyond the schema. The default name behavior is also already documented in the schema, so this matches the baseline of 3.
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 uses a specific verb 'Save' to indicate persisting session card lines and optionally built decks as a timestamped JSON record. It clearly identifies the resource and output format, distinguishing it from sibling tools like session_load and session_list.
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 clearly implies the tool is for saving session data, but it does not explicitly contrast it with alternatives like session_load or session_list. No exclusions or when-not-to-use scenarios are provided, yet the primary use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this admirably, explaining the deterministic algorithm, the grouping by evolution lines, exact deck-size assembly, the counter-score minimization for deck_count=2, and validation against check_deck rules. It doesn't disclose the return format, but the core behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, packing a large amount of algorithmic detail into two sentences. The first sentence is long and complex, but each clause adds necessary information; a slight restructure could improve readability, but it is not wasteful.
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?
Given the algorithmic complexity and absence of an output schema, the description provides a remarkably complete overview: the internal strategy, constraints, validation, and optimization behavior. It stops short of describing the exact return value or structure, but the overall behavior is well specified.
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?
The schema provides descriptions for most parameters, and the description adds algorithmic context that enriches understanding (e.g., deck_size affects proportional scaling, deck_count triggers the rebuild-and-minimize process, owned_only controls proxy suggestions). This goes beyond the raw schema definitions.
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 uses a specific verb ('build') and identifies the resource ('decks from the collection'), and further distinguishes itself by describing its deterministic, evolution-based approach. This clearly separates it from sibling tools like search_cards or check_deck.
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 clearly implies when to use this tool: when you need a deterministic deck built from the local collection, with optional optimization for two decks. It doesn't explicitly mention alternatives, but the context is unambiguous, and the mention of 'validates with the check_deck rules' hints at a complementary relationship with check_deck.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that cards are appended or incremented, that ambiguous matches lead to no changes and candidate listing, and that comments in the file are preserved. It does not cover error handling or output format, but it covers several important behaviors.
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?
The description is compact and front-loaded, with just two sentences. The first sentence states the core action, and the second provides essential input format and ambiguity handling. Every word earns its place.
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?
For a simple one-parameter tool, the description covers the input format, ambiguous lookup behavior, and comment preservation. It does not describe the success return value, but with no output schema and low complexity, this is a minor omission. Overall, it is sufficiently complete.
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?
Although the schema covers the only parameter 100%, the description adds crucial context: the TCG Live format, one line per card, and the behavior when a name lacks a set code. This goes beyond the schema's simple example and enriches the parameter's meaning.
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 clearly states the tool's function with a specific verb+resource: 'Append or increment cards in the collection file.' It is distinct from sibling tools like collection_remove and collection_list, and the input format is given.
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 makes it clear this tool is for adding cards to the collection, and it provides input format and special handling for ambiguous lookups. It doesn't explicitly mention alternatives or exclusions, but the intended use is obvious given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals what the tool returns (card lines in TCG Live format, named decklists), which is important for an agent to understand the output. It doesn't mention error behavior or side effects, but for a read-only load operation, the format disclosure is significant.
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?
The description is two concise sentences, front-loaded with the core purpose and followed by a useful output-format note. Every sentence earns its place with no redundant information.
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?
Given the tool is simple (one parameter, no output schema), the description is complete enough. It explains what the tool does and what the output looks like. Minor gaps like handling of non-existent sessions are not critical for this level of completeness.
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?
The schema covers the 'name' parameter at 100% with 'Session name as shown by session_list'. The description adds further meaning by tying the parameter to the session_list tool, telling the agent where to obtain valid values. This goes beyond the schema's basic description.
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 states a specific verb and resource: 'Load a saved session by name', distinguishing it from siblings like session_save and session_list. It also specifies the output format (card lines in TCG Live format, decks as decklists), making the purpose fully explicit.
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 provides clear context by mentioning that the output is meant to be pasted into collection_add/check_deck/resolve tools, indicating when this tool is useful. It doesn't explicitly exclude alternatives, but the integration hint gives strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly notes the operation is local ('no API'), describes the clamping behavior on over-removal, and explains the do-nothing behavior for ambiguous bare names. This covers key edge cases and side effects, though it could mention whether the file is modified in-place or what happens on success.
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?
The description is two sentences, front-loading the core action and then providing essential edge-case behavior. Every sentence contributes meaningful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is remarkably complete. It explains the core operation, the local-only behavior, and handles ambiguity and over-removal. The sibling context further clarifies its role among collection tools.
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 100%, with the 'lines' parameter already documented via examples. The tool description adds interpretative meaning by explaining that bare names may be ambiguous if they match multiple printings, and that over-removal clamps to zero. This goes beyond the schema's basic format description.
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 clearly states 'Decrement or drop cards in the collection file,' specifying both the action (decrement/drop) and the resource (collection file). It also adds scope with 'matched against the file itself (no API),' distinguishing it from API-based tools and siblings like collection_add.
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 implies when to use the tool (for local collection removal) and provides important usage constraints: a bare name matching multiple printings is ambiguous and changes nothing, and over-removal clamps to zero with a note. While it doesn't explicitly name alternatives, the guidance on ambiguity effectively tells the user to specify printings to ensure successful removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explains the parsing behavior, comment handling, output summary totals, and explicitly states that unresolvable lines become warnings rather than errors. This adds valuable context about failure modes and behavior.
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?
The description is two sentences, packed with relevant information but every clause earns its place. It is front-loaded with the core purpose and then provides necessary configuration and output details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is remarkably complete. It covers the source file, format, parsing rules, output content, and error handling, leaving no significant gaps for an agent to understand what the tool does and what to expect.
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?
The tool has zero parameters, so the baseline is 4. There is nothing to add beyond the empty schema, and the description appropriately focuses on the tool's behavior rather than parameter details.
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 clearly states that the tool provides a parsed and resolved view of the local collection file, with specific details about the file path and output contents (counts, sets, kinds, legality). This distinguishes it from sibling tools like collection_add, collection_remove, and search_cards.
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 clear context about when to use the tool—for inspecting the local collection—and specifies configuration details (env POKEMON_COLLECTION_PATH, default path, line format). However, it does not explicitly mention alternative tools or scenarios where it should not be used, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so exceptionally. It discloses key behaviors: quantity optionality, set inference from card numbers, Japanese set code mapping with numbering differences, bare-name resolution preferring newest standard-legal printings with alternatives, and return of unresolved lines with reasons. This is rich, candid behavioral disclosure.
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?
The description is a single dense paragraph that is front-loaded with the purpose, then provides concrete examples and output details. Every sentence contributes value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers input variations, resolution strategies, output format, and downstream integration, leaving no significant gaps for an agent to infer incorrectly.
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?
The schema already covers the 'lines' parameter with a description and example (100% coverage). The description adds substantial extra meaning by illustrating acceptable messy formats, edge cases like Japanese codes, and output expectations, thereby going beyond the schema's baseline.
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 clearly specifies the tool's function: resolving messy raw card identifications from photos into verified printings. It provides concrete input examples and distinguishes itself from sibling tools like search_cards (searching) and collection_add (adding) by focusing on resolution and normalization.
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 strong context on when to use this tool—when lines are messy, include quantities, Japanese codes, or bare names—and explains the output's downstream use with collection_add, check_deck, or build_decks. However, it does not explicitly name alternatives or state when not to use it, falling just short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pokemon-tcg-mcp MCP server](https://glama.ai/mcp/servers/mopheadpersona/pokemon-tcg-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mopheadpersona/pokemon-tcg-mcp)

Score Badge

Copy to your README.md:

[![pokemon-tcg-mcp MCP server](https://glama.ai/mcp/servers/mopheadpersona/pokemon-tcg-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mopheadpersona/pokemon-tcg-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mopheadpersona/pokemon-tcg-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server