Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

tcgplayer_price_guide

Retrieve TCGplayer price guide data for an entire set, one row per card condition and printing. Page through up to 500 rows per call using a set ID from tcgplayer-sets.

Instructions

Get TCGplayer's price guide for a whole set. Returns TCGplayer's price guide for one set, one row per card, condition and printing: card id, name, collector number, rarity, condition, printing, language, low price, market price and units sold. Page through a whole set (up to 500 rows per call) instead of fetching each card; the set_id comes from tcgplayer-sets.

Input Schema

NameRequiredDescriptionDefault
limitNoPage size, 1 to 500; defaults to 100
offsetNoRows to skip; use the previous response's next_offset
set_idYesNumeric set id from tcgplayer-sets (the id field)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral load and does well: it enumerates the returned fields (prices, condition, printing, units sold) and discloses pagination limits and the source of set_id. It omits auth/rate-limit or error behavior, but as a read-only guide listing it is substantially self-disclosing.

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 core purpose, followed by return shape and then pagination/sourcing guidance. Every sentence contributes distinct information with no redundancy.

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?

No output schema exists, so the description appropriately lists the return fields and pagination behavior, and it explains where set_id originates. It is complete enough to call correctly, with only minor gaps like rate-limit or error semantics.

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 the schema already documents limit, offset, and set_id. The description adds partial value by stating the 500-row page cap and that set_id comes from tcgplayer-sets, but adds no syntax beyond the schema's own descriptions, so 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 and resource ('Get TCGplayer's price guide for a whole set') and clarifies the scope is one whole set with one row per card/condition/printing. This distinguishes it from per-card siblings like tcgplayer_product or tcgplayer_sales without needing to open a 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?

Explicitly says to 'page through a whole set (up to 500 rows per call) instead of fetching each card,' which supplies the use case and contrasts it with a per-card approach. It also routes the agent to tcgplayer-sets for set_id. It stops short of naming the exact sibling tools to avoid.

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

Deploy Server

Other Tools