Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

fanaticscollect_sold_items

Search completed Fanatics Collect sales by title, category, price, grading, year, and date to find historical sold prices and narrow older results.

Instructions

Search Fanatics Collect sold items. Searches Fanatics Collect's sales-history archive -- every completed sale across every marketplace, not just what the live search index currently surfaces. A separate product from Search, reached from the "View all sold items" link on every marketplace search page. purchase_price is what the buyer paid in US dollars: for WEEKLY and PREMIER auction sales it includes the buyer's premium, so it is higher than the listing's final bid; for FIXED sales it equals the asking price. Only the first 1,000 results of a query can be paged through; later pages come back empty and are not charged, so narrow the query with filters to reach older sales. Costs 3 credits per successful call. See GetCategories for the accepted category, grading-service, eye-appeal-grade, and sort values.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number, default 1
sortNoResult order. Default sold_date_desc.
titleNoFree-text search across item title
categoryNoItem category
max_yearNoMaximum card/item year, inclusive
min_yearNoMinimum card/item year, inclusive
per_pageNoResults per page, default 20, max 50; larger values are lowered to 50
max_priceNoMaximum sold price, inclusive
min_priceNoMinimum sold price, inclusive
grading_serviceNoGrading/authentication service, including ungraded for raw items
eye_appeal_gradeNoEye-appeal grade

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.18
    • changedInput schema / properties / per_page / description
      Previous value: -"Results per page, default 20, max 100"New value: +"Results per page, default 20, max 50; larger values are lowered to 50"
  2. Addedv1.17.5

TDQS

A4.3/5.0
Behavior5/5

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

With zero annotations, the description still discloses the critical behavioral traits: buyer's-premium inclusion in purchase_price for WEEKLY/PREMIER vs. asking price for FIXED, the 1,000-result paging cap with uncharged empty pages, and a 3-credit cost per successful call. This is exactly the domain-specific context structured fields cannot carry.

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?

Front-loaded with purpose and scope, then layered with pricing, paging cap, cost, and cross-reference. Dense but every sentence carries useful information; the only slight redundancy is the GetCategories pointer given enums are already inline.

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 an 11-param tool with no annotations and no output schema, the description covers the notable behavioral pitfalls (credit cost, paging cap, price semantics). It stops short of describing other return fields beyond purchase_price, which would help given no output schema exists.

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 the enums are fully inline, so the schema already documents all 11 parameters. The description adds only a pointer to GetCategories for accepted category/grading/eye-appeal/sort values, which is redundant with the inline enums. 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 ('Search Fanatics Collect sold items') and immediately scopes it to the sales-history archive, distinguishing it from the live search index. It also names the separate product it is not ('A separate product from Search'), so an agent can differentiate it from fanaticscollect_search 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains when this tool is appropriate (historical completed sales, not live listings) and gives actionable guidance to narrow queries with filters because only the first 1,000 results page. It routes away from the live Search product, though it stops short of an explicit 'use Search instead for live items' directive.

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