Crawlora MCP

vestiaire_product

Read-only

Fetch public Vestiaire Collective listing detail data from the listing URL or path returned by vestiaire_search; a numeric ID alone is not enough to resolve the page. Use vestiaire_seller for seller information.

Tool call template

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

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

Input Schema

Name	Required	Description	Default
`path`	Yes	Listing URL or path, from a search result's url field

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026
- addedInput schema / properties / path / description
```
Added value: +"Listing URL or path, from a search result's url field"
```
First observedOct 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious behavioral context beyond that: the tool needs a full URL/path, a bare numeric ID will fail, and it returns only public listing data. No permission or rate-limit detail is given, but the input-resolution constraint is the key operational caveat.

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 compact clauses with the action and resource front-loaded, followed by the input constraint and the sibling routing. No filler, and every clause carries actionable 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?

A single-parameter read tool with an output schema, so return values need no explanation. The description covers purpose, input provenance, the ID-vs-URL pitfall, and sibling routing, leaving nothing an agent needs in order to call it 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 100%, so the baseline is 3; the description goes further by specifying that the path value is the url field from a vestiaire_search result and by warning that a numeric ID is insufficient. That materially clarifies what value to put in the single parameter beyond the schema's wording.

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 (fetch) and resource (public Vestiaire Collective listing detail data), and explicitly positions itself against siblings by naming vestiaire_search as the source of the input and vestiaire_seller as the alternative for seller data. An agent can identify this as the listing-detail endpoint without opening any schema.

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 clear preconditioning: the path must come from a vestiaire_search result's url field, and a numeric ID alone will not resolve the page. It also routes seller-related questions to vestiaire_seller. It stops short of explicit when-not-to-use exclusions, but the context is unambiguous.

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

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?