vinted-seller-mcp

by rachid598

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, with the three search-related tools (search_items, search_similar_items, get_similar_items) differentiated by their descriptions. Similarly, update_price vs edit_listing are separated by scope, and deactivate vs delete are unambiguous. Only minor overlap exists between session-related tools whoami and session_status.
Naming Consistency3/5
The majority of tools follow a verb_noun pattern (search_items, get_item, update_price, publish_listing), but several deviate with noun-only names like whoami, my_listings, seller_stats, conversations, and session_status. This mix of verb-led and noun-only names creates a slight inconsistency in the naming scheme.
Tool Count2/5
At 27 tools, the count exceeds the 25-tool threshold considered 'too many' in the calibration. While the breadth of functionality for a seller MCP is extensive, the large number feels heavy, and some tools (e.g., multiple search variants) could potentially be consolidated.
Completeness5/5
The tool set covers the full selling lifecycle: research (search, estimate_price, find_brand, find_category), draft management (prepare, update, add photos, validate), publishing, and post-publish actions (edit, price, deactivate, delete). Messaging and session handling are also included. No obvious gaps exist for the stated domain.
Average 4.2/5 across 27 of 27 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that the listing was 'previously hidden' and returns it to the catalogue, offering some context on state transition. However, it does not detail what happens if the listing is already active, whether it becomes immediately visible, or any side effects such as search indexing.
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?
The description is one concise sentence that effectively communicates the core functionality without unnecessary words. It is front-loaded and earns its place, making it easy for an agent to parse quickly.
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?
This is a simple tool with two parameters and no output schema. The description adequately conveys the main purpose and state change. It could mention edge cases (e.g., reactivating an already-active listing) but given the tool's simplicity and the idempotent annotation, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: country has a description, but itemId does not, and the description provides no additional meaning for itemId. It is self-evident that itemId identifies the listing, but the description does not compensate for the missing schema documentation. Given coverage is below 50%, the tool description should have explained the parameters but does not.
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 clearly states the tool's function: bringing a previously hidden listing back into the catalogue. The verb 'brings back' and resource 'listing' provide a specific action, and the title 'Republish a hidden listing' reinforces the purpose. It does not explicitly differentiate from sibling publish_listing, but the mention of 'previously hidden' sets it apart from publishing a draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a listing was hidden (e.g., deactivated) and needs to be restored. However, it provides no explicit alternatives, conditions, or scenarios where this tool should not be used. Context from sibling tools (deactivate_listing, publish_listing) helps infer usage, but the description alone offers limited guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context by noting that favourited buyers are notified of price drops, which is not captured in annotations. It also includes the confirmation requirement. This goes beyond what annotations already provide.
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?
Two concise sentences with no fluff. The core action is front-loaded, and the caveat about notifications is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple price update tool, the description covers the main function and a key side effect, but lacks parameter details and does not address potential confusion with edit_listing, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the itemId or price parameters, and with only 25% schema description coverage, it fails to compensate for undocumented parameters like currency and country. It only implies that itemId refers to a live listing.
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?
The description clearly states it changes the price of a user's live listing, using a specific verb and resource. This distinguishes it from sibling tools like edit_listing or draft management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to confirm the new price with the user first, which is useful context. However, it does not explicitly mention when to use this tool over alternatives like edit_listing for broader changes, leaving usage somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral details (sort order, included fields). However, it doesn't go beyond these essentials, so it's consistent but not particularly rich.
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?
A single, tightly worded sentence that conveys all essential information without redundancy. It is front-loaded with the action and scope.
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 simple list tool, the description covers the core return content (counterpart and item) and the pagination is implied by the schema parameters. The absence of an output schema is mitigated by the explicit mention of what the list contains. It doesn't specify any edge cases, but given the tool's simplicity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33% (only country has a description). The tool description does not explain page or perPage parameters, despite their meaning not being self-evident to all agents. The description fails to compensate for the low schema coverage.
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?
The description clearly states the tool lists the signed-in user's conversations, with specific details on order (newest first) and content (counterpart and related item). This distinguishes it from sibling tools like read_messages or send_message.
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?
The description provides clear context: it is for listing conversations of the signed-in user. It doesn't explicitly mention alternatives or exclusions, but the scope is unambiguous and the purpose is obvious from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is safe. The description adds that it returns listings with prices, views, and favourites, which is helpful context. However, it does not mention pagination behavior, status filtering, or any rate limits, which would be useful beyond the annotations.
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?
The description is a single, front-loaded sentence that clearly states the purpose without any extraneous information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with annotations and schema, the description is mostly adequate, mentioning the key return fields. However, it does not mention pagination or the effect of status/country parameters, which could be important for an agent to know when calling the tool. No output schema exists, so more detail on the response shape would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: status and country have descriptions, while page and perPage do not. The description does not compensate for the missing parameter details, but the parameter names are fairly self-explanatory. It adds no additional meaning beyond the schema's existing descriptions.
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?
The description clearly states the tool lists the signed-in user's own listings, with specific fields (prices, views, favourites). This distinguishes it from sibling tools like search_items and get_item, which operate on the general marketplace or individual items.
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?
The description provides clear context: it is for the signed-in user's own listings, which implies it should be used when the agent needs the current user's items. However, it does not explicitly name alternatives or exclusions, such as 'for other users' items, use search_items instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description reinforces this with 'Returns' and clarifies the operational scope by listing the draft components returned. This adds context beyond the annotation, though it doesn't address error behaviors or prerequisites.
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?
A single sentence that front-loads the action ('Returns') and concisely enumerates the return contents without extraneous information.
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 single-getter with one parameter and no output schema, the description is fairly complete: it identifies the target resource and the full set of information contained in the draft. It doesn't cover error cases, but that's typical for simple getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a description ('Draft id returned by prepare_listing'), so the description does not need to elaborate. It adds no direct parameter detail, but with full schema coverage, baseline 3 is appropriate.
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?
The description uses the verb 'Returns' and clearly specifies the resource 'a stored draft in full' with enumerated components (fields, photos, comparables, price estimate, validation state, history). This distinguishes it from sibling tools like list_drafts (list vs single) and update_listing_draft (update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single draft by ID, but does not explicitly state when to use it versus alternatives like list_drafts or get_item, nor does it provide any when-not-to-use guidance. However, the context is straightforward for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and openWorld hints. Description adds the context that this is Vinted's own carousel, but doesn't detail behavior such as empty results or validation errors.
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?
Two sentences, minimal, with the core action first and complementary context second.
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 simple read-only tool with annotations and two documented parameters, the description covers the essentials, though lack of output schema info leaves the return format somewhat vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers country description; description clarifies itemId as the listing id but provides no additional constraints or semantics beyond the schema.
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?
Clearly states it returns Vinted's similar items carousel for a listing id, and distinguishes from search_similar_items by positioning it as complementary when anchoring on a near-identical listing.
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?
Explicitly names the alternative search_similar_items and gives a condition for using this tool (anchoring on a near-identical listing), though it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses non-obvious behavior: it 'tries several search phrasings,' removes duplicates/accessories/broken/mismatched items, and returns both kept comparables and rejection reasons. This is rich, non-obvious behavioral context with no contradiction.
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?
Three sentences: purpose, input guidance, and behavioral detail. It is front-loaded with the core purpose, every sentence adds information, and there is no fluff.
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 tool with 18 parameters and no output schema, the description explains the output format (kept items plus rejection reasons) and the core filtering logic, which is essential context. It does not address default behavior or explicitly compare with get_similar_items, but the schema and annotations cover most parameter semantics and safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (89%), so the baseline is 3. The description adds mild semantic value by identifying 'brand, model, capacity, size, colour' as photo-visible facts, but does not elaborate on parameters beyond what the schema already provides.
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 clearly states it 'Finds listings genuinely comparable to an item you are about to sell' and details the filtering and output, making the purpose specific. However, the sibling 'get_similar_items' exists and the description does not explicitly differentiate itself from that similarly named tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context: use when about to sell an item and give facts visible in photos, and mentions returning rejection reasons 'so you can justify the price to the user.' No explicit exclusions or comparisons with alternatives like search_items or get_similar_items are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical behavioral guarantee: 'Originals on disk are never modified or moved.' This goes beyond the destructiveHint annotation by specifying exactly what is protected. It also mentions Vinted's photo-count rule, giving useful behavioral context about the platform's constraints.
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?
Three concise sentences: the primary action, a safety guarantee, and a usage tip. Each sentence adds value without redundancy, and the main action is front-loaded.
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?
The description covers the core purpose, safety, and a practical use case. With two straightforward parameters, no output schema, and clear annotations, this is largely complete. Minor omissions like duplicate handling or return value do not detract significantly for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% top-level schema description coverage, the description should compensate by explaining parameters, but it does not. It only hints that 'photos' are images to copy and 'draftId' identifies the draft. The nested schema descriptions for path and caption are present, but the overall parameter semantics are minimally addressed.
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?
The description explicitly states the action: 'Copies more photos into an existing draft.' This clearly identifies the verb (copies), the resource (photos), and the target (existing draft), distinguishing it from sibling tools like delete_draft or publish_listing.
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?
The description provides a concrete usage scenario: 'Vinted may block publishing higher-value items with fewer than 3 photos,' implying this tool should be used to add photos when a draft has too few. It does not explicitly name alternative tools, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true in annotations, the safety profile is covered. The description adds value by disclosing sort order ('newest first') and that returned fields include status and headline. It does not mention pagination or filtering behavior, but the annotations lower the bar and the added details are useful.
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?
The description is a single, well-structured sentence that front-loads the core purpose ('Lists local drafts') and packs in ordering and output details without waste.
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 simple list tool with two optional parameters and no output schema, the description conveys the main purpose, ordering, and key fields. It is slightly incomplete in not explaining the effect of the 'limit' parameter or whether pagination exists, but overall it is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: the 'status' parameter has a description, but 'limit' does not. The tool description does not mention parameters at all, instead focusing on output fields. It fails to compensate for the undocumented 'limit' parameter, offering no guidance on its meaning or constraints.
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?
The description clearly states the tool 'lists local drafts' with a specific verb and resource. It also distinguishes itself from siblings like get_listing_draft by focusing on the collection, and adds sorting ('newest first') and output fields ('status and headline fields').
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?
The context is clear: this is for listing local drafts, which is distinct from single-draft tools like get_listing_draft or mutating tools like delete_draft. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=true, destructive=false. The description adds useful partial-update semantics ('Only the fields you pass are changed') and the ethical constraint about not rewriting user wording. This goes beyond the annotations without contradicting them.
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?
The description is two sentences with no filler. The first sentence states the core purpose, and the second adds the critical behavioral nuance. It is front-loaded and every word earns its place.
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?
Given the tool's complexity (14 parameters, no output schema) and rich sibling set, the description provides enough context for safe invocation: when to use, that it's a partial update, and that it's non-destructive. It could mention validation behavior or return format, but the annotations cover the safety profile, making this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 21%, so the description must compensate for the many undocumented parameters. It provides a general partial-update rule that applies to all fields but does not explain individual fields beyond what the schema already offers. The names are somewhat self-explanatory, but the low coverage leaves significant room for misunderstanding.
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?
The description uses a specific verb ('Applies the user's corrections') and names the resource ('draft'). It also differentiates from siblings by emphasizing partial updates ('Only the fields you pass are changed') and by explicitly scoping to post-user-feedback usage. This is clear and distinct within the tool set.
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?
The description gives explicit usage context ('Use this after showing the draft to the user') and a behavioral constraint ('never rewrite their wording on your own initiative'). However, it does not mention any alternative tools or when not to use it, so it stops short of a full when/when-not pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals a meaningful behavioral trait beyond annotations: it attempts the API first and falls back to driving the browser form. It also states a constraint ('Only change what the user asked for') which implies preservation of unrequested fields. No contradiction with annotations exists.
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?
Two sentences, no wasted words. The first sentence states the action and scope; the second adds fallback behavior and a safety constraint. Information is front-loaded and scannable.
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 moderate-complexity tool with annotations and no output schema, the description covers the essential context: what it edits, that it belongs to the user, when it uses a fallback, and that it only changes requested fields. It could mention prerequisites like authentication or error behavior, but given the annotations and schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description must compensate. It mentions the main editable fields but omits itemId (the required ID) and the country parameter. 'Classification' is ambiguous (covers categoryId and/or brandId). The description adds some meaning but does not fully clarify all parameters.
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?
The description clearly specifies the action ('Edits') and the resource ('one of the user's live listings'), and enumerates the editable fields (title, description, price, classification). This distinguishes it from sibling tools like update_price (price only) and update_listing_draft (drafts).
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?
Provides clear context: targets live listings as opposed to drafts, and notes the fallback from API to browser automation. However, it does not explicitly mention when to prefer sibling tools like update_price or how to handle draft listings, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds useful behavior beyond that: exact matching semantics (`exact: true`) and the fallback behavior for no matches, which is valuable context for the agent.
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?
Two sentences, front-loaded with the purpose, and every clause adds value. No fluff or repetition of schema/annotation details.
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 simple read-only lookup, it covers purpose, output shape, exact-match semantics, and no-match fallback. Without an output schema, return fields are only partially explained, but the description is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover name and country, but the optional `limit` parameter has no description and the tool description doesn't explain it. The exact-match note relates to output rather than parameter semantics, leaving a moderate gap at ~67% schema coverage.
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?
The description clearly states the tool 'Looks a brand up in Vinted's brand list and returns ranked candidates with their numeric id.' This uses a specific verb, identifies the resource, and describes the output, distinguishing it from siblings like find_category.
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?
The description gives practical guidance: if nothing matches, the item can still be listed with brand unset, and explicitly says 'do not substitute a different brand.' It implies listing use but does not explicitly name alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and open-world, but the description adds valuable context: results are ranked, the response includes id and full path, and the correctness of category selection affects listing visibility. It does not contradict annotations and goes beyond the structured metadata.
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?
The description is three sentences, front-loaded with the main action, and every sentence provides meaningful information—what it does, the leaf-category nuance, and a user interaction guideline. No filler or repetitive content.
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 simple search tool with no output schema, the description sufficiently covers purpose, return value structure, and a critical usage caveat (leaf categories). It lacks detail on ranking criteria or no-result behavior, but given the tool's simplicity and annotation coverage, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, covering query and country with examples. The description adds some context by mentioning the full path and leaf category, which helps interpret output but not the limit parameter. Since the schema already documents most parameters, the description provides marginal additional parameter-level meaning.
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?
The description clearly identifies the tool as a search over the Vinted catalogue tree that returns ranked candidates with numeric id and full path. It distinguishes itself from sibling tools like find_brand by focusing on categories and adds the leaf-category constraint, making the purpose specific and unambiguous.
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?
The description gives clear context for use: when you need a category for a listing, especially highlighting that only leaf categories can hold listings. It provides a behavioral guideline to show top candidates rather than silently pick the first, but does not explicitly compare against alternative tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to cover safety. It adds the useful analogy 'exactly like the site search box' and implies real-time data ('currently on sale'), but it doesn't disclose pagination behavior or result structure beyond what annotations provide. This is decent but not rich behavioral context.
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?
The description is two sentences, front-loaded with the action ('Searches the Vinted catalogue'), and every clause earns its place—purpose, usage context, and sibling alternative. No fluff or redundancy.
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?
The tool has 10 parameters and no output schema, but the description covers the core purpose and the key distinction from a sibling. It doesn't explicitly mention pagination or filtering options, but those are visible in the schema. For a search tool, this is sufficient for an agent to select and invoke it correctly, though a note about result format would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 70%, which is high, so the description needn't compensate for missing parameter docs. The description doesn't mention any parameters, but the schema already covers most of them (query, page, sortBy, country, perPage, brandIds, catalogIds). The schema handles parameter semantics; the description adds no extra value here.
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?
The description clearly states 'Searches the Vinted catalogue, exactly like the site search box', which is a specific verb+resource. It also distinguishes from the sibling 'search_similar_items' by noting the alternative for pricing, so it explicitly differentiates its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: 'Use it to look at what is currently on sale for a given query.' It also gives an exclusion/alternative: 'For pricing a specific item, prefer search_similar_items, which filters out results that are not really comparable.' This is clear when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and openWorldHint. The description adds valuable behavior: stats are computed from listing pages, and the `note` field discloses how much of the shop was actually read. This transparency about the computation method and potential incompleteness goes beyond the annotations.
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?
The description is two sentences with no wasted words. It front-loads the core purpose, then efficiently explains the computational method and the caveat about the note field. Every sentence earns its place.
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?
Given the lack of an output schema, the description adequately enumerates the main returned metrics (active/sold counts, total active value, views, favourites) and mentions the note field for coverage. It also explains the data source and the absence of a native endpoint, providing enough context for an agent to understand the tool's behavior.
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 coverage is 100% for both parameters, setting a baseline of 3. The description enhances the meaning of the 'pages' parameter by linking it to the `note` field, explaining that how many pages read directly affects the coverage of the shop stats. This adds context not present in the schema alone.
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?
The description uses a specific verb 'Aggregates' and clearly identifies the resource as 'the signed-in seller's shop', listing concrete metrics (active/sold counts, total active value, views, favourites). This distinguishes it from sibling tools like my_listings or whoami, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating that Vinted has no stats endpoint, so this tool is the means to obtain shop statistics. However, it does not explicitly state when to prefer this over alternatives or when not to use it. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds value by explicitly stating 'It never clicks publish' and describing the browser interaction. This clarifies the safety boundary and what the tool actually does, though it doesn't disclose details like side effects on the draft or browser state.
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?
Two sentences, front-loaded with the action, and the critical safety guarantee ('It never clicks publish') is bolded. No wasted words; every sentence earns its place.
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?
The description explains the core behavior and return nature ('reports whether it is ready to publish' and 'returned missing/warnings'), which is sufficient for a tool with no output schema. It does not cover failure modes or the screenshot parameter, but the overall usage context is complete enough for an agent to decide when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; draftId has no schema description, but the description references 'from the draft', giving some context. The screenshot parameter has a schema description but is not mentioned in the tool description. The description adds marginal value beyond the schema but does not fully compensate for the undocumented draftId.
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?
The description clearly states the tool's specific function: it opens Vinted's new-listing form, fills it from the draft, and reports readiness. It distinguishes itself from publish_listing by explicitly stating 'It never clicks publish.' This is a specific verb+resource+scope.
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?
It provides clear usage context: 'run it before asking the user for permission to publish' and calls it 'the safe end-to-end check.' It does not name explicit alternative tools, but the timing and purpose are concrete, so this is clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fallback to the public item page when the API is bot-blocked, which is not captured in the readOnlyHint/openWorldHint annotations. It also lists the exact data fields returned, adding useful behavioral context. It does not overexplain, but the disclosed details meaningfully go beyond annotations.
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?
The description is two sentences, front-loaded with the verb and resource, and wastes no words. The first sentence covers the core function and outputs; the second adds a valuable behavioral edge case. Every sentence earns its place.
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 compensates by enumerating the returned fields (title, description, price, brand, size, condition, photos, seller). It also covers the fallback behavior, making the tool's behavior fully understood for a simple fetch operation. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (itemId and country), so the description does not need to add parameter-level detail. The description's mention of 'numeric id' aligns with the schema, but it adds no new semantic value beyond what the schema already states. Baseline 3 is appropriate.
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?
The description opens with the specific verb 'Fetches' and identifies the resource as 'one listing by numeric id', clearly distinguishing this from the sibling search tools that query multiple listings. It concisely enumerates the returned fields, leaving no ambiguity about the tool's function.
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?
The description establishes clear usage context: use this when you have a numeric item id and need the full listing details. It does not explicitly name alternatives or exclusions (e.g., when to prefer search_items), but the purpose is specific enough that the intended use case is implied. A minor omission prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it clearly discloses that nothing is sent to Vinted and nothing is published, that it creates a local draft, and that it performs searches/price estimation/category and brand lookup. This adds significant behavioral context not covered by readOnlyHint/openWorldHint/destructiveHint.
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?
The description is four sentences, front-loaded with 'The main entry point' and ends with the actionable pipeline. It is dense but purposeful, with no filler. A slightly more structured format could improve readability, but it is concise enough.
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 21-parameter tool with no output schema, the description covers the overall workflow, safety guarantees, and next steps. It does not mention optional overrides like price/title/description or the research toggle, but those are already in the schema. Given the high complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 90%, so the schema already documents nearly all parameters. The description only adds general context ('photo paths', 'facts you supplied') and mentions draft outputs, but does not need to elaborate further. Baseline 3 is appropriate.
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?
The description clearly states it is 'The main entry point' and 'creates a local draft' with specific actions: searches comparable listings, estimates a price, looks up category and brand, and writes title and description. This distinguishes it from sibling tools like update_listing_draft, validate_listing, and publish_listing.
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?
It provides explicit workflow guidance: 'Show the returned draft to the user, let them correct it with update_listing_draft, then validate_listing.' It also signals when to use it ('main entry point', 'give it what you can actually see in the photos plus the photo paths'). However, it does not explicitly list when-not-to-use scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, readOnlyHint=false, but the description adds crucial context beyond that: the operation is IRREVERSIBLE, it requires explicit user confirmation, and it turns a draft into a public listing. This goes beyond what annotations convey and warns the agent of the finality.
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?
Two sentences, first is a clear purpose statement, second packs the two critical warnings (IRREVERSIBLE and confirm requirement) plus the prerequisite. Every word earns its place, and the key constraint is front-loaded.
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 simple two-parameter tool with no output schema, the description covers the purpose, prerequisite, safety gate, and the irreversible nature. It does not describe the return value or error cases, but for a publish action the input constraints and consequence are the most important context, which are fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% and the description does not compensate. The confirm parameter's meaning (must be true, after explicit approval) is already fully stated in the schema, so repeating it adds no value. The draftId parameter is not addressed at all beyond its name, and the description provides no additional semantics. Thus it fails to improve parameter understanding.
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?
The description opens with a specific verb and object: 'Publishes a draft as a real, public Vinted listing.' This clearly distinguishes it from sibling tools like validate_listing, which only checks drafts, and update_listing_draft, which edits them. The scope ('real, public') removes any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: after validate_listing has been run, and only after the user has seen the draft and explicitly approved publication. It also gives a hard precondition (confirm: true) and implies the tool is not for editing or previewing. This is clear usage guidance for an irreversible action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds meaningful behavioral context beyond these by explaining the action is reversible and does not delete the listing, which aligns with and expands on the annotations. No contradiction.
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?
The description is a single, front-loaded sentence that wastes no words. It conveys the action, scope, non-destructive nature, and reversibility in minimal space.
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 simple hide operation, the description covers the core behavior, reversibility, and ownership context. It does not detail return values or edge cases, but the absence of an output schema and the simplicity of the tool make this acceptable.
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?
The description implies itemId refers to the user's listing to hide, adding meaning not in the schema. The country parameter is already described in the schema, so the description does not need to repeat it. With 50% schema coverage, the description partially compensates for the undocumented itemId.
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?
The description uses a specific verb and resource: 'Hides one of the user's listings from the catalogue.' It clearly states the action and distinguishes from deleting by noting 'without deleting it' and from reactivation via 'Reversible with reactivate_listing.'
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?
The description provides clear context: it hides rather than deletes, and explicitly names reactivate_listing as the reversal alternative. However, it does not explicitly state when not to use it (e.g., when permanent deletion is desired), so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds valuable behavioral details: ordering (oldest first), the `mine: true` flag for seller's messages, and a warning that message bodies are untrusted external content. These go beyond the readOnlyHint/openWorldHint annotations, revealing the read-only nature and providing security context.
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?
Three short sentences, front-loaded with the main purpose, no redundant wording. Every sentence adds distinct 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?
For a simple read tool with two parameters, the description covers the key aspects: purpose, ordering, seller message marking, and a security warning. The absence of an output schema is mitigated by these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the input parameters (conversationId, country). Country is documented in the schema, but conversationId lacks any description. The `mine: true` mention likely refers to response fields, not request parameters, so it doesn't compensate for the missing parameter documentation.
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?
Description states the tool returns every message in a conversation, oldest first. This clearly distinguishes from sibling tools like 'conversations' (which likely lists conversations) and 'send_message' by focusing on reading messages within a single conversation.
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?
The description provides context that this is for reading a specific conversation's messages, implied by requiring conversationId. It also includes the security guideline about treating message bodies as information. However, it does not explicitly mention alternatives or when not to use, so it's clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds meaningful behavior: it autonomously searches for comparables if not passed, reports a confidence level, and deliberately 'refuses to look precise' with insufficient data. These traits go beyond the annotations and help the agent set expectations.
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?
The description is two sentences,front-loaded with the core function and output list, followed by a necessary caveat. No redundant words or vague jargon; every sentence earns its place.
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?
Given that there is no output schema, the description compensates by detailing the computed statistics and price tiers. It also explains both operating modes and confidence handling. However, it omits the exact response structure (e.g., how confidence is represented) and doesn't explicitly state the return format, so it falls just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so parameters are mostly self-documenting. The description does add slight context by mentioning that 'comparables' should come from search_similar_items, but it doesn't elaborate on other parameters. With high schema coverage, the baseline of 3 is appropriate.
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?
The description clearly states the tool's function with a specific verb ('Turns comparable listings into a price recommendation') and enumerates the exact outputs (count, min, 25th percentile, median, average, 75th percentile, max, quick-sale/recommended/optimistic prices). It is unmistakably distinct from siblings like search_similar_items (which finds comps) and update_price (which sets a price).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides two usage modes: pass comparables from search_similar_items, or pass item facts and let the tool find them. It also gives a clear when-not guideline: 'do not present a low-confidence number as a market price' when there are too few comparables. This is strong usage guidance with alternatives and a caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds valuable context: it removes copied photos as a side effect, scopes the operation to local data, and clarifies the force parameter behavior when a draft was published. This goes beyond the structured annotation data.
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?
Two sentences, directly to the point. The first sentence states the core action, the second adds a crucial boundary and a condition. No wasted words or repetition.
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?
For a simple two-parameter destructive operation with no output schema, the description covers the primary effect, side effects, scope boundary, and a conditional nuance. It is complete enough for an agent to use the tool correctly.
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 coverage is 50% (only 'force' has a description). The description reinforces the meaning of force by stating when it is needed ('Published drafts need force: true'), adding behavioral semantics. 'draftId' is not elaborated, but its meaning is clear from the tool name and description. The description compensates for the incomplete schema.
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?
The description states a clear action ('Removes') on a specific resource ('a local draft and its copied photos'). It explicitly distinguishes from the Vinted platform ('Does not touch anything on Vinted'), which differentiates it from the sibling tool 'delete_listing' and other listing-related tools.
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?
The description communicates this is for local drafts only, and the phrase 'Does not touch anything on Vinted' implies the alternative for Vinted deletions. It also gives a specific condition ('Published drafts need force: true'), which is a clear usage guideline. However, it does not explicitly name the alternative tool, so it misses the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint), the description adds critical behavioral context: the deletion is irreversible, and specifically the item, photos, and stats are permanently gone. It also discloses the confirmation requirement, enriching the annotation-provided safety signal.
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?
The description is compact and well-structured, leading with the primary action, then irreversible consequences, then usage constraint and alternative. Every sentence adds value with no redundancy or fluff.
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?
For a destructive mutation tool with no output schema, the description provides sufficient context: it defines the action, irreversibility, what data is lost, and the mandatory confirmation guardrail, covering the essential aspects an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents confirm and country, and the description adds no substantial new parameter semantics beyond restating the confirm requirement. The itemId parameter remains undocumented in the description, though schema coverage is moderate at 67%.
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?
The description clearly states the tool permanently deletes one of the user's Vinted listings, using a specific verb and resource. It also explicitly distinguishes this from deactivate_listing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (after exact user confirmation) and when-not-to-use guidance, directing users to deactivate_listing for catalogue-only removal. It also specifies the prerequisite that confirm must be true only after explicit user consent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds critical context: 'this cannot be unsent' and 'never send a test message.' This goes beyond the structured annotations to explain real-world consequences, making the tool's irreversible nature explicit.
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?
Two sentences, front-loaded with the core purpose, followed by essential safety instructions. Every clause earns its place; no filler or redundant phrasing.
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?
For a simple send-message tool with no output schema, the description covers the action, the irreversible nature, the confirmation requirement, and the prohibition on test messages. It is fully sufficient for an agent to use this tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents text, confirm, and country. The description reinforces the confirm requirement ('Requires confirm: true', 'get their approval first') but does not add new semantic detail beyond what the schema's property descriptions already state, particularly for confirm. No significant parameter insight is added.
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?
The description starts with 'Sends a message to a real person in a Vinted conversation' — a specific verb and resource that clearly distinguishes it from read-only siblings like read_messages and conversations. The 'real person' qualifier adds important context that this is a human-facing, non-test action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the required confirm:true workflow, instructs the agent to get user approval before sending, and warns that messages cannot be unsent. This provides clear when-to-use and guardrail guidance, effectively excluding casual or test usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, the description adds valuable behavioral context: 'without throwing' indicates error-handling behavior, and it explains the login requirement and explicitly instructs never to ask for the user's password, which is critical safety guidance.
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?
The description is three sentences, front-loaded with the main purpose, and each sentence earns its place: function, usage scenario, and login safety guidance. No waste or redundancy.
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?
For a simple status-checking tool with no mandatory parameters and no output schema, the description is complete. It covers what the tool does, when to use it, what it returns (absent vs expired), and critical login instructions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the 'country' parameter, including its description and default behavior. The tool description adds no new parameter-level details beyond restating the country concept in the login command, so baseline 3 is appropriate.
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?
The description clearly states the tool's function with a specific verb ('Reports') and resource ('usable Vinted session'), and explicitly differentiates it by noting it returns 'absent' vs 'expired' statuses without throwing, which no sibling tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use: 'Use it when a seller tool fails, to tell the user precisely whether they have never logged in or their session lapsed.' This gives clear context and distinguishes it from any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds valuable behavioral context beyond the annotations: specific error codes (NOT_AUTHENTICATED, SESSION_EXPIRED), the return fields, and the agent's limitation ('you cannot log in for them'). This is more than what annotations alone convey.
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?
The description is three sentences, each serving a distinct purpose: what it returns, when to use it, and how to handle failures. It is front-loaded with the core function and contains no redundant wording.
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?
For a simple read-only tool with one optional parameter and no output schema, the description covers all essential aspects: return fields, usage context, failure handling, and user instructions. It is sufficiently complete for an agent to invoke the tool correctly and respond to errors appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the 'country' parameter, including its meaning and default behavior. The description does not add new parameter details beyond what the schema states, so it meets the baseline for high schema coverage without needing to compensate.
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?
The description explicitly states what the tool does: 'Returns the signed-in Vinted account for a storefront' with specific fields (user id, username, item count, reputation). This clearly distinguishes it from sibling tools that handle items, messages, or listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use it first to check the session is alive before any seller operation.' Also gives concrete failure handling instructions and tells the agent to direct the user to a login command, which is actionable and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcpvin MCP server](https://glama.ai/mcp/servers/rachid598/mcpvin/badges/card.svg)](https://glama.ai/mcp/servers/rachid598/mcpvin)

Score Badge

Copy to your README.md:

[![mcpvin MCP server](https://glama.ai/mcp/servers/rachid598/mcpvin/badges/score.svg)](https://glama.ai/mcp/servers/rachid598/mcpvin)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rachid598/mcpvin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server