Crawlora MCP

tcgplayer_search

Read-only

Search TCGplayer's trading-card and collectible catalog (Pokemon, Magic, Yu-Gi-Oh!, One Piece, Lorcana and about 70 other product lines) and return each match's product id, name, set, rarity, card number, market, lowest and median price, listing count and links, plus filter facets. Filter by product line, set, product type, rarity, card type and price range; sort by market price, lowest price, listings, sales or name. Use this to find a card or sealed product and its current price; use tcgplayer_product for full detail.

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": "tcgplayer_search"
  }
}

Input Schema

Name	Required	Description
`q`	No	Search text, up to 100 characters; optional when product_line is set
`set`	No	Set url_name from tcgplayer-sets; needs product_line
`sort`	No	Sort field; omit for relevance. Documented values: market-price, lowest-price, lowest-price-with-shipping, median-price, listings, sales, product-name.
`limit`	No	Page size, 1 to 50; defaults to 24
`order`	No	Sort direction, needs sort; default desc (asc for product-name). Documented values: asc, desc.
`offset`	No	Results to skip; offset plus limit must be 9999 or less
`rarity`	No	Exact rarity label such as Holo Rare; see facets.rarities
`card_type`	No	Exact card type label such as Pokemon; see facets.card_types
`max_price`	No	Maximum market price in US dollars
`min_price`	No	Minimum market price in US dollars
`product_line`	No	Product line url_name from tcgplayer-product-lines, for example pokemon, magic, yugioh
`product_type`	No	Exact product type label such as Cards or Booster Box; see facets.product_types

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by spelling out the result payload (product id, set, rarity, card number, market/lowest/median price, listing count, links, facets), which is the main behavioral unknown for a search tool.

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?

Three sentences, front-loaded with purpose and catalog scope, then filters/sort, then routing guidance. The first sentence carries a long list of return fields but each element is informative and nothing is redundant.

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 12 optional parameters, an output schema, and read-only/open-world annotations, the description covers what the tool does, what it returns, how to filter and sort, and where to go for detail. Nothing material is missing 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 100% across all 12 parameters, so the schema already documents filters, sort values and pagination limits. The description mirrors the same filter and sort axes but adds no syntax, default or format detail beyond what the schema states, 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?

The description opens with a specific verb and resource ('Search TCGplayer's trading-card and collectible catalog'), names the covered product lines, and enumerates the returned fields. It explicitly distinguishes itself from the sibling tcgplayer_product, so an agent can pick the right tool without opening 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?

It states the primary use case ('find a card or sealed product and its current price') and routes detailed lookups to tcgplayer_product. It does not, however, address the other close siblings such as tcgplayer_price_history, tcgplayer_listings or tcgplayer_sales, which an agent might plausibly want instead.

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

All Crawlora MCP tools Inspect

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

Need Help?