recent_salesMost recent verified sales for one card (up to 10): date, grading company + grade, price in USD, marketplace name. Sales span US, Japan-domestic and Chinese marketplaces — each sale is a real completed transaction, not a listing.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | Card id from search_card / slang_lookup. |
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| sales | No | ||
| card_id | No | ||
| sale_count | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and destructiveHint annotations, the description adds valuable behavioral context: sales are 'real completed transactions, not listings', and they span US, Japan-domestic, and Chinese marketplaces. This authenticity and scope detail helps the agent understand the tool's limitations and reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: first sentence conveys core purpose and output fields, second adds geographic scope and data authenticity. Information is front-loaded and every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers output items (up to 10, date, grading, price, marketplace), geographic scope, and data authenticity. It does not explicitly state ordering (presumably most recent first), which is a minor gap. With an output schema present, the return structure is already defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required parameter card_id. The tool description repeats the same guidance ('from search_card / slang_lookup') as the schema, adding no new meaning. At baseline, with full schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb (get/recent sales) and resource (sales for one card), includes details about output fields (date, grading, price, marketplace), and implies it retrieves recent vs historical data. It distinguishes from siblings by focusing on recent sales rather than price history or population, which are covered by card_price_history and card_pop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it provides 'most recent verified sales for one card (up to 10)', giving clear context for when to use. However, it does not explicitly mention when not to use or list alternative tools like card_price or card_price_history for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.