Cleaned sold prices for used clothing, shoes and bags: Poshmark US and Canada.
Scored across 3 tools
The three tools map to clearly distinct workflows: a buy/pass decision for one item at a given cost, raw sold-comps data for one item, and bulk valuation of a donation list. buy_or_pass and sold_comps are related, but the presence of cost and a decision output makes the boundary clear.
All names use snake_case, but the semantic patterns are mixed: buy_or_pass is an imperative decision phrase, sold_comps is a noun phrase, and value_donation_list is verb_noun_noun. The names are readable but do not follow one predictable convention.
Three tools is well-scoped for a focused Poshmark pricing and valuation server. Each tool serves a distinct role, and there are no redundant or filler endpoints.
The surface covers the core workflows: sold comps, single-item buy/pass decisions, and bulk donation valuation. Minor gaps exist, such as no dedicated bulk buy/pass workflow for resale sourcing, but the current tools provide practical workarounds.
Whether an item is worth buying at a given cost to resell on Poshmark: buy, maybe or pass with the reason, judged from its clean sold comps after Poshmark's fee. Call it for one item at a time; if it reports busy, wait the given number of seconds and call again.
query: brand + item, e.g. "patagonia better sweater".
cost: what you'd pay, e.g. the thrift-store tag price, in the same currency as source (USD for poshmark, CAD for poshmark_ca).
min_profit: smallest profit after fees worth the effort (default 10).
size / condition: same filters as sold_comps.
source: "poshmark" (US, default) or "poshmark_ca" (Poshmark Canada; prices and fees in CAD).
| Name | Required | Description | Default |
|---|---|---|---|
| cost | Yes | ||
| size | No | ||
| query | Yes | ||
| source | No | poshmark | |
| condition | No | ||
| min_profit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantive context beyond them: output is a buy/maybe/pass verdict with a reason, comps are fee-adjusted, currency follows the source (USD vs CAD), and there is documented rate-limit retry 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?
The verdict definition is front-loaded, followed by operational notes, then a compact per-parameter list. Nearly every line earns its place; only minor formatting artifacts and the deferred size/condition line dilute it.
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?
For a six-parameter tool with no output schema, the description covers the return shape (verdict plus reason), the fee/currency model, retry behavior, and all parameters. It omits how comps are selected (lookback window, comp count), which limits full confidence in the verdict.
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?
With 0% schema description coverage the description carries the burden and mostly does: query format is exemplified, cost is explained against the source currency, min_profit gets a default and meaning, and source values are enumerated with currency implications. Only size/condition are deferred to 'same filters as sold_comps' without format detail.
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 states exactly what the tool produces: a buy/maybe/pass verdict with a reason, derived from sold comps net of Poshmark fees. It is distinguishable from sold_comps by output type (a decision, not raw comps), though it never explicitly names sold_comps as the alternative for raw data.
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 gives clear operating context — evaluate one item at a time, and on a 'busy' response wait and retry — plus the implicit condition of use (you have a cost and want a resale verdict). It stops short of explicit when-not guidance or routing to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What an item actually sold for on Poshmark: median sold price, typical range (p10-p90), days to sell, what the seller keeps after fees, price by condition, a confidence rating, and the matching sales. Call it for one item at a time; if it reports busy, wait the given number of seconds and call again.
query: brand + item, e.g. "coach tabby 26" or "lululemon align leggings", or a plain item type like
"womens jeans". For kids' clothing put girls, boys, kids, toddler or youth in the query ("girls jeans");
otherwise kids' sizes are removed.
size: only this size, e.g. "8", "M" or "10.5". Leave it out unless the user named a size: it can leave
very few sales.
condition: "new", "used", a plain word (nwt, like new, excellent, very good, good, fair, poor), or an
exact grade: new_with_tags, not_new_with_tags, used_like_new,
used_excellent, used_good, used_fair (comma-separated for several).
days: only sales from the last N days (1-365). Poshmark lists sold results by relevance, not date, so
without it the sales can be years old; days=365 (or 90) keeps prices recent.
limit: how many individual sales to include in `sales` (default 10, 0-50). Each sale has the same fields
as a /v1/sold item.
exclude_seller: comma-separated seller usernames to leave out (case-insensitive).
sort: order of the included sales: "recent" (newest first), "price_asc" or "price_desc". Stats are unaffected.
department: comma-separated: Women, Men, Kids, Home, Pets, Electronics. "Kids" also keeps kids' sizes, and
adds "kids" to a query with no kids' word ("snow pants" searches "kids snow pants"; query_note says so).
category: comma-separated Poshmark categories, e.g. "Jeans".
kids_age: only kids' sales in "baby" (0-24 months), "toddler" (2T-5T) or "big_kids" (4/5 and up) sizes.
Kids' searches otherwise keep 12-24 month and toddler sizes, as Poshmark's Kids department does.
include_removed: true also returns removed_items, the sales cleaning dropped, each with a removed_reason.
deep: true reads up to ~190 sales (4 pages of up to 48, in Poshmark's relevance order) instead of one
page (slower when not cached, about 10s; one lookup).
source: "poshmark" (US, default) or "poshmark_ca" (Poshmark Canada; prices and fees in CAD).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| deep | No | ||
| size | No | ||
| sort | No | ||
| limit | No | ||
| query | Yes | ||
| source | No | poshmark | |
| category | No | ||
| kids_age | No | ||
| condition | No | ||
| department | No | ||
| exclude_seller | No | ||
| include_removed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/idempotent/non-destructive, so the description adds substantial behavior beyond them: busy/retry handling, the ~10s uncached latency and 4-page/~190-sale scope of deep, caching behavior, the removed_items list with removed_reason, and CAD vs USD pricing for poshmark_ca. These are exactly the operational traits an agent needs and cannot infer from structured fields.
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 long, but the length is driven by 13 undocumented parameters and it is cleanly structured with a labeled line per parameter after a front-loaded purpose statement. Only minor waste (restating the limit default that the schema already declares), but nothing is padded.
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 13 parameters, no schema descriptions, and no output schema, the definition supplies both halves: full parameter semantics and a description of the return payload (stats bundle plus the sales list and their field parity with /v1/sold items). Anything an agent needs to invoke and interpret this call is present.
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 0%, so the description carries the entire burden, and it does: it documents all 13 parameters with meaning, accepted values, formats, defaults, side effects (kids' sizes dropped without a kids' word; Poshmark's relevance ordering making old sales appear without days), and illustrative examples. The condition grades and department/source vocabularies are supplied here and nowhere else 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?
The description names a specific resource (Poshmark sold prices for one item) and enumerates the exact outputs it produces: median sold price, p10-p90 range, days to sell, seller proceeds, price by condition, and a confidence rating. That is far more specific than a restated title. It never names its siblings (buy_or_pass, value_donation_list) or contrasts itself with them, so sibling differentiation 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?
Usage context is clear and actionable: 'Call it for one item at a time; if it reports busy, wait the given number of seconds and call again,' plus conditional guidance on individual parameters ('Leave it out unless the user named a size'). It never states when to prefer this tool over buy_or_pass or value_donation_list, so the alternatives dimension is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fair-market values for a whole donation list (clothing, shoes, bags and household goods: kitchen, home, electronics, media, toys, baby gear, pets, beauty), each item with the Poshmark sales behind it, a list total and a dated method paragraph the donor can keep with their records. One call values up to 100 items and costs one lookup per item. Call it once with the whole list, not once per item.
items: a list of objects, one per item. Only description is required.
description: what it is, as the donor would say it: "womens handbag", "mens suit", "kids snow pants",
"Levi's 501 jeans", "KitchenAid stand mixer". Put brand and model in brand or description. Goods are
valued only from sales of the same product, so name it as it would be listed; a count in the text
("throw pillows (4)") is read as the quantity.
brand: optional, e.g. "Coach". With a brand the item is priced from that brand's own sales when enough are
saved, else from its category.
condition: optional. new_with_tags, used_like_new, used_excellent, used_good, used_fair, a plain word
(like new, good, fair), or new or used. Default used, which is right for most donations.
category, department, size: optional; read from the description when left out. A kids' size such as
"4T" marks the item as kids'.
kids_age: optional, for kids' items: "baby" (0-24 months), "toddler" (2T-5T) or "big_kids" (4/5 and up).
quantity: optional, default 1. total is value times quantity.
source: "poshmark" (US, USD, default) or "poshmark_ca" (Poshmark Canada, CAD).
examples_per_item: how many of the sales behind each value to include (0-5, default 2). Each has a title,
price, sold date and link.
days: only sales from the last N days (1-3650); 365 is the last 12 months. Default: every sale.
sold_after, sold_before: only sales sold on or after / on or before these dates (YYYY-MM-DD).
On the Free, pass and Starter plans every value uses only sales from the last 90 days (any window is cut to
it, history_days is 90 and history_note says so), except keys issued before Oct 25 2026, which keep the full
archive (history_days is null); Growth and Scale use the full archive, back to 2012.
Each item gets value (the median sold price), low and high (the 25th and 75th percentiles), p10 and p90
(the 10th and 90th), sales_used, oldest_sold and newest_sold (within the window), matched_on ("brand +
item", "item description", "category + department" or "category, all departments"), broadened (true when
the value comes from wider sales than the item as described: no brand match, a description reduced to its
category, all departments, or the condition group instead of the exact grade), condition_matched (the grade
or group the sales are in), by_condition (median and range per grade), a confidence rating and a reason
that says why. basis is the older name of matched_on. An item with nothing to go on has value null and a
reason; never guess a value for it. The list has total, items_valued, method and disclaimer. This is resale
market data, not tax or legal advice; appraisal_may_be_needed is true when a single item, or a group of similar items (same category), is over $5,000.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| items | Yes | ||
| source | No | poshmark | |
| sold_after | No | ||
| sold_before | No | ||
| examples_per_item | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, but the description adds critical behavioral context: plan-based history windows (Free/Starter 90 days vs Growth/Scale full archive), cost of one lookup per item, null-value handling with 'never guess', confidence/broadening semantics, and the appraisal flag. This is rich, non-redundant disclosure.
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 purpose, then well-organized sections for items, source, examples_per_item, days, plan limitations, and output fields. The length is justified by the tool's complexity; every sentence adds concrete information.
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 explains all return fields (value, low, high, p10, p90, sales_used, oldest_sold, newest_sold, matched_on, broadened, condition_matched, by_condition, confidence, reason, basis, total, items_valued, method, disclaimer) and edge cases like null values and the $5,000 appraisal flag. Nothing essential 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?
Despite the context signal of 0% schema description coverage, the description thoroughly explains every parameter: item description guidance ('as the donor would say it'), brand behavior, condition defaults, kids_age meanings, quantity effect, source options, examples_per_item, days, and sold_after/sold_before. It more than compensates for any schema gap.
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 ('value') and resource ('donation list'), plus scope (up to 100 items, fair-market values). It does not explicitly name or distinguish from the sibling tools buy_or_pass and sold_comps, so it falls short of a 5.
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?
Clearly advises to call once with the whole list rather than per item, which is a useful usage constraint. However, it does not name alternative tools or say when not to use this tool, so no explicit alternative routing.
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.
sold_comps1 field changedInput schema / properties / kids_ageAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "baby",
+ "toddler",
+ "big_kids"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Kids Age"
+}value_donation_list4 fields changedInput schema / $defs / DonationItem / properties / kids_ageAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "baby",
+ "toddler",
+ "big_kids"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional, for kids' items: baby (0-24 months), toddler (2T-5T) or big_kids (4/5 and up) sizes only",
+ "title": "Kids Age"
+}Input schema / properties / daysAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 3650,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Days"
+}Input schema / properties / sold_afterAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sold After"
+}Input schema / properties / sold_beforeAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sold Before"
+}value_donation_listsold_comps5 fields changedInput schema / properties / categoryAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Category"
+}Input schema / properties / departmentAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Department"
+}Input schema / properties / exclude_sellerAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Exclude Seller"
+}Input schema / properties / include_removedAdded value: +{
+ "default": false,
+ "title": "Include Removed",
+ "type": "boolean"
+}Input schema / properties / sortAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "recent",
+ "price_asc",
+ "price_desc"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sort"
+}sold_comps1 field changedInput schema / properties / deepAdded value: +{
+ "default": false,
+ "title": "Deep",
+ "type": "boolean"
+}buy_or_pass1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "poshmark",
+ "title": "Source",
+ "type": "string"
+}sold_comps1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "poshmark",
+ "title": "Source",
+ "type": "string"
+}buy_or_passsold_compseBay, Poshmark US and Mercari US listings, sold-price summaries, comparisons and research exports.
GDPR-clean secondhand listings and sold comps for resale pricing research. No seller personal data.
Poshmark Comps — sold-price search on the public Poshmark marketplace
Real sold prices on Vinted in 7 countries: median, range, time to sell, country comparison.
Add one secure layer between your agents and this server.