A
licenseA
qualityB
maintenanceProvides AI assistants with comprehensive Magic: The Gathering data including card info, combos, draft analytics, Commander metagame, constructed formats, sideboard strategy, deck building, and rules.
74
MIT
tcgmcp
by com.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.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.5/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: single-card price lookup, comparing printings, market trends, and deck pricing. The descriptions explicitly cross-reference each other to prevent confusion, such as list_printings noting when to use it instead of price_card.
Naming Consistency4/5
All tool names are lowercase with underscores, and most follow a verb_noun pattern (list_printings, price_card, price_deck). market_index is a slight deviation as a noun_noun phrase, but the naming remains intuitive and predictable.
Tool Count5/5
With only 4 tools, the server is tightly scoped to its purpose of TCG pricing and market data. Each tool covers a distinct need without redundancy, and the count is well within the ideal range for a focused server.
Completeness5/5
The tool surface covers the core workflows for TCG pricing: single card lookups, comparing printings, decklist pricing, and market trend analysis. There are no obvious missing operations for the stated domain, making the set feel complete.
Available Tools
4 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.
ParametersJSON Schema
| 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
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context: the grouping field explanation with caveats about over/under-grouping, and that certain parameters cannot be combined. No contradictions.
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, no wasted words. Key information is front-loaded: what the tool does, use cases, and important caveats. Efficient and clear.
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 tool's purpose, use cases, return structure (grouping field, prices, treatments), and parameter constraints. With no output schema, the description adequately explains what is returned. Minor omissions like pagination are acceptable given the simplicity.
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 description coverage is 100%, so baseline is 3. The description adds semantic value by explaining the grouping field, mutual exclusivity constraints, and the intent parameter's effect. This goes beyond 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 clearly states it lists every known printing of a TCG card with per-finish prices and treatment tags, and explicitly distinguishes from sibling tool price_card by specifying when to use it instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for comparing printings, finding cheapest version, or specific treatment. It also mentions the grouping field and its potential inaccuracies, helping the agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_indexARead-onlyIdempotentInspect
Shows the cross-market price trend for a whole game or a single set — a chain-linked index (base 100) with 7/30/90-day movement, the total market value of one-of-every product, the median price, and how many products are priced. Use this for "how is Pokemon / this set trending" questions, or pass a comma-separated vs list to compare up to 3 scopes. This is trend data across a set, NOT a single card's price — use price_card or list_printings for one card.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vs | No | Optional: comma-separated extra scopes to compare against, e.g. 'pokemon,lorcana' or 'magic/fdn,magic/blb'. The primary scope plus compares are capped at 3 total. | |
| scope | Yes | A game (e.g. 'pokemon', 'magic') or a specific set as 'game/set' (e.g. 'magic/fdn', 'pokemon/ssp'). | |
| track | No | Optional product track: 'all' (default), 'singles', or 'sealed'. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only/idempotent safety, but the description adds substantial context: the index is chain-linked base 100, includes 7/30/90-day movement, total market value, median price, and product count. It also discloses cross-market behavior and the comparison cap of 3 scopes, enriching beyond annotations without contradiction.
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?
Three sentences, front-loaded with purpose, and each sentence earns its place: definition and metrics, usage examples, and exclusion/alternative guidance. No waste 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 read-only trend tool with no output schema, the description is complete: it explains what data is returned (index, movement, totals, median, count), when to use it, and how to compare scopes. All necessary context is present without needing to infer behavior.
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%, so parameters are well-documented. The description reinforces scope semantics ('whole game or a single set') and the `vs` list format (comma-separated, up to 3 total), but does not add major new meaning beyond the schema. Baseline 3 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 it 'Shows the cross-market price trend for a whole game or a single set' with specific metrics, distinguishing it from single-card price tools via 'NOT a single card's price — use price_card or list_printings for one card.' This makes the tool's purpose unambiguous and differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it for '"how is Pokemon / this set trending" questions' and explains how to compare scopes with a `vs` list. It also gives exclusionary guidance: 'NOT a single card's price' and names alternative tools. This is excellent when/when-not guidance.
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.
ParametersJSON Schema
| 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
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by specifying affiliate-wrapped link behavior and alternate handling for ambiguous names, with no contradictions.
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 concise with two efficient sentences: the first states the core purpose, the second adds return details and edge-case handling (alternates). No waste.
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?
With 3 params, 100% schema coverage, and informative annotations, the description covers main use, scope, and return behavior. It lacks explicit info on no-match cases or exact output structure, but is largely complete for its simplicity.
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 100%, providing all parameter details. The description adds no new parameter semantics beyond what the schema already states, meeting the baseline expectation.
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 looks up the current market price of a single TCG card across 22+ games, specifies it returns the best match's price and an affiliate link with alternates, and distinguishes itself from siblings (list_printings, price_deck) by focusing on single card price lookup.
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 implicitly guides usage for single card price queries and mentions alternates for ambiguous names, but does not explicitly contrast with siblings (e.g., when to use price_deck for decks) or state when not to use this tool.
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.
ParametersJSON Schema
| 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent. Description adds rich behavioral details: returns priced table, grand total, unresolved lines with suggestions, and affiliate link. No contradictions.
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: first states purpose and supported TCGs, second gives format and output summary. No fluff, front-loaded, efficient.
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?
With full schema coverage, annotations, and no output schema needed (output described), description provides all necessary context. Siblings listed, usage clear.
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 covers both params with descriptions (100% coverage). Description adds example format and clarifies optional game hint for ambiguity, adding value beyond schema.
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 prices a decklist for multiple TCGs and returns a TCGplayer cart link. It distinguishes from siblings (list_printings, price_card) by focusing on full decklists.
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 explains when to use with paste of raw decklist, gives format example, and mentions optional game hint. Does not explicitly say when not to use, but context with siblings implies it's for full lists.
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!
Related MCP Servers
- Flicense-qualityBmaintenanceProvides access to TCGplayer trading card data, including search, product details, pricing, and market information, enabling natural language queries for card analysis.1
- Alicense-qualityCmaintenanceEnables querying Yu-Gi-Oh! TCG card data, such as card information, sets, and prices, through natural language.10MIT
- Flicense-qualityAmaintenanceProvides Magic: The Gathering card, deck, provider, and statistical evidence tools for LLMs to make informed deckbuilding decisions.