SoldStack

Sold prices for an item

sold_comps

Read-onlyIdempotent

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).

Input Schema

Name	Required	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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / kids_age

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "baby",
+        "toddler",
+        "big_kids"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Kids Age"
+}

Changed5 schema fields changedOct 13, 2026

addedInput schema / properties / category

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Category"
+}

addedInput schema / properties / department

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Department"
+}

addedInput schema / properties / exclude_seller

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Exclude Seller"
+}

addedInput schema / properties / include_removed

Added value: +{
+  "default": false,
+  "title": "Include Removed",
+  "type": "boolean"
+}

addedInput schema / properties / sort

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "recent",
+        "price_asc",
+        "price_desc"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Sort"
+}

Changed1 schema field changedOct 11, 2026

addedInput schema / properties / deep

Added value: +{
+  "default": false,
+  "title": "Deep",
+  "type": "boolean"
+}

Changed1 schema field changedOct 8, 2026

addedInput schema / properties / source

Added value: +{
+  "default": "poshmark",
+  "title": "Source",
+  "type": "string"
+}

First observedOct 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All SoldStack tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?