Skip to main content
Glama

Pulltrader Seller Economics

by app.pulltrader

Find recent comparable sold sales for a trading card

search_card_sales

Return a capped sample of recent comparable SOLD listings for a trading card (price + sale date), plus a market snapshot (median, range, sample size). Use this when a user asks 'what is this card selling for', 'recent sales', or 'comps'. Accepts a natural-language query or a structured item. Figures are estimates from recent sales and exclude fees/taxes/shipping; this is not financial advice and does not place orders. Trading cards only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemNoStructured card fields (alternative to query): player_athlete, year_manufactured, set_name, card_number, parallel_variety, grader, grade, sport.
limitNoMaximum number of example sales to return (1–10).
queryNoNatural-language card description, e.g. '2023 Panini Prizm Victor Wembanyama #136 Silver PSA 10'. Either query or item is required.

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It transparently states that figures are 'estimates from recent sales', 'exclude fees/taxes/shipping', 'not financial advice', and 'does not place orders'. This effectively sets expectations. It could mention data source freshness, but overall it's good.

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?

The description is highly concise: four sentences covering purpose, usage, caveats, and domain. It front-loads the core function and provides necessary details without padding. Every sentence earns its place.

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?

Despite having no output schema, the description specifies the return: 'price + sale date' and 'market snapshot (median, range, sample size)'. It covers all three parameters, domain restrictions, and limitations. For a tool of this complexity, the description is complete.

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 description coverage is 100%, so baseline is 3. The description adds value by explaining that 'query' is natural-language and 'item' is structured, and that either is required. It also clarifies the 'limit' parameter's purpose. This extra context helps the agent choose between parameters.

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 clearly states it returns recent comparable sold listings and a market snapshot for a trading card. The verb 'Return' and specific resource 'recent comparable SOLD listings' make the purpose unmistakable. It distinguishes itself from siblings like 'get_card_price_history' or 'summarize_card_market' by focusing on recent comps.

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?

The description explicitly tells when to use it: 'when a user asks 'what is this card selling for', 'recent sales', or 'comps''. It also limits usage to 'Trading cards only.' While it doesn't discuss alternatives, the context signals provide sibling tools, and the description gives clear usage scenarios.

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

All Pulltrader Seller Economics toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct operation: calculating prices, comparing costs, explaining methods, identifying cards, searching sales, summarizing markets, and fetching price history. No functional overlap exists between any pair.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., calculate_required_sale_price, compare_selling_costs, explain_selling_method) with no mixed conventions or abbreviations.

Tool Count5/5

With 7 tools covering pricing, fee comparison, method explanations, card identification, sales search, market summary, and price history, the set is well-scoped for a seller economics domain—neither too sparse nor bloated.

Completeness5/5

The tool surface comprehensively covers the seller economics lifecycle: card identification, market data (recent sales, price history, summary), fee/cost comparison, target-pricing calculation, and method explanation. No obvious dead ends for the stated purpose.

Resources