tcgmcp
Server Details
Live TCG card and decklist prices for AI assistants. 22+ games, no account, ready-to-buy links.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 2 of 2 tools scored.
The two tools are clearly distinct: one prices a single card, the other prices a full decklist. No overlap in purpose.
Both tools follow a consistent `price_` prefix in snake_case, making them predictable and easy to remember.
Two tools is slightly thin for a TCG domain, but acceptable if the server is narrowly scoped to pricing only. Could benefit from additional tools like card searching.
The server lacks basic TCG operations such as card search, set details, or data beyond pricing. This creates gaps for common workflows.
Available Tools
3 toolslist_printingsARead-onlyIdempotentInspect
Lists every known printing of a TCG card (any of 22+ games) — every set it was printed in, with per-finish (nonfoil/foil) prices and treatment tags (border, frame, promo, full art). Use this instead of price_card when the buyer wants to compare printings, find the cheapest version, or find a specific treatment (e.g. borderless, showcase). Returns a grouping field: "oracle_id" means the printings are confirmed the exact same card; "normalized_name" is a best-effort name match that can occasionally over- or under-group.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Optional: narrow to a single set name/code. Cannot be combined with intent=cheapest or with finish/treatment. | |
| game | No | Optional game hint (e.g. 'Magic', 'Pokemon') when the name is ambiguous across games. | |
| name | Yes | Card name to look up. | |
| finish | No | Optional: narrow to printings available in a finish, e.g. 'foil' or 'etched'. Cannot be combined with intent=cheapest or with set/treatment. | |
| intent | No | Optional: "all" (default) lists every printing; "cheapest" returns only the lowest-priced one. Cannot be combined with set/finish/treatment. | |
| treatment | No | Optional: narrow to printings with a treatment/variant, e.g. 'borderless', 'showcase', 'full_art', 'boosterfun'. Cannot be combined with intent=cheapest or with set/finish. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds context about the grouping field, including the differences between oracle_id and normalized_name and potential grouping issues.
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 moderately concise and front-loaded with the main purpose. It provides all necessary information in a single paragraph. While it could be slightly more structured (e.g., bullet points), it remains readable and effective.
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 the tool has no output schema, the description adequately explains the key output field (grouping) and its semantics. It covers the essential functionality and parameter options. It could mention the return format more explicitly but is sufficient.
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 input schema has 100% description coverage, so the description is not required to explain parameters in detail. However, it adds valuable context such as constraints (e.g., cannot combine certain parameters) and the effect of the intent parameter.
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 clearly states the tool lists every known printing of a TCG card, specifying details like sets, finishes, prices, and treatment tags. It explicitly distinguishes itself from the sibling tool price_card with use cases.
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 explicit guidance on when to use this tool over price_card (comparing printings, finding cheapest, specific treatment). It also explains the grouping field semantics. However, it does not address when not to use it or mention the other sibling tool price_deck.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_cardARead-onlyIdempotentInspect
Looks up the current market price of a single TCG card (any of 22+ games: Magic, Pokemon, Yu-Gi-Oh, One Piece, Lorcana, and more). Returns the best match's price and an affiliate-wrapped TCGplayer product link, plus alternates when the name is ambiguous.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Optional set name/code to disambiguate printings. | |
| game | No | Optional game hint (e.g. 'Magic', 'Pokemon') when the name is ambiguous across games. | |
| name | Yes | Card name to look up. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive; description adds that it returns best match price, affiliate link, and alternates for ambiguous names, providing useful behavioral context.
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 wasted words, efficiently conveying purpose, output, and special behavior.
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 3 fully described parameters, no output schema, description covers what is returned (price, link, alternates), ambiguity handling, and supported games; minor omission: no explicit mention of currency or price format.
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 covers all parameters with descriptions; description reinforces game parameter but adds minimal new meaning beyond listing supported games.
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?
Description clearly states the tool looks up the market price of a single TCG card, lists 22+ supported games, and distinguishes from sibling price_deck by focusing on 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?
Implies use for single-card price lookup, but does not explicitly state when to use price_deck instead or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_deckARead-onlyIdempotentInspect
Prices a pasted decklist (any TCG: Magic, Pokemon, Yu-Gi-Oh, One Piece, Lorcana, and 18+ more) and returns a ready-to-buy TCGplayer cart link. Paste the raw decklist text — one card per line, quantity + name, e.g. '4x Lightning Bolt' or '2 Counterspell (7ED)'. Returns a priced table (qty, name, set, unit price, line total), a grand total, any lines that couldn't be resolved with did-you-mean suggestions, and one affiliate-wrapped buy link.
| Name | Required | Description | Default |
|---|---|---|---|
| deck | Yes | The raw decklist text, one card per line (e.g. "4x Lightning Bolt\n2 Counterspell (7ED)"). | |
| game | No | Optional game hint (e.g. 'Magic', 'Pokemon', 'Yu-Gi-Oh', 'One Piece', 'Lorcana') when the decklist is ambiguous. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral context: returns priced table, unresolved lines with suggestions, affiliate link, and input format details.
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 concise (three sentences) with front-loaded purpose, clear structure, and no unnecessary words.
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?
Despite no output schema, the description fully covers input format, supported games, and output components (priced table, total, suggestions, link), making it complete for agent understanding.
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?
With 100% schema coverage, the description adds meaning through examples (e.g., '4x Lightning Bolt') and explains the optional game hint, providing context 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 clearly states the tool prices a decklist and returns a TCGplayer cart link, covering multiple TCGs. It distinguishes from sibling price_card by focusing on decklists vs single cards.
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 details when to use (paste decklist, one card per line, examples) and implies alternative price_card for single cards, but does not explicitly state when not to use or name the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!