Skip to main content
Glama
Sign In

CARDZ MCP

by io.github.cardzgame
OverviewDiscussionsAdmin

TCG market rankings

get_market
Read-onlyIdempotent

Use this when the user asks about the top-ranked cards by market cap, wants to know which cards are most valuable by the CARDZ index, or requests a leaderboard for Pokémon or One Piece graded cards. Returns the published ranking with PSA 10 prices, populations, market caps, and the effective date of the data. Market cap = PSA 10 reference price × verified PSA 10 population. This index does not represent the full trading-card market.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_market"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoLanguage for display labels in the response. Does not filter by card language; use tcg to narrow by game. Printing language is always returned in the result.
limitNoHow many top-ranked cards to return. Default 10, max 20.
scopeNo'pokemon', 'one-piece', or 'all' (combined index). Default: all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / lang / description
      Previous value: -"Display language; printing language is returned separately."New value: +"Language for display labels in the response. Does not filter by card language; use tcg to narrow by game. Printing language is always returned in the result."
    • changedInput schema / properties / limit / description
      Previous value: -"Number of ranked cards; default 10."New value: +"How many top-ranked cards to return. Default 10, max 20."
    • changedInput schema / properties / scope / description
      Previous value: -"Ranking scope; default all."New value: +"'pokemon', 'one-piece', or 'all' (combined index). Default: all."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds real value on top: it discloses the fields returned (PSA 10 prices, populations, market caps, effective date), the market-cap formula, and the caveat that the index is not the whole trading-card market. Missing only edge behavior such as what happens when ranking data is unavailable or how fresh the data is beyond the effective-date field.

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 sentences, front-loaded with the use case, then returns, then the formula, then the caveat — every sentence carries information an agent or user needs. No redundancy or filler.

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 no output schema and no required parameters, the description carries the burden of explaining results and does so by enumerating returned fields and the index definition. Combined with a fully documented input schema, an agent has everything needed 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with lang, limit, and scope all documented including defaults, enums, and the lang-vs-filtering nuance. The description only indirectly gestures at scope via 'Pokémon or One Piece' and adds no syntax or default information beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource — returning the published top-ranked card leaderboard by market cap / CARDZ index — and scopes it to Pokémon or One Piece graded cards. It is clearly distinguishable from get_card and search_cards, which are per-card lookups, without needing either schema.

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 trigger conditions: when the user asks about top-ranked cards by market cap, most valuable by the CARDZ index, or a leaderboard for a game. It does not explicitly name the sibling tools to use instead when the user wants an individual card, so the routing guidance is strong but not complete.

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

All CARDZ MCP toolsInspect
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.

Resources