Skip to main content
Glama

Value a donation list

value_donation_list
Read-onlyIdempotent

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.
    

Input Schema

NameRequiredDescriptionDefault
daysNo
itemsYes
sourceNoposhmark
sold_afterNo
sold_beforeNo
examples_per_itemNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / $defs / DonationItem / properties / kids_age
      Added 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"
      +}
    • addedInput schema / properties / days
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 3650,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Days"
      +}
    • addedInput schema / properties / sold_after
      Added value: +{
      +  "anyOf": [
      +    {
      +      "format": "date",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Sold After"
      +}
    • addedInput schema / properties / sold_before
      Added value: +{
      +  "anyOf": [
      +    {
      +      "format": "date",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Sold Before"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness5/5

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.

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

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources