Midpoint Card Prices

Server Details

Trading card prices and grading ROI for 1.5M+ Pokémon, Magic, Yu-Gi-Oh! and sports cards. Read-only.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.6% over 21 days
Last Tested: 2026-10-01 23:42
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: kolourr/midpoint-mcp
GitHub Stars: 0
Server Listing: Midpoint MCP server

TDQS

A4.4/5.0

Scored 2026-09-21 17:40 across 9 tools

Disambiguation4/5

Most tools target a distinct action: search, single-card price lookup, price history, set checklist, set lookup, and grading ROI. The main ambiguity is between trending_cards and liquid_movers, which both identify gainers, though the descriptions differentiate them by liquidity and filter criteria.

Naming Consistency3/5

Five tools follow a get_/list_/search_ verb_noun pattern, but best_cards_to_grade, grading_roi, liquid_movers, and trending_cards are noun or phrase-style names. The naming is readable and consistently lowercase snake_case, but the conventions are mixed.

Tool Count5/5

Nine tools is well within the appropriate range for a card-pricing and grading-analysis server. Each tool covers a meaningful slice of the domain, from discovery and lookup to history, set data, market movers, and grading profitability.

Completeness5/5

For a read-only card-price and grading-analysis API, the surface is complete: search, full prices by condition and grade, price history, set-level checklists, trending/liquid lists, and grading economics. The ID dependencies are covered by search_cards and list_sets, so there are no dead ends.

Available Tools

9 tools

best_cards_to_gradeBest cards to gradeA

Read-onlyIdempotent

Inspect

Use this when the user asks which cards in a game, sport or set have the biggest payoff from grading. Ranks priced cards by expected net profit at a 50% gem rate (half PSA 10, half PSA 9, minus raw and the fee), requiring both PSA 9 and PSA 10 prices so thin-market outliers are excluded. Returns card ids for grading_roi. Do not use for a single named card.

ParametersJSON Schema

Name	Required	Description
`game`	Yes	Game or sport to rank.
`limit`	No
`set_slug`	No	Optional set slug (as used on /sets/<game>/<slug>) to rank inside one set.
`grading_fee_usd`	No	Grading fee to assume. Defaults to $25.

Output Schema

ParametersJSON Schema

Name	Required	Description
`game`	Yes
`cards`	Yes
`count`	Yes
`links`	Yes
`criteria`	Yes
`assumed_fee_usd`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The annotations already mark this as read-only and non-destructive, and the description adds valuable behavioral context beyond that: the 50% gem-rate calculation, expected net profit formula, the requirement for both PSA 9 and PSA 10 prices, and the consequent exclusion of thin-market outliers.

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, each earning its place: the use case is front-loaded, the second sentence gives the core calculation and eligibility rule, and the third states the output routing and an important exclusion. No redundant wording.

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 ranking tool with an output schema and safety-carrying annotations, the description provides everything an agent needs: the user intent trigger, the exact business logic, the data prerequisites, the output target, and a clear when-not-to-use boundary.

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 schema already documents game, set_slug, and grading_fee_usd, and the description reinforces the roles of game/sport/set and the fee in the calculation. However, the limit parameter has no schema description and the tool description does not clarify it either, so coverage is good but not complete.

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 action (rank priced cards by grading payoff), a clear resource (cards in a game, sport, or set), and a distinctive output (card ids for grading_roi). It also explicitly excludes single-card lookups, which helps separate it from sibling tools.

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 explicitly says when to use the tool ('Use this when the user asks which cards...') and gives an exclusion ('Do not use for a single named card'). However, it does not name an alternative tool for the excluded case, so it stops short of full alternative guidance.

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

get_card_pricesGet card price ladderA

Read-onlyIdempotent

Inspect

Use this when the user wants the full current value of a specific card: ungraded prices by condition (NM/LP/MP/HP) and graded prices for every company and grade on record (PSA, CGC, BGS, SGC, TAG). Requires a card id from search_cards. Prices are USD market values from real sold listings, refreshed daily. Do not use to search by name.

ParametersJSON Schema

Name	Required	Description	Default
`card_id`	Yes	Catalog card id from search_cards, e.g. "swsh7-215" or "pricecharting-1821843".

Output Schema

ParametersJSON Schema

