Real sold prices on Vinted in 7 countries: median, range, time to sell, country comparison.
Scored across 2 tools
The two tools have clearly distinct scopes: one returns detailed sold-price statistics for a single country, the other compares sales counts and medians across seven countries. An agent can easily pick the right one based on whether it needs single-market detail or cross-border comparison.
Both names use a consistent 'vinted_' prefix and snake_case, which makes the set predictable. There is a minor style deviation in that 'compare_countries' is verb-led while 'sold_prices' is a noun phrase, but the intent of each remains clear.
Two tools is thin for a server, though the domain (Vinted sold-price comps) is narrow and each tool bundles substantial functionality. A small set is defensible here, but it sits at the borderline of feeling under-scoped.
The core comps workflow—single-country stats and cross-country comparison—is well covered, including medians, ranges, sell-through speed, and examples. Minor gaps remain, such as historical price trends or browsing/searching by category, but nothing that blocks the primary use case.
The same search across all 7 Vinted countries: how many sales each has, and the median price in EUR for the home country and the next busiest one, with the price gap. Useful for cross-border reselling. Returns a link to the full comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| home_country | No | Vinted country: UK, FR (France), DE (Germany), IT, ES (Spain), NL, PL. Pick the user's market; if unknown, FR has the most sales. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuine output context — sales counts per country, median price in EUR for two countries, the price gap, and a link to the full comparison — which an agent cannot derive from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct information: what is compared, what is returned, and who it is for. The output shape is front-loaded before the audience note, with no filler.
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 does the necessary work of summarizing return values (counts, medians, gap, link). The remaining gap is query semantics — it is unclear whether query is a keyword, phrase, or category — for a 2-parameter tool with one required free-text input.
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 50%: home_country is fully documented in-schema including the 'FR if unknown' fallback, but query has no description at all. The description only implies query is a search term ('The same search') and clarifies that median price is reported for the home country plus the next busiest, adding some meaning to home_country beyond the enum.
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 a specific verb and resource — running one search across all 7 Vinted countries and comparing sales counts and median EUR prices — which is clearly distinct from a single-market price lookup. It never names the sibling vinted_sold_prices, so differentiation is inferable but not 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?
'Useful for cross-border reselling' gives a usage context, implying it fits market-selection decisions. However there is no explicit when-to-use vs. vinted_sold_prices, no prerequisites, and no statement of when a single-country lookup is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirmed sold prices for an item on Vinted in one country: number of sales, median and typical range (p25-p75), how many days items took to sell, how many sold within a week, and a few recent example sales. Returns a link to the full list of sales.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days | |
| query | Yes | What to price, as a seller would title it: brand + model/item, e.g. 'adidas samba', 'levis 501', 'zara golden decade 80ml'. Leave out size and colour unless they matter. | |
| country | No | Vinted country: UK, FR (France), DE (Germany), IT, ES (Spain), NL, PL. Pick the user's market; if unknown, FR has the most sales. | |
| condition | No | any |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by spelling out exactly what is returned (aggregate stats, example sales, and a link to the full list), which is the main thing an agent needs to decide whether to call it.
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?
A single front-loaded sentence that names the resource first, then the metrics payload, then the return link. Dense but every clause maps to a distinct output the caller would care about; no filler.
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 so explicitly by listing the aggregated statistics and the link to the full sales list. Parameter behavior is largely left to the well-covered schema, which is acceptable at 75% coverage.
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 75% and the schema already documents query phrasing, the 90-day default window, the country enum with guidance, and condition. The description adds only the 'one country' framing and no detail on the days window or condition, so it sits at the baseline for a well-documented 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 (confirmed Vinted sold prices for an item in one country) and enumerates the computed outputs (sales count, median, p25-p75, days-to-sell, weekly sell-through, examples, link). The 'in one country' scoping implicitly separates it from vinted_compare_countries, though the sibling is never named.
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 is only implied: 'in one country' plus the schema note 'Pick the user's market; if unknown, FR has the most sales' hints at market selection, but the description never states when to choose this over vinted_compare_countries or what prerequisites exist. An agent must infer the routing decision.
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.
vinted_compare_countriesvinted_sold_pricesCleaned sold prices for used clothing, shoes and bags: Poshmark US and Canada.
Observed Vinted market analytics: compare brands, research niches, and discover trends via OAuth.
GDPR-clean secondhand listings and sold comps for resale pricing research. No seller personal data.
Video game prices from completed eBay and Vinted sales, by platform, region, edition and condition.
Add one secure layer between your agents and this server.