Skip to main content
Glama

Recent eBay sold comps

get_sold_comps
Read-onlyIdempotent

The most recent real eBay sales (sold comps) for a search query (brand, model or pattern, a few specific words), with the count, median and quartiles. Use when the user wants to see what actually sold and for how much. It searches the signed-in user's own eBay marketplace (eBay UK in GBP for a UK seller), eBay US in USD when nobody is signed in, or the site given in marketplace; the result names the site (marketplace) and the currency (currency). One search runs: the query as typed (a retail price with "$" in it is left out), with model or part_number appended only when the query does not already name it; with no query, brand plus model, or brand plus part_number. Sales whose title shows a different item are left out of the count, median and quartiles: comps.matched is how many were kept, comps.dropped how many were left out, and comps.relevanceChecked is false when that check could not run (every sale is then kept). comps.countIsLowerBound true means eBay returned a full page, so the count is that many or more. include words must all appear in a sale's title (and are added to the search when missing); a title with any exclude word is left out; both match whole words in any case and are named in the answer. prefer words leave nothing out: sales whose title has every one are listed first (preferred true) and summarized in comps.preferred, while count and summary still cover every matching sale. Each listed sale has condition, saleType, bids, shipping and location, each null when not known (a sale stored before 22 October 2026 gives condition only as new or used). exclude_items leaves out sales by eBay item number (each listed sale's itemId), before every other filter; comps.removedByItems counts them. limit sets how many recent sales are listed (default 8, up to 50).

Input Schema

NameRequiredDescriptionDefault
brandNoThe brand or maker exactly as printed on the item, its tag or its label (for example "Simrad", "Pyrex", "Levi's"). Fill it from what you read on the item or the user's photo; leave it empty rather than guess.
limitNoHow many recent sales to list in comps.recent, 1 to 50. Leave it empty for 8. The count and summary always cover every matching sale, not just the ones listed.
modelNoThe model or product-line name as printed on the item or its box (for example "iPhone 12", "QuietComfort 35", "Odyssey G5", "501"). It is passed to the identification as a hint and added to the search when no word of it is already there; it never replaces the search. Put a manufacturer part number in part_number. Leave it empty rather than guess.
queryNo3 to 6 specific words, brand and model first, like an eBay search.
preferNoUp to 5 soft words (each up to 40 characters), for example ["rattan"]. No sale is left out and the search is not changed: sales whose title contains every one as a whole word, any case, are listed first in comps.recent (marked preferred) and summarized apart in comps.preferred. Use prefer when sellers may word the same item differently; use include to keep only titles with the word.
excludeNoUp to 5 words (each up to 40 characters); a sale whose title contains any of them as a whole word, any case, is left out, for example ["jade", "cabinet"].
includeNoUp to 5 words (each up to 40 characters) every sale title must contain as a whole word, any case, for example ["oak", "carved"]. They are also added to the search when the query does not already hold them.
marketplaceNoThe eBay site to search: EBAY_US (eBay US, prices in USD) or EBAY_GB (eBay UK, prices in GBP). Leave it empty to use the signed-in user's own marketplace, or eBay US when nobody is signed in. Set it only when the user asks about a market other than their own. A photo scan always uses the account's own marketplace.
part_numberNoThe manufacturer part number printed on the label or rating plate (for example "000-16294-001", "DCD771C2", "CUH-ZCT2U"), copied character for character. Not a size, voltage, year, SKU, ASIN, LPN or barcode. In price_item it is a hint to the identification only and is not added to the search (a part number required in every listing title leaves too few sales); in get_sold_comps it is appended to the query when the query lacks it. Leave it empty rather than guess.
exclude_itemsNoUp to 20 eBay item numbers (9 to 15 digits) to leave out of the count, summary and list, for example the user's own earlier sale of the same item, which is not independent evidence. Each listed sale's itemId is its eBay item number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / exclude_items
      Added value: +{
      +  "description": "Up to 20 eBay item numbers (9 to 15 digits) to leave out of the count, summary and list, for example the user's own earlier sale of the same item, which is not independent evidence. Each listed sale's itemId is its eBay item number.",
      +  "items": {
      +    "pattern": "^\\d{9,15}$",
      +    "type": "string"
      +  },
      +  "maxItems": 40,
      +  "type": "array"
      +}
    • addedInput schema / properties / prefer
      Added value: +{
      +  "description": "Up to 5 soft words (each up to 40 characters), for example [\"rattan\"]. No sale is left out and the search is not changed: sales whose title contains every one as a whole word, any case, are listed first in comps.recent (marked preferred) and summarized apart in comps.preferred. Use prefer when sellers may word the same item differently; use include to keep only titles with the word.",
      +  "items": {
      +    "maxLength": 40,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "type": "array"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / exclude
      Added value: +{
      +  "description": "Up to 5 words (each up to 40 characters); a sale whose title contains any of them as a whole word, any case, is left out, for example [\"jade\", \"cabinet\"].",
      +  "items": {
      +    "maxLength": 40,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "type": "array"
      +}
    • addedInput schema / properties / include
      Added value: +{
      +  "description": "Up to 5 words (each up to 40 characters) every sale title must contain as a whole word, any case, for example [\"oak\", \"carved\"]. They are also added to the search when the query does not already hold them.",
      +  "items": {
      +    "maxLength": 40,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "type": "array"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "How many recent sales to list in comps.recent, 1 to 50. Leave it empty for 8. The count and summary always cover every matching sale, not just the ones listed.",
      +  "maximum": 50,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / marketplace
      Added value: +{
      +  "description": "The eBay site to search: EBAY_US (eBay US, prices in USD) or EBAY_GB (eBay UK, prices in GBP). Leave it empty to use the signed-in user's own marketplace, or eBay US when nobody is signed in. Set it only when the user asks about a market other than their own. A photo scan always uses the account's own marketplace.",
      +  "enum": [
      +    "EBAY_US",
      +    "EBAY_GB"
      +  ],
      +  "type": "string"
      +}
  4. Changed4 schema fields changed
    • addedInput schema / properties / brand
      Added value: +{
      +  "description": "The brand or maker exactly as printed on the item, its tag or its label (for example \"Simrad\", \"Pyrex\", \"Levi's\"). Fill it from what you read on the item or the user's photo; leave it empty rather than guess.",
      +  "maxLength": 80,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / model
      Added value: +{
      +  "description": "The model or product-line name as printed on the item or its box (for example \"iPhone 12\", \"QuietComfort 35\", \"Odyssey G5\", \"501\"). It is passed to the identification as a hint and added to the search when no word of it is already there; it never replaces the search. Put a manufacturer part number in part_number. Leave it empty rather than guess.",
      +  "maxLength": 80,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / part_number
      Added value: +{
      +  "description": "The manufacturer part number printed on the label or rating plate (for example \"000-16294-001\", \"DCD771C2\", \"CUH-ZCT2U\"), copied character for character. Not a size, voltage, year, SKU, ASIN, LPN or barcode. In price_item it is a hint to the identification only and is not added to the search (a part number required in every listing title leaves too few sales); in get_sold_comps it is appended to the query when the query lacks it. Leave it empty rather than guess.",
      +  "maxLength": 40,
      +  "minLength": 3,
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  5. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes far beyond the annotations: it explains marketplace/currency resolution (signed-in site, EBAY_US fallback, explicit `marketplace`), that only one search runs, how relevance filtering drops mismatched titles, and how `countIsLowerBound`, `relevanceChecked` and null condition fields behave. All of this is consistent with readOnlyHint/idempotentHint/openWorldHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and use case are correctly front-loaded, but the body collapses into one dense run-on paragraph of semicolon clauses covering search construction, filtering, and null-field caveats. Every clause is substantive for a 10-parameter tool, yet the lack of any grouping or breaks makes it hard to scan under time pressure.

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 no output schema, the description carries the return-shape burden itself and does so: it documents `comps.matched`, `comps.dropped`, `comps.relevanceChecked`, `comps.countIsLowerBound`, `comps.preferred`, `comps.removedByItems`, and the per-sale fields. An agent can call this correctly without opening anything else.

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 already 100%, so the baseline is 3; the description still adds ordering and interaction semantics the schema lacks, notably that `exclude_items` is applied before every other filter and surfaces as `comps.removedByItems`, and that `prefer` never changes the search while `include` does. The `limit` default and the count-vs-listed distinction are restated rather than new.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'The most recent real eBay sales (sold comps) for a search query', and names the aggregate output (count, median, quartiles). It does not explicitly distinguish itself from `price_item` or `worth_it` in the prose (the `price_item` mention lives in the schema, not the description), so sibling differentiation is only implied.

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?

'Use when the user wants to see what actually sold and for how much' gives a clear triggering condition, and the include-vs-prefer guidance ('use prefer when sellers may word the same item differently; use include to keep only titles with the word') is genuinely actionable. It stops short of naming when to prefer a sibling like `worth_it` or `price_item` instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources