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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "sold_comps"
  }
}

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 changedNov 9, 2026

changedInput schema / properties / days / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 365,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

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"
+}

First observedOct 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), yet the description adds real behavior: busy/retry handling, cache and ~10s latency for deep mode, page-size and result caps, department-driven query rewriting, and CAD pricing for poshmark_ca. These are non-obvious traits an agent cannot get from the annotations or schema.

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?

Front-loads the purpose sentence, then uses a clean per-parameter list with indented examples, so it scans well despite its length. A few phrases are cryptic for a caller ('the same fields as a /v1/sold item', 'one lookup') and could be tightened, but nearly every line carries necessary semantics for 13 params.

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 takes responsibility for describing returns (stats, fee take, per-condition breakdown, confidence, and the `sales` array, plus optional `removed_items`). Combined with retry, latency, and pagination notes, nothing essential for a correct call is missing.

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% and there are 13 parameters, so the description must carry the load — and it does, documenting every one with examples and accepted values (condition grades, kids_age bands, sort enums, department list, source currencies, days 1-365, limit 0-50 default 10). It also explains interactions, e.g. Kids department adding 'kids' to the query and setting query_note.

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

Purpose5/5

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

Opens with a concrete verb-and-resource statement ('What an item actually sold for on Poshmark') and enumerates the delivered metrics: median sold price, p10-p90 range, days to sell, seller net after fees, price by condition, confidence rating, and matching sales. This is clearly a comps/pricing tool, distinguishable from valuation siblings like buy_or_pass and value_donation_list.

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?

Gives operational guidance ('one item at a time', retry-on-busy after waiting N seconds) and conditional rules for optional params ('leave size out unless the user named a size', 'days=365 keeps prices recent'). It does not explicitly contrast with sibling tools or state when-not-to-use relative to them, which keeps it below a 5.

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?