Name	Required	Description
`raw`	Yes
`card`	Yes
`links`	Yes
`graded`	Yes
`summary`	Yes
`variant`	Yes	The printing the raw and graded rungs refer to (e.g. "holofoil", "1st edition"). Other printings are listed under other_variants.
`currency`	Yes
`raw_note`	Yes	Set when the raw condition ladder is out of order (thin data): treat raw prices as low confidence.
`captured_on`	Yes	Date of the latest price capture (UTC)
`other_variants`	Yes	Other printings of the same card id (reverse holo, 1st edition…) with their own prices. Never mix these with the main ladder.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds non-redundant context: prices are USD market values from real sold listings and refreshed daily, and the output covers ungraded and graded tiers. No contradiction with annotations.

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

Conciseness5/5

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

Four short sentences with the usage instruction front-loaded, followed by prerequisite, data source, and exclusion. No filler or repetition.

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 a single well-documented parameter, an output schema, and annotations covering safety, the description supplies the remaining operational context: when to use, prerequisite, data provenance, and an exclusion. Nothing needed for correct invocation is missing.

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% and the schema description already explains card_id and provides examples ('swsh7-215'). The description repeats the search_cards prerequisite, adding no new semantic information 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?

States a specific verb and resource: 'full current value of a specific card' and enumerates exact output categories (ungraded NM/LP/MP/HP and graded PSA/CGC/BGS/SGC/TAG). The closing instruction 'Do not use to search by name' distinguishes it from search_cards, and the title reinforces the resource. This is more specific than a generic price tool.

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?

Opens with 'Use this when the user wants the full current value of a specific card,' explicitly tying to a user need. It states the prerequisite ('Requires a card id from search_cards') and gives an explicit when-not ('Do not use to search by name'), effectively routing name-based lookups to search_cards. It doesn't name alternatives like get_price_history, but the when/when-not coverage is strong.

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

get_price_historyGet price historyA

Read-onlyIdempotent

Inspect

Use this when the user asks how a card's price has changed over weeks or months, or wants a trend for the raw or a PSA-graded series. Returns dated USD market values for the last 7 to 180 days. Requires a card id from search_cards. Do not use for forecasts.

ParametersJSON Schema

Name	Required	Description
`days`	No
`grade`	No	PSA grade for a graded series, e.g. "10" or "9". Omit for the raw (ungraded) series.
`card_id`	Yes	Catalog card id from search_cards.

Output Schema

ParametersJSON Schema

Name	Required	Description
`days`	Yes
`name`	Yes
`links`	Yes
`points`	Yes	Oldest first. Graded series only contain days with sales; gaps are normal.
`series`	Yes	"raw" or "PSA <grade>"
`source`	Yes
`card_id`	Yes
`variant`	Yes	The printing the series follows (e.g. "holofoil"); other printings are separate markets and are never mixed in.
`coverage`	Yes	How many of the requested days have a capture, and how to read repeated or sparse values.
`currency`	Yes
`last_usd`	Yes
`first_usd`	Yes
`change_pct`	Yes	First-to-last change; null when change_note is set because a single step carries it.
`change_note`	Yes	Set when one step between consecutive captures accounts for the change: usually a data correction, not a market move. change_pct is null in that case.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context: the 7-to-180-day date range, USD values, and raw vs PSA-graded series, which are not visible in 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.

Conciseness5/5

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

Four short sentences, each earning its place: trigger condition, output scope, prerequisite, and explicit non-use. The most important usage guidance is front-loaded.

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

Completeness4/5

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

