wosneaker.de Preisvergleich

Partner-Angebot auf wosneaker.de nachschlagen / look up offer

lookup_product

Read-onlyIdempotent

Schlaegt ein Partner-Angebot aus search_offers per Produkt-ID (externalId) nach. EN: Looks up a partner offer from search_offers by its ID (externalId). Read-only.

Input Schema

Name	Required	Description
`id`	No	Produkt-ID / product ID (externalId aus search_offers).
`url`	No	Alternativ eine Produkt-URL / product URL (optional).
`language`	No	Antwortsprache / response language (de\|en). Default: Accept-Language, sonst de.

Output Schema

Name	Required	Description
`site`	No
`count`	Yes
`query`	No
`facets`	No	Verfuegbare Filter-Werte (Marke + domain-spezifische Attribute) mit Trefferzahlen — zum gezielten Nachfiltern via query/brand/minPrice/maxPrice.
`products`	Yes
`updatedAt`	No
`disclosure`	No
`catalogVersion`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

changedInput schema / properties / id / description

Previous value: -"Produkt-ID: Amazon-ASIN oder externalId."New value: +"Produkt-ID / product ID (externalId aus search_offers)."

addedInput schema / properties / language

Added value: +{
+  "description": "Antwortsprache / response language (de|en). Default: Accept-Language, sonst de.",
+  "enum": [
+    "de",
+    "en"
+  ],
+  "type": "string"
+}

changedInput schema / properties / url / description

Previous value: -"Amazon-Produkt-URL (z.B. https://www.amazon.de/dp/B0ABC123DE) — die ASIN wird extrahiert."New value: +"Alternativ eine Produkt-URL / product URL (optional)."

Changed5 schema fields changedJul 7, 2026

addedOutput schema / properties / facets

Added value: +{
+  "description": "Verfuegbare Filter-Werte (Marke + domain-spezifische Attribute) mit Trefferzahlen — zum gezielten Nachfiltern via query/brand/minPrice/maxPrice.",
+  "type": "array"
+}

addedOutput schema / properties / products / items / properties / attributes

Added value: +{
+  "description": "Domain-spezifische Filter-Attribute, z.B. {farbe, watt, speicher, reichweite}.",
+  "type": "object"
+}

addedOutput schema / properties / products / items / properties / brand
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / products / items / properties / detailUrl

Added value: +{
+  "description": "Zitierfaehige Produktseite mit Preisverlauf.",
+  "type": "string"
+}

addedOutput schema / properties / products / items / properties / priceStats / description
```
Added value: +"30-Tage-Preisstatistik (avg/min/max, isLowest30d)."
```

First observedJul 6, 2026

TDQS

B3.2/5.0

Behavior2/5

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

The only behavioral claim is 'Read-only', which merely restates the provided readOnlyHint=true (and idempotentHint/openWorldHint=false are not addressed). With annotations already covering the safety profile, the description adds nothing new about caching, rate limits, or what happens when the offer no longer exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is short and front-loaded, but the German sentence is immediately restated verbatim in English, doubling length without adding information. Roughly half the text is redundant duplication.

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?

An output schema exists and annotations fully cover the read-only/idempotent profile, so the description need not explain return values. For a simple two-way lookup the remaining gap is only the absent guidance on whether id or url must be supplied.

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 100%, so all three parameters (id, url, language) are already documented, including the externalId origin and the language default. The description only echoes the externalId link for id and says nothing about choosing between the id and url alternatives, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('looks up a partner offer') and ties it to the sibling search_offers as the source of the externalId, so an agent can distinguish lookup from search. It stops short of a crisper contrast statement, but the purpose is unambiguous.

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 phrase 'aus search_offers' hints at the sequence search-then-lookup, but there is no explicit when-to-use, when-not-to-use, or rule for choosing lookup_product over re-running search_offers or find_pages. Usage is implied rather than stated.

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

All wosneaker.de Preisvergleich 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?