Skip to main content
Glama
googlarz

Vinted MCP and CLI Server

get_new_items

Fetch the most recently listed items for a search query (newest first). To monitor a search, call it repeatedly and pass the previous response's latestId as afterId — only items listed since then are returned (truncated: true means more…

Instructions

Fetch the most recently listed items for a search query (newest first). To monitor a search, call it repeatedly and pass the previous response's latestId as afterId — only items listed since then are returned (truncated: true means more than perPage arrived; raise perPage or poll more often). Supports the same filters as search_items (brand, category, size, color, price, condition).

Input Schema

NameRequiredDescriptionDefault
sizeNoSize labels, e.g. ["M"]; automatically resolved to IDs
brandNoBrand names; automatically resolved to IDs
colorNoColor names, e.g. ["black"]; automatically resolved to IDs
queryYesSearch keywords to monitor, e.g. "Nike Air Max 90 size 42"
afterIdNoReturn only items with an ID greater than this (use latestId from the previous call). Omit on the first call.
countryNoVinted country site to monitorfr
perPageNoNumber of newest items to inspect, 1–96
sizeIdsNoSize IDs to filter by
brandIdsNoNumeric brand IDs from search_brands
colorIdsNoColor IDs to filter by
priceMaxNoMaximum price in local currency
priceMinNoMinimum price in local currency
conditionNoItem condition filter
categoryIdNoCategory ID from get_categories

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.3

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it does disclose useful behavior: newest-first ordering, incremental semantics via afterId, the truncated flag, and polling guidance for perPage. It also reveals response shape (latestId) despite no output schema. It omits auth requirements and hard rate limits, which keeps it below 5.

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?

Three sentences with no filler, and the core monitoring pattern is front-loaded right after the purpose statement. The nested parentheticals around truncated/perPage make it slightly dense to parse, but every clause is load-bearing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with no annotations and no output schema, the description covers the essentials an agent needs: the polling contract, the incremental cursor, the truncation signal, and the shared filter set. Left uncaptured are authentication expectations and the shape of individual item objects, which is a minor gap given the sibling tools likely define item structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, and the description adds real meaning on top: it explains the intended afterId value (latestId from the previous call), the perPage/toggle-polling tradeoff, and which filter groups (brand, category, size, color, price, condition) are shared with search_items.

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?

States a specific verb and resource — fetch the most recently listed items for a search query, newest first — and its monitoring/afterId semantics differentiate it from search_items, which it names as the source of the same filter set. An agent can tell what this tool returns and how it differs from the general search sibling.

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 a concrete when-to-use workflow: call repeatedly to monitor a search, passing the previous response's latestId as afterId, and notes that truncated:true means raising perPage or polling more often. It does not state when NOT to use it (e.g. one-off lookups should use search_items), so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.