Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

psa_price_guide_sets

Search PSA Price Guide set names by keyword to find matching sets and retrieve category and set identifiers for set-level lookups; it does not search card or player names.

Instructions

Search PSA Price Guide set names. Searches PSA Price Guide by set name (for example "1974 topps" or "super bowl") using PSA's own browse-by-category pages. It matches set names only: it does not search card or player names, and results carry no card items. Use psa-price-guide-search for card and player search while PSA's own search is available. Every word of the query must start a word of the set name; exact and leading matches rank first. Each result's category_path, set_path and set_id are the inputs to psa-price-guide-set. Set lists are cached for 12 hours, so a first call after a cold start can take longer. If a category's set list cannot be loaded, the other categories still answer and unavailable_categories names the missing ones.

Input Schema

NameRequiredDescriptionDefault
pageNoOne-based result page, default 1
queryYesSet-name search term, e.g. 1974 topps
page_sizeNoSets per page, default 50, max 100
category_pathNoRestrict to one category. Allowed values: baseball-card-values, basketball-card-values, boxing-card-values, football-card-values, golf-card-values, hockey-card-values, soccer-card-values, non-sports-tcg-card-values, racing-card-values, sports-ticket-values, tennis-card-values, unopened-pack-values, presidential-autograph-values, sports-autograph-values, game-used-bat-values, graded-baseball-values. Default: every category.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the match rule (every query word must start a word of the set name, exact/leading matches ranked first), a 12-hour cache with possible slow cold-start calls, and graceful partial failure where unavailable_categories names missing categories. These are non-obvious operational traits an agent needs before calling.

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?

Dense but well front-loaded: scope first, then alternatives, then matching, then operational caveats. The opening two sentences repeat "Search PSA Price Guide by set name," which is the only real redundancy in an otherwise efficient block.

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?

No output schema exists, and the description compensates by explaining that results carry set identifiers only (no card items) and that category_path/set_path/set_id are the handoff to the detail tool, plus how failures surface. An agent has enough to call it correctly and to know what it will and will not get back.

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 coverage is 100%, so page, page_size and the category enum are already documented. The description adds real value on the query parameter's matching semantics and on category restriction ("Default: every category" is in schema, but the fallback behavior across categories is in the description). Pagination behavior is left entirely to the schema, which caps this at 4.

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 ("Search PSA Price Guide set names") and immediately bounds the scope: set names only, not card or player names, and results carry no card items. It names the sibling psa-price-guide-search for the other case, so an agent can distinguish the two without opening schemas.

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?

Explicit routing: use psa-price-guide-search for card and player search, and feed each result's category_path, set_path and set_id into psa-price-guide-set. This is a clear when-to-use, when-not-to-use, and next-step chain rather than implied guidance.

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