Pokemon Trading Card Game MCP
Catalog metadata: game version, schema version, card/printing/set/pack counts, and supported locales. Quote the game version alongside any simulation result so the evidence stays pinned to the data it was computed from.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying exactly which metadata fields the tool exposes and by recommending the game version be cited with simulation results. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence front-loads the tool's core purpose and contents; the second adds a practical usage note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only metadata endpoint, the description is sufficient: it lists the data categories and explains why the version field matters. A return-format example would be a minor enhancement but is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the schema to document. The description appropriately focuses on the tool's output contents instead of parameter behavior, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear resource—catalog metadata—and enumerates its contents: game version, schema version, card/printing/set/pack counts, and supported locales. This differentiates it from card-search or deck-evaluation siblings, though it lacks an explicit action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives concrete usage context: quote the game version alongside any simulation result to tie evidence to the underlying catalog data. It does not state exclusions or alternatives, but the intended role of the tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a 20-card Pokémon TCG Pocket deck against the game's rules (exactly 20 cards, at most 2 copies of a card, at least one Basic Pokémon) and return build advice: missing evolution lines, energy-type spread, Pokémon/Trainer balance, missing staple Trainers, and known card synergies. Takes gameplay card ids, not printing ids.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | The deck list, one entry per distinct card. | |
| locale | No | Locale for card names in messages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description meaningfully extends this by specifying exactly what checks are performed and what advice will be returned. The clarification that it takes gameplay card ids, not printing ids, adds important operational context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, front-loaded with the core purpose, followed by a compact list of validation rules and output topics. Every phrase earns its place; there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does well to enumerate the validation rules and the categories of advice the caller can expect. It could additionally mention how locale affects output or what happens for invalid decks, but the essential information for selecting and invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents cards and locale. The description adds valuable disambiguation by emphasizing that gameplay card ids are required, not printing ids, which is a subtle but critical detail for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Check'), a specific resource ('a 20-card Pokémon TCG Pocket deck'), and precisely enumerates the validation rules and advice categories. This makes the tool's purpose unmistakable and clearly distinct from siblings like suggest_deck or simulate_matchup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case—evaluating an existing decklist against game rules—is clearly implied by the description, but it does not explicitly state when to use this tool versus alternatives such as suggest_deck or simulate_matchup. There is no 'use this when...' or 'instead of...' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Pokémon TCG Pocket card's available catalog data: HP, attacks with energy costs and damage, abilities, weakness, retreat cost, evolution, artist, rarity, and artwork. Trainer cards return their rules text and subtype instead of attacks. Accepts either a printing id like 'A1-001' or a gameplay card id like 'PK_000010'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Printing id ('A1-001') or gameplay card id ('PK_000010'). | |
| locale | No | Locale for names and text. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, and the description adds useful behavioral detail: which catalog fields are returned and that trainer cards substitute rules text/subtype for attacks. No contradiction and no hidden mutation or side-effect concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the main purpose, then add the trainer-card exception and accepted id formats. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still tells the agent what fields come back, how trainer cards differ, and how to identify the card. Nothing essential is missing for a simple, read-only single-card lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are already described with examples and default behavior. The description repeats the id examples but adds no new parameter semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('one ... card's available catalog data'), and enumerates the returned fields, which makes its purpose unmistakable and distinguishable from the list/search siblings like search_cards and list_printings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for fetching a single card by an id, and gives the two accepted id formats, so an agent knows when it applies. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every locale code the catalog has translations for. Pass one as 'locale' to any other tool for localized card, set, and pack names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only behavior is already covered by the readOnlyHint annotation, and the description adds useful context: the list is exhaustive for all locales the catalog has translations for, and the returned values are valid inputs to sibling tools. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both substantive. The first states the tool's exact scope, and the second gives immediate practical guidance. No redundant phrases or irrelevant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description fully covers what the tool does and how the result should be used. An agent has everything it needs to decide to call it and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is effectively 100% since there is nothing to document. The description adds no parameter detail, which is appropriate because no parameters exist. The baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('every locale code the catalog has translations for'), making it immediately distinguishable from sibling tools like list_packs and list_sets. It also clarifies the purpose of the result: locale codes needed by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear downstream usage: pass the returned locale code as 'locale' to any other tool for localized names. It does not explicitly discuss when not to use the tool, but for a lightweight enumeration tool that is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Pokémon TCG Pocket booster pack with its id, parent set id, and localized name. Pack ids identify where a printing can be pulled.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale for pack names. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate that this is a safe read. The extra sentence about pack ids identifying pull locations adds useful domain context beyond the structural schema, and the 'every' wording conveys that no filtering or pagination is involved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and resource, then the returned fields, then the domain context. Every sentence earns its place and no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless-required read-only list tool, the description covers what is listed, the fields returned, and why pack ids matter. The absence of an output schema is mitigated because the description already names the output fields explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, locale, is already fully described in the schema including its default value, so schema coverage is 100%. The description does not need to repeat parameter details; the mention of 'localized name' loosely ties the locale parameter to the output but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and resource ('every Pokémon TCG Pocket booster pack'), and enumerates the returned fields: id, parent set id, and localized name. This makes the tool's purpose unambiguous and distinguishable from sibling tools like list_sets or list_printings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool as the way to enumerate all booster packs, and adds context that pack ids identify where a printing can be pulled. It does not explicitly state when not to use it or name alternatives, but for such a simple read-only list tool the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every printing of one card across all sets: printing id, set, collector number, rarity, artist, and canonical page URL. Accepts either a printing id like 'A1-001' or a gameplay card id like 'PK_000010'. get_card only returns the first printing; use this when the question is about reprints, alt arts, or pull sources.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Printing id ('A1-001') or gameplay card id ('PK_000010'). | |
| locale | No | Locale for names. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior context: it accepts both printing ids and gameplay card ids, and it lists the exact fields returned. It does not mention pagination or locale effects, but these are minor for a read-only listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose and output fields are front-loaded, then the dual-id behavior is stated, then the routing guidance to get_card is provided. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the return fields and id formats, which is enough to call the tool correctly for typical reprint/alt-art questions. Since there is no output schema, describing the fields is helpful. A small gap is that it does not explicitly state pagination or what happens when no printings match, but the read-only nature and clear purpose keep this from being a serious omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter description coverage for both id and locale, including the same id format examples ('A1-001', 'PK_000010'). The description does not add meaning beyond the schema for either parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List every printing of one card across all sets,' with concrete output fields. It also distinguishes itself from get_card, which is a sibling tool, by noting the get_card only returns the first printing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool: when the question is about reprints, alt arts, or pull sources. It also names the alternative (get_card) and explains why that alternative is insufficient in this case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Pokémon TCG Pocket set with its id and localized name. Use the ids to filter search_cards by set.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale for set names. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description goes beyond them by specifying the output includes ids and localized names, and that the list is exhaustive ('every'). It doesn't mention ordering or pagination, but for a read-only list 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The core behavior is front-loaded, and the usage guidance is delivered in a single actionable sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with zero required parameters and a full schema, the description provides enough context: it names the resource, the return shape, and the workflow. No output schema exists, but the description covers the essential return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the only parameter, locale, is 100% and the schema already states its purpose and default. The description adds the context that set names are localized, which slightly reinforces the parameter's meaning, but the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), a clear resource ('every Pokémon TCG Pocket set'), and the returned fields ('id and localized name'). It also connects directly to a sibling tool ('search_cards') by explaining how the ids are meant to be used, distinguishing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the tool's output: to filter search_cards by set. It doesn't spell out exclusions or alternatives like list_packs or list_printings, but the intended workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Pokémon TCG Pocket card catalog by name, attack, ability, artist, or id, with optional filters for set, energy type, stage, card kind, rarity, Trainer subtype, HP range, weakness, and retreat cost. Returns up to 20 summarized cards plus the total number of matches.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Set id, e.g. 'A1', 'A2b', 'PROMO-A'. | |
| kind | No | ||
| page | No | 1-based page number. Defaults to 1. | |
| hpMax | No | Maximum HP (Pokémon only). | |
| hpMin | No | Minimum HP (Pokémon only). | |
| query | No | Free text: card name, attack or ability text, artist, or card id. | |
| stage | No | ||
| energy | No | Energy type of the Pokémon. | |
| locale | No | Locale for card names, e.g. 'en', 'ja_JP', 'fr_FR'. Defaults to 'en'. | |
| rarity | No | Rarity code, e.g. 'diamond-1', 'star-2', 'crown'. | |
| weakness | No | Weakness energy type of the Pokémon. | |
| retreatMax | No | Maximum retreat cost (Pokémon only). | |
| trainerType | No | Trainer subtype: item, supporter, tool, fossil, or stadium. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds useful behavioral context by stating the result cap ('up to 20 summarized cards') and that the total number of matches is returned. It does not specify pagination or result ordering, but this is a reasonable level of disclosure for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff; the core action and scope are front-loaded, and the return behavior is stated at the end. The enumeration of filters is dense but necessary for a search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 optional parameters and no output schema, the description provides a solid overview of searchable fields, filterable attributes, and return shape. It lacks detail on sorting or result field structure, but combined with the schema's high coverage, the tool is adequately specified for an agent to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 85%, so the schema already documents most parameters in detail. The description adds a compact grouping of query and filters, which reinforces the query parameter's role but does not materially go beyond the schema's existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Search') and a clear resource ('the Pokémon TCG Pocket card catalog'), and enumerates the exact searchable fields: name, attack, ability, artist, or id. It also lists the optional filters, distinguishing this search operation from sibling tools like get_card, which retrieves a single card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when looking for cards by free-text query and/or applying any of the listed filters. It does not explicitly name sibling alternatives or state exclusions, but the search context is clear enough for an agent to select this tool over catalog_info or get_card.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run two legal 20-card Pokémon TCG Pocket decks through the Battle Lab rules engine using deterministic heuristic AI. Returns wins, draws, failures, average turns/actions, and a short sample game log. This measures the built-in AI policy, not human skill or competitive win probability.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Base random seed. Reusing the same inputs and seed reproduces the result. | |
| deckA | Yes | First deck to compare. | |
| deckB | Yes | Second deck to compare. | |
| games | No | Number of simulated games. Defaults to 20; maximum 50. | |
| locale | No | Locale for card names in the sample log. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that behavior is deterministic, uses a heuristic AI policy, and returns specific summary metrics and a sample log. It also clarifies that results reflect the AI policy rather than human performance, adding meaningful interpretive context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core action, then lists outputs, then clarifies the tool's interpretational boundary. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers high-level return values: wins, draws, failures, average turns/actions, and a sample game log. It also explains the AI policy limitation. It stops short of specifying the exact output structure, but is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides, but it also does not need to since the schema fully documents deck, seed, games, and locale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Run two legal 20-card Pokémon TCG Pocket decks through the Battle Lab rules engine' using deterministic heuristic AI. It clearly distinguishes itself by stating it measures the built-in AI policy, not human skill or competitive win probability, which separates it from evaluation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for deterministic AI-vs-AI matchup simulation and not for estimating human skill or competitive win probability. It provides a clear when-not-to-use signal, though it does not explicitly name sibling alternatives such as evaluate_deck or trial_deck.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a complete, legal 20-card Pokémon TCG Pocket deck around a chosen card. Returns a named archetype, why it works, limitations, and the full card list with copy counts. Trainer targets produce a legal baseline with an explicit effect-data limitation. Give either a card name to search for or a gameplay card id.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Card name to build around, e.g. 'Charizard ex'. | |
| cardId | No | Gameplay card id, e.g. 'PK_000960'. | |
| locale | No | Locale for card names. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only safety is covered. The description adds valuable behavioral context beyond that: it specifies what the response contains and, notably, discloses a limitation for Trainer targets ('explicit effect-data limitation'). This gives the calling agent useful expectations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tight sentences with no filler: purpose, output, limitation, and input instruction. Each sentence earns its place, and the most important information (what it builds) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does a good job covering return contents and a known limitation. One minor gap is that it strongly implies at least one of query/cardId is needed but the schema marks zero parameters as required; the description could state this requirement more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds real semantic value by indicating that query and cardId are alternatives ('either... or...'), and its examples align with the schema's examples. This clarifies the intended relationship between the two main parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and a precise resource: a complete, legal 20-card Pokémon TCG Pocket deck around a chosen card. It also enumerates the output components (archetype, reasoning, limitations, card list), which clearly separates it from siblings like evaluate_deck or trial_deck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the purpose: use this when you want a deck built around a specific card. It gives input guidance ('Give either a card name... or a gameplay card id') but does not explicitly contrast with sibling tools such as search_cards, evaluate_deck, or trial_deck, nor state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solo-trial one legal 20-card Pokémon TCG Pocket deck: opening-hand consistency (Basics per opener, Trainer density, how often each card shows up across sampled hands) plus mirror self-play with the deck on both seats (closing speed and first-player bias). Use this to tune a single deck; use simulate_matchup to compare two decks. Takes gameplay card ids, not printing ids.
| Name | Required | Description | Default |
|---|---|---|---|
| deck | Yes | The deck to trial. | |
| seed | No | Base random seed. Reusing the same inputs and seed reproduces the result. | |
| games | No | Mirror self-play games. Defaults to 10; maximum 50. | |
| hands | No | Opening hands to sample. Defaults to 50; maximum 200. | |
| locale | No | Locale for card names. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context by detailing what the trial measures: Basics per opener, Trainer density, card appearance across hands, closing speed, and first-player bias. It does not discuss side effects or failure modes, but the read-only hint makes that less necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core function is front-loaded, the measured metrics are compactly listed after a colon, and the alternative-tool routing is in the second sentence. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carries the burden of describing results; it covers the expected metric groups well (opening-hand consistency, mirror self-play, closing speed, first-player bias). It does not specify the exact result shape or labels, but the described outcomes are sufficient for an agent to invoke the tool and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents deck, seed, games, hands, and locale. The description contributes an important clarification the schema does not emphasize: 'gameplay card ids, not printing ids,' which materially improves correct parameter use. It also reinforces the 'legal 20-card' requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Solo-trial one legal 20-card Pokémon TCG Pocket deck.' It enumerates the two things the tool computes (opening-hand consistency and mirror self-play) and names simulate_matchup as the comparison alternative, so an agent can distinguish it from related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing guidance: 'Use this to tune a single deck; use simulate_matchup to compare two decks.' It also adds a practical selection constraint with 'Takes gameplay card ids, not printing ids,' which helps avoid a common invocation mistake.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: catalog metadata, search, single-card retrieval, printings, sets, packs, locales, and deck validation/creation/testing/simulation are all cleanly separated. Even the deck-related tools are unambiguous because each targets a different stage: validate, suggest, trial, or matchup.
The vast majority of tools follow a predictable verb_noun pattern (list_sets, get_card, search_cards, simulate_matchup, evaluate_deck). The only outlier is catalog_info, which uses a noun_info form instead of an imperative verb, creating a minor but noticeable deviation.
At 11 tools, the server is well-scoped for its domain of card-catalog lookup and deck analysis. Each tool covers a distinct function and none feel redundant or unnecessary.
The catalog surface is strong with search, get, list, and metadata tools, and the deck workflow covers validation, suggestion, solo trialing, and matchups. Minor gaps exist: search_cards returns at most 20 results with no pagination, and there are no detailed set/pack getters, but agents can work around these with existing tools.