The description covers purpose, time range, grade options, prerequisite, and exclusion. With an output schema present and annotations covering safety, nothing critical is missing for invoking the tool correctly, though it could name get_card_prices as the alternative for current spot prices.

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 card_id and grade, and the description reinforces both: card_id must come from search_cards and grade is for the PSA-graded series with raw as the alternative. The days parameter is not named explicitly, but the '7 to 180 days' phrase maps directly to it, adding context beyond the 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 opens with a precise trigger ('how a card's price has changed over weeks or months') and states the deliverable: dated USD market values for a 7-to-180-day window. It clearly distinguishes this history tool from siblings like get_card_prices by emphasizing trend and raw/PSA-graded series.

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 explicitly says when to use the tool and includes a firm exclusion ('Do not use for forecasts'). It also states the prerequisite card id must come from search_cards. It does not name a specific sibling alternative for current pricing, but the temporal language makes the intended use clear.

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

get_set_cardsCards in a set with pricesA

Read-onlyIdempotent

Inspect

Use this when the user wants the most valuable cards in a specific set or a priced checklist of a set. Requires a set id from list_sets. Returns raw and PSA 10 USD prices per card. Do not use for a single named card; use search_cards instead.

ParametersJSON Schema

Name	Required	Description	Default
`game`	Yes
`sort`	No	"value" = most valuable first; "number" = checklist order.	value
`limit`	No
`set_id`	Yes	Expansion id from list_sets.

Output Schema

ParametersJSON Schema

Name	Required	Description
`game`	Yes
`cards`	Yes
`count`	Yes
`set_id`	Yes
`set_name`	Yes
`total_cards`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover safety with readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context by specifying that the tool requires a set id from list_sets and returns both raw and PSA 10 USD prices per card, which goes beyond the structured annotations.

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 with no filler: use case, prerequisite, output summary, and routing rule. The primary guidance 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.

Completeness5/5

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

The description covers when to use the tool, the prerequisite set id, the output content, and the main alternative. Given the annotations and output schema, an agent has enough context to select and invoke this tool correctly.

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 documents set_id and sort, and the description reinforces set_id provenance and clarifies sort semantics via 'most valuable' and 'checklist order'. It does not add detail for game or limit, but those are reasonably self-explanatory enums and range constraints, and schema coverage is 50%.

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 use case: retrieving the most valuable cards in a specific set or a priced checklist of a set. It names the resource and explicitly distinguishes itself from search_cards for single-card queries, making its purpose clear and separable 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?

It gives an explicit trigger condition ('when the user wants the most valuable cards in a specific set or a priced checklist'), a required prerequisite ('Requires a set id from list_sets'), and a clear when-not-to-use rule with an alternative ('Do not use for a single named card; use search_cards instead').

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

grading_roiIs this card worth grading?A

Read-onlyIdempotent

Inspect

Use this when the user asks whether a card is worth grading, submitting to PSA/CGC/BGS/SGC/TAG, or what a PSA 10 adds. Returns raw vs PSA 9 vs PSA 10 market prices, the gem premium, net profit after grading fees per outcome, expected value by gem probability, the break-even gem rate, which company pays most, and a plain-language verdict. Requires a card id from search_cards. It does not assess the condition of the user's copy.

ParametersJSON Schema

Name	Required	Description	Default
`card_id`	Yes	Catalog card id from search_cards.
`grading_fee_usd`	No	Grading fee to assume. Defaults to a $25 economy tier; the table also shows $50 and $150.

Output Schema

ParametersJSON Schema

Name	Required	Description
`card`	Yes
`links`	Yes
`verdict`	Yes
`currency`	Yes
`psa9_usd`	Yes
`psa10_usd`	Yes
`captured_on`	Yes
`net_after_fee`	Yes
`expected_value`	Yes
`raw_market_usd`	Yes
`assumed_fee_usd`	Yes
`gem_premium_multiple`	Yes	PSA 10 price ÷ raw price
`top_grade_by_company`	Yes
`break_even_gem_probability`	Yes	Chance of a PSA 10 needed to break even at the assumed fee; null when grading never breaks even

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already provide readOnly/idempotent/destructive hints. The description adds a behavioral boundary ('does not assess condition') and clarifies the input dependency, which is useful. It doesn't over-explain since annotations cover safety.

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 concise and front-loaded with the trigger phrase. It lists outputs in a single sentence, which is informative without being bloated. Could be slightly tighter but each sentence carries weight.

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 analytical tool with two parameters and an output schema, the description provides all essential context: when to invoke, what it returns, prerequisite, and a key limitation. Nothing an agent needs to call it correctly is missing.

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% and both parameters are fully described. The tool description repeats the 'card id from search_cards' requirement, adding no new parameter semantics. 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 opens with a specific trigger ('when the user asks whether a card is worth grading...') and names the submission companies. It clearly distinguishes itself by noting it does not assess condition of the user's copy, separating it from condition-appraisal tools.

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?

Gives explicit when-to-use context: when the user asks about grading a specific card or PSA 10 premium. It states a prerequisite (requires a card id from search_cards) and an exclusion (does not assess condition). However, it doesn't name sibling alternatives like best_cards_to_grade for multi-card comparisons.

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

liquid_moversLiquid movers (rising cards that actually sell)A

Read-onlyIdempotent

Inspect

Use this when the user wants cards that are both rising in price and easy to sell: recent gainers filtered to cards with at least 25 recorded sales a year and a raw price of at least $5, across all games and sports. Better than trending_cards for flipping or selling decisions. Do not use for a single named card.

ParametersJSON Schema

Name	Required	Description
`game`	No	Restrict to one game or sport; omit for all.
`limit`	No
`include_unknown_volume`	No	Also include cards whose yearly sales count is not tracked (mostly Pokémon from the Scrydex source). Off by default so every result has a verifiable sales figure.

Output Schema

ParametersJSON Schema

Name	Required	Description
`as_of`	Yes	When this ranking was computed (ISO 8601)
`cards`	Yes
`count`	Yes
`criteria`	Yes
`volume_verified`	Yes	False when the list had to include cards whose yearly sales count is not tracked (Pokémon and other Scrydex-sourced games have no volume data).
`excluded_unstable`	Yes	Candidates dropped because their own 40-day raw series did not hold together.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already mark it read-only and idempotent, so the safety profile is covered. The description adds behavioral detail about the filtering logic (recent gainers, minimum sales and price, all games by default) that goes beyond the annotations. It does not mention how 'recent' is defined, but this is minor given the output schema.

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, no fluff. The use case is front-loaded, followed by criteria and alternatives. 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?

For a read-only tool with an output schema and annotations covering safety, the description is largely complete: it states the use case, criteria, default scope, and the sibling alternative. It omits sorting order or exact definition of 'recent gainers', but these are likely reflected in the output schema or are minor for correct invocation.

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 67% (game and include_unknown_volume are described). The description adds context that the default is 'across all games and sports' and implies the sales filter relates to include_unknown_volume being off, but it does not clarify the limit parameter beyond what the schema provides. It adds some value but not substantial.

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 purpose: returning cards that are both rising in price and easy to sell, with concrete filters (at least 25 sales/year, price >= $5). It also differentiates from sibling trending_cards by explicitly naming it, so an agent can distinguish the tools.

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?

It gives explicit when-to-use guidance: 'Better than trending_cards for flipping or selling decisions' and an exclusion: 'Do not use for a single named card.' This clearly routes to or away from this tool.

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

list_setsList sets / expansionsA

Read-onlyIdempotent

Inspect

Use this to find the set id for a game or sport (e.g. "Evolving Skies", "2019 Panini Prizm") before calling get_set_cards, or when the user asks which sets exist. Newest first. Do not use to price a single card.

ParametersJSON Schema

Name	Required	Description
`game`	Yes
`limit`	No
`query`	No	Optional substring to filter set names, e.g. "evolving" or "2019 prizm".

Output Schema

ParametersJSON Schema

Name	Required	Description
`game`	Yes
`sets`	Yes
`count`	Yes
`links`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: results are ordered 'newest first', and the tool is a lookup step for set ids. It doesn't mention pagination or response shape, but the output schema exists and the annotations carry the safety burden, so this is solid.

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, all information-dense. The primary use case is front-loaded, the ordering behavior is stated, and the exclusion is a single short sentence. No filler or repetition of schema details.

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 read-only list tool with an output schema, the description covers the key context: when to call it, what it returns (set ids), ordering, and what it is not for. It doesn't mention pagination or how to handle large result sets, but the limit parameter and output schema cover most of what an agent needs.

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 only 33% (only 'query' has a description), so the description must compensate. It does: it explains the purpose of the 'game' parameter via examples and clarifies that the tool returns set ids. It doesn't detail 'limit' semantics, but the schema already has a default and min/max, so the marginal gap is small.

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 ('find the set id'), a clear resource (sets/expansions), and gives concrete examples ('Evolving Skies', '2019 Panini Prizm'). It also explicitly distinguishes itself from get_set_cards and search_cards by naming the intended use case, so an agent can tell it apart from siblings without opening the schema.

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 explicitly says when to use it ('before calling get_set_cards, or when the user asks which sets exist') and when not to use it ('Do not use to price a single card'). This is strong routing guidance that names the alternative behavior and the exclusion condition.

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

search_cardsSearch card pricesA

Read-onlyIdempotent

Inspect

Use this first when the user names a trading card and wants its value, price, or whether to grade it. Searches 1.5M+ Pokémon, Magic, Yu-Gi-Oh!, One Piece, Lorcana, sports (baseball, basketball, football, hockey, soccer, wrestling, UFC and more) and entertainment cards by name, set, number and year, returning ungraded and PSA 10 market prices in USD from real sold listings. Returns card ids for get_card_prices, grading_roi and get_price_history. Do not use for sealed product, for cards you already have an id for, or for price prediction.

ParametersJSON Schema

Name	Required	Description
`game`	No	Restrict to one game or sport. Omit when unsure.
`limit`	No
`query`	Yes	Card name, optionally with set, number or year. Examples: "Umbreon VMAX Evolving Skies", "1986 Fleer Jordan", "Charizard base set 4/102".
`set_id`	No	Expansion id from list_sets, to search inside one set.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`cards`	Yes
`count`	Yes
`query`	Yes
`matched_on`	Yes	The search term that produced the results

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish this as a safe, read-only, idempotent operation. The description adds useful behavioral detail beyond that: it searches a large multi-game database, returns real sold-listing based prices in USD for ungraded and PSA 10 states, and outputs card ids for other tools. It does not mention pagination or result limits, but the schema and output schema cover those aspects.

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 three tightly packed sentences with no filler: primary use case, search scope and return values, then explicit non-uses. The critical routing instruction is front-loaded, so an agent learns its purpose and boundaries immediately.

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 search tool with an output schema and safe read-only annotations, this description is complete: it covers scope, supported categories, output semantics, downstream consumers, and exclusion cases. An agent can correctly select and invoke the tool without needing additional context.

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 75%, with query and set_id already documented, and the description's phrase 'by name, set, number and year' largely echoes the query parameter examples. It adds no meaningful guidance for game, limit, or set_id beyond what the schema provides, so the baseline 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 states a specific verb ('Searches') and resource ('1.5M+ Pokémon, Magic, Yu-Gi-Oh!, One Piece, Lorcana, sports and entertainment cards'), and clearly distinguishes this tool from siblings by saying to use it first when a user names a card and wants its value, price, or grading advice. It also says what it returns (ungraded and PSA 10 prices, card ids) and what it is not for.

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 gives explicit when-to-use guidance ('Use this first when the user names a trading card and wants its value, price, or whether to grade it') and explicit exclusions ('Do not use for sealed product, for cards you already have an id for, or for price prediction'). It also names downstream tools that consume its returned card ids, which helps an agent choose the right sequence.

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

trending_cardsTrending cards (30-day price movers)A

Read-onlyIdempotent

Inspect

Use this when the user asks which cards are rising, hot, spiking, crashing or trending, in one game or across all games. Returns the biggest 30-day gainers (or drops) with the percentage change, measured on the PSA 10 price where the card has one and on the raw price otherwise; moves over 300% are excluded as bad data. Do not use for a single named card or for long-term history.

ParametersJSON Schema

Name	Required	Description	Default
`game`	No	Restrict to one game or sport; omit for all.
`limit`	No
`direction`	No	"up" = biggest gainers, "down" = biggest drops.	up
`min_market_usd`	No	Ignore cards whose raw price is below this.

Output Schema

ParametersJSON Schema

Name	Required	Description
`game`	Yes
`cards`	Yes
`count`	Yes
`criteria`	Yes
`direction`	Yes
`window_days`	Yes
`excluded_unstable`	Yes	Candidates dropped because their own 40-day series did not hold together (too few captures, a baseline that swings >2×, a >6× range, or a one-capture jump).

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial behavioral detail beyond the readOnly/idempotent annotations: the 30-day window, PSA 10 versus raw price fallback, and the exclusion of moves over 300% as bad data. These are non-obvious quirks an agent must know before trusting the results.

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 the primary use case, then data-source detail, then exclusions. No filler or redundancy; every sentence adds actionable information.

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 listing tool with optional filters and an output schema, the description covers all essential aspects: when to use, what is returned, how prices are calculated, exclusions, and what not to use it for. Nothing important is missing.

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 high (75%), so the description does not need to re-explain parameters. It does reinforce that game may be omitted for cross-game queries, but it adds little beyond the schema; parameters like limit and direction are already self-documenting.

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?

Description states a specific action ('Returns the biggest 30-day gainers or drops'), names the resource ('trending cards'), and gives clear trigger phrasing ('rising, hot, spiking, crashing or trending'). It also excludes single-card and long-term-history use cases, which distinguishes it from get_card_prices and get_price_history.

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?

Explicitly says 'Use this when the user asks which cards are rising...' and 'Do not use for a single named card or for long-term history,' giving both positive and negative usage signals. It does not explicitly name which sibling tool to use as an alternative, but the intent is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 19, 2026

Changedget_price_history2 fields changed

changedOutput schema / properties / change_note / description

Previous value: -"Set when one step between consecutive captures accounts for the change: usually a data correction, not a market move. Do not quote change_pct as a trend when this is set."New value: +"Set when one step between consecutive captures accounts for the change: usually a data correction, not a market move. change_pct is null in that case."

addedOutput schema / properties / change_pct / description

Added value: +"First-to-last change; null when change_note is set because a single step carries it."

2 tool updatesSep 19, 2026

Changedget_price_history2 fields changed

addedOutput schema / properties / change_note

Added value: +{
+  "description": "Set when one step between consecutive captures accounts for the change: usually a data correction, not a market move. Do not quote change_pct as a trend when this is set.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "card_id",
-  "name",
-  "series",
-  "variant",
-  "days",
-  "coverage",
-  "currency",
-  "points",
-  "first_usd",
-  "last_usd",
-  "change_pct",
-  "source",
-  "links"
-]New value: +[
+  "card_id",
+  "name",
+  "series",
+  "variant",
+  "days",
+  "coverage",
+  "currency",
+  "points",
+  "first_usd",
+  "last_usd",
+  "change_pct",
+  "change_note",
+  "source",
+  "links"
+]

Changedliquid_movers2 fields changed

addedOutput schema / properties / volume_verified

Added value: +{
+  "description": "False when the list had to include cards whose yearly sales count is not tracked (Pokémon and other Scrydex-sourced games have no volume data).",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "as_of",
-  "criteria",
-  "count",
-  "excluded_unstable",
-  "cards"
-]New value: +[
+  "as_of",
+  "criteria",
+  "count",
+  "volume_verified",
+  "excluded_unstable",
+  "cards"
+]

2 tool updatesSep 19, 2026

Changedliquid_movers2 fields changed

addedOutput schema / properties / excluded_unstable

Added value: +{
+  "description": "Candidates dropped because their own 40-day raw series did not hold together.",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "as_of",
-  "criteria",
-  "count",
-  "cards"
-]New value: +[
+  "as_of",
+  "criteria",
+  "count",
+  "excluded_unstable",
+  "cards"
+]

Changedtrending_cards3 fields changed

addedOutput schema / properties / criteria
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / excluded_unstable

Added value: +{
+  "description": "Candidates dropped because their own 40-day series did not hold together (too few captures, a baseline that swings >2×, a >6× range, or a one-capture jump).",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "window_days",
-  "direction",
-  "game",
-  "count",
-  "cards"
-]New value: +[
+  "window_days",
+  "direction",
+  "game",
+  "count",
+  "excluded_unstable",
+  "criteria",
+  "cards"
+]

3 tool updatesSep 19, 2026

Changedget_card_prices4 fields changed

addedOutput schema / properties / other_variants

Added value: +{
+  "description": "Other printings of the same card id (reverse holo, 1st edition…) with their own prices. Never mix these with the main ladder.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "graded": {
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "company": {
+              "type": "string"
+            },
+            "grade": {
+              "type": "string"
+            },
+            "market_usd": {
+              "type": [
+                "number",
+                "null"
+              ]
+            }
+          },
+          "required": [
+            "company",
+            "grade",
+            "market_usd"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "raw": {
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "condition": {
+              "type": "string"
+            },
+            "high_usd": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "low_usd": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "market_usd": {
+              "type": [
+                "number",
+                "null"
+              ]
+            }
+          },
+          "required": [
+            "condition",
+            "market_usd",
+            "low_usd",
+            "high_usd"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "variant": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "variant",
+      "raw",
+      "graded"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / raw_note

Added value: +{
+  "description": "Set when the raw condition ladder is out of order (thin data): treat raw prices as low confidence.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / variant

Added value: +{
+  "description": "The printing the raw and graded rungs refer to (e.g. \"holofoil\", \"1st edition\"). Other printings are listed under other_variants.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "card",
-  "currency",
-  "captured_on",
-  "raw",
-  "graded",
-  "summary",
-  "links"
-]New value: +[
+  "card",
+  "currency",
+  "captured_on",
+  "variant",
+  "raw_note",
+  "raw",
+  "graded",
+  "other_variants",
+  "summary",
+  "links"
+]

Changedget_price_history3 fields changed

addedOutput schema / properties / coverage

Added value: +{
+  "additionalProperties": false,
+  "description": "How many of the requested days have a capture, and how to read repeated or sparse values.",
+  "properties": {
+    "days_with_data": {
+      "type": "integer"
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "days_with_data",
+    "note"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / variant

Added value: +{
+  "description": "The printing the series follows (e.g. \"holofoil\"); other printings are separate markets and are never mixed in.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "card_id",
-  "name",
-  "series",
-  "days",
-  "currency",
-  "points",
-  "first_usd",
-  "last_usd",
-  "change_pct",
-  "source",
-  "links"
-]New value: +[
+  "card_id",
+  "name",
+  "series",
+  "variant",
+  "days",
+  "coverage",
+  "currency",
+  "points",
+  "first_usd",
+  "last_usd",
+  "change_pct",
+  "source",
+  "links"
+]

Changedliquid_movers2 fields changed

addedInput schema / properties / include_unknown_volume

Added value: +{
+  "default": false,
+  "description": "Also include cards whose yearly sales count is not tracked (mostly Pokémon from the Scrydex source). Off by default so every result has a verifiable sales figure.",
+  "type": "boolean"
+}

addedOutput schema / properties / cards / items / properties / sales_per_year / description

Added value: +"Recorded sales in the last year; null only when include_unknown_volume is on and the source does not track volume."

9 tool updatesSep 11, 2026
- First observedbest_cards_to_grade
- First observedget_card_prices
- First observedget_price_history
- First observedget_set_cards
- First observedgrading_roi
- First observedliquid_movers
- First observedlist_sets
- First observedsearch_cards
- First observedtrending_cards

Related MCP Connectors

Gembook — PSA Vintage Pokémon Prices & Pop A
xyz.gembook
Neutral prices + PSA population for PSA-graded vintage Pokémon (WotC 1999–2003). Read-only.
Finance Research & Data
32
POKEKA — Pokémon Card Prices A
xyz.pokeka
Real sold prices, history & PSA population for graded Pokémon cards (EN/JP/CN). Knows nicknames.
Games & Gamification E-commerce & Retail
141
tickermint A
io.github.seankarltonlee
Trading card prices: daily TCGplayer market, history since 2024, sold comps, PSA 10 floors. 6 games.
Finance Games & Gamification E-commerce & Retail
111
SpellBook Finance A
com.spellbook-finance
Magic: The Gathering card prices, movers, arbitrage, sealed box EV, and seller inventory tools.
Finance Games & Gamification E-commerce & Retail
1121

Related MCP Servers

Sports Trading Card Agent
Sports Finance Research & Data
rjexile
A
license
A
quality
D
maintenance
Real-time sports card pricing, market analysis, arbitrage detection, grading ROI, investment advice, and player stats (NBA/NFL/MLB). 9 tools for AI agents helping collectors and investors.
Updated 6 months ago (2026-03-24 22:25 UTC)
9
2
MIT
PokéWallet MCP
w3bKodr
A
license
B
quality
C
maintenance
Vision-guided Pokémon TCG card identification server that matches exact printings using visual evidence and marketplace data.
Updated 2 months ago (2026-07-21 03:41 UTC)
40
1
MIT
litvm-tcg-oracle
Blockchain Cryptocurrency AI & Machine Learning
sailorpepe
A
license
A
quality
B
maintenance
On-chain TCG price oracle for the LitecoinVM ecosystem. 6 tools: search 433K+ trading cards, 60-day price history, Merkle proof verification on LiteForge (Chain 4441), Monte Carlo simulation, and AI card grading via Qwen 2.5 VL.
Updated 3 days ago (2026-09-28 13:20 UTC)
7
Business Source 1.1
litvm-onboard
Blockchain Web3 & Decentralized Tech
sailorpepe
F
license
Not graded
quality
B
maintenance
Enables proving trading-card prices against the LitecoinVM chain with six read-only tools, no wallet, keys, or auth required.
Updated 16 days ago (2026-09-15 14:59 UTC)
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources