Ask what a thrift find sells for. Real eBay sold comps, price range and net after fees.
Scored across 5 tools
The five tools map to distinct steps: price an item (price_item), inspect raw sold sales (get_sold_comps), retrieve an async scan (get_scan_result), run fee math (worth_it), and prepare a draft listing (list_on_ebay). The only real overlap is that price_item already embeds sold comps and returns the same shape as get_scan_result, so an agent must read descriptions carefully to pick between them. Descriptions do provide explicit guidance (e.g. use price_item first for worth_it, use get_scan_result when comps were still loading), which keeps the boundary usable.
All names are consistent snake_case and mostly verb_noun (get_scan_result, get_sold_comps, list_on_ebay, price_item). The only outlier is worth_it, which is a phrase rather than a verb_object action, and price_item uses a verb that also appears as a noun elsewhere in the domain. Minor deviations, but the pattern stays predictable.
Five tools for a focused eBay pricing assistant is well-scoped: each covers a distinct part of the workflow (estimate, comps detail, async scan, fee math, draft listing). Nothing feels padded or missing at the count level, and the small surface keeps selection overhead low.
The pricing lifecycle is covered end to end: describe or photo price, drill into sold comps, re-read a saved scan, compute seller proceeds, and stage an eBay draft, with publishing intentionally deferred to the app. Gaps are minor but real — there is no way to list previously saved scans/items, update an item, or read account/marketplace state beyond what other tools return inline. Agents can work around this by passing account.scanId directly.
For a signed-in user: the finished result for a scan on their account, in the same shape as price_item, once the sold comps have landed in the background. Call it with the account.scanId a photo price returned when that result said comps were still loading (about 20 seconds later), or to re-read any saved scan.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | What the user would pay, in the scan's currency (price.currency), for a worth-it verdict. | |
| scan_id | Yes | The account.scanId from a signed-in price_item, or the saved-scan link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the asynchronous timing ('about 20 seconds later') and the fact that results land in the background, which helps an agent decide when to re-poll.
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 dense sentences with no filler, and the audience/scope qualifier ('For a signed-in user') is front-loaded. The second sentence is somewhat run-on, slightly reducing readability.
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?
Covers the async polling lifecycle, the input provenance and the return shape (by reference to price_item) despite there being no output schema. For a read-only tool with full annotations, this is close to complete, with only the explicit alternative-sibling routing left implicit.
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 coverage is 100%, so both parameters are already documented, including scan_id's provenance and the cost bounds. The description largely restates scan_id's origin ('account.scanId a photo price returned'), adding only the timing correlation, so the baseline 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?
States a specific verb and resource ('the finished result for a scan on their account') and ties the return shape to the sibling price_item. It doesn't explicitly contrast its purpose against get_sold_comps or price_item, so sibling differentiation is partial rather than explicit.
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?
Gives two concrete invocation triggers: polling with account.scanId after a photo price reported comps still loading (~20 seconds later), or re-reading a saved scan. This is clear when-to-use context, though it stops short of naming an explicit alternative or exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | 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. | |
| limit | No | 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. | |
| model | No | 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. | |
| query | No | 3 to 6 specific words, brand and model first, like an eBay search. | |
| prefer | No | 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. | |
| exclude | No | 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"]. | |
| include | No | 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. | |
| marketplace | No | 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. | |
| part_number | No | 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. | |
| exclude_items | No | 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. |
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.
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.
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.
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.
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.
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.
For a signed-in user: turns a photo scan from price_item (account.scanId) into an inventory item with a draft eBay listing on their Underpriced AI account (title, list price defaulting to the market price, condition, description) and returns the link where they review and publish it in the app, plus whether eBay is connected and the connect link if not (connecting brings them back to the same item). If the item already has an unpublished eBay draft, it returns that draft unchanged and never overwrites it (draftKept); changes are made in the app. It never publishes anything and only prepares eBay; publishing happens in the app after the user checks the listing, and until then the draft shows in the app under Sell, Not live yet.
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | List price in the scan's currency (price.currency from price_item). Leave empty for the scan's market list price. Not applied when the item already has an eBay draft. | |
| title | No | Overrides the generated listing title (80 characters, eBay's limit). Not applied when the item already has an eBay draft. | |
| scan_id | Yes | The account.scanId that price_item returned for a photo scan on this account (the saved-scan link works too). | |
| condition | No | Replaces the condition read from the photo when the seller has not changed it in the app. Not applied when the item already has an eBay draft. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations flag idempotentHint=true and destructiveHint=false; the description corroborates and enriches this by explaining the existing-draft case (returns draft unchanged, never overwrites, draftKept flag) and that changes must be made in the app. It does not cover auth/rate-limit specifics, but the mutation semantics and non-destructiveness are fully disclosed.
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?
Front-loaded with the core action and the return payload, which is the right ordering. It runs long as one dense paragraph with some restatement ('changes are made in the app' / 'publishing happens in the app'), which slightly dilutes rather than wastes.
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?
Despite having no output schema, the description explains the return payload (review/publish link, eBay connection status, connect link, draftKept) and the follow-on user flow. For a 4-parameter mutation with only one required field, nothing an agent needs to call and interpret it correctly is missing.
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%, so the schema already carries per-parameter meaning including defaults and the 'not applied when a draft exists' caveat. The description only echoes the field list and the market-price default, adding no new syntax or precedence detail beyond structured data.
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?
States a precise transformation chain: photo scan from price_item (account.scanId) → inventory item with a draft eBay listing containing title, price, condition, description. This is a specific verb+resource with the upstream dependency named, which cleanly separates it from price_item and the other read-oriented siblings.
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?
Gives the precondition (signed-in user, scan_id from price_item), the boundary (never publishes — publishing happens in the app after user review), and the alternative path for the not-connected case (connect link returns them to the same item). An agent knows both when to call it and what it must not expect from it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a secondhand item sells for on eBay: a calibrated estimate with a range, the recent real eBay sales behind it (sold comps, linked where the source gives a link), three list prices (fast, market, patient) with the 14-day sell chance, what the seller keeps after eBay fees, and a worth-it verdict when you pass what the user would pay. A description price 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; price.currency names the currency. A photo price (photo, a file the user uploaded in the chat, or image_url, a public https link) needs the user signed in through the connector: it runs a real scan on their account, priced in their own eBay marketplace and currency (price.currency). Without sign-in, describe the item; a description works but reads less than a photo.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | What the user paid or would pay for it, for a worth-it verdict, in the currency the price comes back in (price.currency): the seller's own currency when signed in, USD otherwise, or the currency of the marketplace you pass. | |
| size | No | Size as printed on the tag or measured (for example "M", "10.5", "36 x 36 in", "2.5 quart"). Fill it from the item or label when you can read it. | |
| brand | No | 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. | |
| model | No | 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. | |
| photo | No | A photo the user uploaded in this conversation (ChatGPT passes it as a file). Preferred over a description. | |
| condition | No | Condition as the user states it or as you see it on the item. Open box counts as Like New. "For parts or not working" is for an item that does not work, is broken, or is sold for repair or parts; it is priced against parts sales. When the description says for parts or not working, that wins over this field. Leave empty when unknown. | |
| image_url | No | Public https URL of a photo of the item. Preferred over description alone. | |
| description | No | What the item is: brand, model or pattern, size, any marks, completeness. | |
| marketplace | No | 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. | |
| part_number | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnlyHint=false and openWorldHint=true; the description adds the crucial disclosure that a photo price 'runs a real scan on their account' — a side effect the annotations do not convey. It also spells out auth prerequisites and which currency the result comes back in. It leaves out any notion of credit consumption, rate limits, or failure behavior.
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?
It is front-loaded with the return payload, which is necessary given there is no output schema, and the mode split (description vs photo) follows in a logical order. However, it is a single dense paragraph of long compound sentences that would read far better broken into return-contract, mode, and currency sections.
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?
With no output schema and ten optional parameters, the description does the heavy lifting: it defines the return contract, the two input paths, sign-in gating, and currency behavior. What is missing is routing guidance against the sibling tools and any cost/quota expectations for the account scan.
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 coverage is 100%, so the schema already documents all ten parameters including the cost-currency rule and the marketplace defaulting. The description's parameter content largely restates that (currency follows sign-in/marketplace, photo preferred over description) rather than adding new nuance. Baseline 3 is appropriate when the schema carries the load.
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 names a concrete verb and resource (pricing a secondhand item on eBay) and enumerates the outputs: sold comps, three list prices with 14-day sell chance, fee net, and worth-it verdict. An agent can tell what it produces without opening the schema. It stops short of naming its siblings (get_sold_comps, worth_it, list_on_ebay), so the boundary with those tools is left implicit.
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?
It sets clear conditions for the two input modes: a photo price requires sign-in through the connector, while without sign-in the agent should describe the item. It also explains marketplace/currency selection (own marketplace when signed in, EBAY_US otherwise, explicit marketplace override). It does not say when to reach for price_item instead of worth_it or get_sold_comps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the seller keeps after eBay fees and a verdict (worth it / thin / pass) for an expected sale price and what the user would pay. Pure arithmetic in the currency you give it, with eBay US fees: pass the sale price and the cost in the same currency (the one price_item named in price.currency). For a seller on eBay UK, the worthIt block price_item returns already uses their own fees. Use price_item first when the sale price is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | Yes | What the user would pay for the item, in the same currency as expected_sale_price. | |
| expected_sale_price | Yes | Expected eBay sale price, in the same currency as cost. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the fee model it assumes (eBay US fees by default), the currency matching requirement, and the verdict categories returned. It does not state whether the verdict has thresholds or tolerances, which would have been useful.
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?
Front-loads the output (net proceeds + verdict) before the input mechanics and the currency caveat. Four sentences, all bearing load, though the currency/eBay UK explanation is dense enough that it could be tightened slightly.
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?
With no output schema, the description carries the return-value burden and does describe the two returned concepts (seller net, verdict label). The tool's complexity is low and the currency and fee-model assumptions are stated, leaving only minor ambiguity about verdict thresholds.
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 coverage is 100%, so the two parameters are already documented; the baseline is 3. The description adds meaning beyond the schema by insisting both values be in the same currency and tying that currency to price_item's price.currency, which is a real constraint not captured in the schema.
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?
States a precise computation (net proceeds after eBay fees) plus the verdict output (worth it / thin / pass) for two named inputs. It clearly distinguishes itself from price_item by describing itself as arithmetic on a known sale price rather than a price lookup.
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?
Explicitly routes the agent: 'Use price_item first when the sale price is unknown', and explains that the eBay UK worthIt block from price_item already applies local fees. This is a concrete when-to-use/when-to-defer rule naming the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_sold_comps2 fields changedInput schema / properties / exclude_itemsAdded 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"
+}Input schema / properties / preferAdded 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"
+}price_item1 field changedInput schema / properties / photoAdded value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "download_url": {
+ "format": "uri",
+ "maxLength": 4000,
+ "type": "string"
+ },
+ "file_id": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "file_name": {
+ "anyOf": [
+ {
+ "maxLength": 300,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mime_type": {
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "download_url",
+ "file_id"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "A photo the user uploaded in this conversation (ChatGPT passes it as a file). Preferred over a description."
+}get_sold_comps3 fields changedInput schema / properties / excludeAdded 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"
+}Input schema / properties / includeAdded 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"
+}Input schema / properties / limitAdded 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"
+}get_sold_comps1 field changedInput schema / properties / marketplaceAdded 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"
+}price_item2 fields changedInput schema / properties / cost / descriptionPrevious value: -"What the user paid or would pay for it, for a worth-it verdict: in USD, or in the seller's own currency for a photo scan on a signed-in account."New value: +"What the user paid or would pay for it, for a worth-it verdict, in the currency the price comes back in (price.currency): the seller's own currency when signed in, USD otherwise, or the currency of the marketplace you pass."Input schema / properties / marketplaceAdded 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"
+}worth_it2 fields changedInput schema / properties / cost / descriptionPrevious value: -"What the user would pay for the item in USD."New value: +"What the user would pay for the item, in the same currency as expected_sale_price."Input schema / properties / expected_sale_price / descriptionPrevious value: -"Expected eBay sale price in USD."New value: +"Expected eBay sale price, in the same currency as cost."list_on_ebay3 fields changedInput schema / properties / condition / descriptionPrevious value: -"Overrides the condition read from the photo."New value: +"Replaces the condition read from the photo when the seller has not changed it in the app. Not applied when the item already has an eBay draft."Input schema / properties / price / descriptionPrevious value: -"List price in the scan's currency (price.currency from price_item). Leave empty for the scan's market list price."New value: +"List price in the scan's currency (price.currency from price_item). Leave empty for the scan's market list price. Not applied when the item already has an eBay draft."Input schema / properties / title / descriptionPrevious value: -"Overrides the generated listing title (80 characters, eBay's limit)."New value: +"Overrides the generated listing title (80 characters, eBay's limit). Not applied when the item already has an eBay draft."get_sold_comps4 fields changedInput schema / properties / brandAdded 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"
+}Input schema / properties / modelAdded 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"
+}Input schema / properties / part_numberAdded 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"
+}Input schema / requiredRemoved value: -[
- "query"
-]price_item6 fields changedInput schema / properties / brandAdded 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"
+}Input schema / properties / condition / descriptionPrevious value: -"Condition as the user states it."New value: +"Condition as the user states it or as you see it on the item. Open box counts as Like New. \"For parts or not working\" is for an item that does not work, is broken, or is sold for repair or parts; it is priced against parts sales. When the description says for parts or not working, that wins over this field. Leave empty when unknown."Input schema / properties / condition / enumPrevious value: -[
- "New",
- "Like New",
- "Good",
- "Fair",
- "Poor"
-]New value: +[
+ "New",
+ "Like New",
+ "Good",
+ "Fair",
+ "Poor",
+ "For parts or not working"
+]Input schema / properties / modelAdded 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"
+}Input schema / properties / part_numberAdded 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"
+}Input schema / properties / sizeAdded value: +{
+ "description": "Size as printed on the tag or measured (for example \"M\", \"10.5\", \"36 x 36 in\", \"2.5 quart\"). Fill it from the item or label when you can read it.",
+ "maxLength": 60,
+ "minLength": 1,
+ "type": "string"
+}buy_creditsbuy_credits1 field changedInput schema / properties / pack / descriptionPrevious value: -"A pack to buy, or PAY_AS_YOU_GO (top-up scans, plan subscribers only). Leave empty to see the options and the balance first."New value: +"A pack to buy, or PAY_AS_YOU_GO (the meter: 25 cents for each photo pricing; no plan needed, or the top-up past a plan's scans). Leave empty to see the options and the balance first."buy_credits1 field changedInput schema / properties / pack / descriptionPrevious value: -"A pack to buy, or PAY_AS_YOU_GO. Leave empty to see the options and the balance first."New value: +"A pack to buy, or PAY_AS_YOU_GO (top-up scans, plan subscribers only). Leave empty to see the options and the balance first."get_scan_result1 field changedInput schema / properties / cost / descriptionPrevious value: -"What the user would pay, in USD, for a worth-it verdict."New value: +"What the user would pay, in the scan's currency (price.currency), for a worth-it verdict."list_on_ebay1 field changedInput schema / properties / price / descriptionPrevious value: -"List price in USD. Leave empty for the scan's market list price."New value: +"List price in the scan's currency (price.currency from price_item). Leave empty for the scan's market list price."price_item1 field changedInput schema / properties / cost / descriptionPrevious value: -"What the user paid or would pay for it, in USD, for a worth-it verdict."New value: +"What the user paid or would pay for it, for a worth-it verdict: in USD, or in the seller's own currency for a photo scan on a signed-in account."Appraise resale items from photos and write listings for eBay, Mercari, OfferUp and more.
Sold comps and active listings from eBay, Poshmark, Mercari, Depop, Vinted, TCGplayer and more.
Know what anything is worth new, used, or resale, and get links to the best place to buy or sell it. Just name it or snap a photo.
Price checks for resale agents: sold comps with confidence grades, mislisting scans, fee math.
Add one secure layer between your agents and this server.
