MediaMarkt & Saturn MCP

Overview Schema Source Related Servers Discussions Admin

get_product

Retrieve product details from MediaMarkt or Saturn using an exact product ID or HTTPS product URL, including description, EAN, images, rating, variants, offers, and specifications.

Instructions

Read product details from the product page by exact ID or product URL, including description, EAN, images, rating, variants, linked marketplace offers and specifications where available. Offers are limited to what the page embeds and are not necessarily complete. Returns found=false for a 404 URL or if the requested ID is absent from a redirected product page; this does not prove the product no longer exists.

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": {
      "reference": "<reference>"
    },
    "name": "get_product"
  }
}

Input Schema

Name	Required	Description	Default
`fresh`	No	Bypass the process cache and request current shop data.
`country`	No	Storefront country code. Defaults to de. Product and store IDs are country-specific.	de
`language`	No	Shop language; defaults to the country's main language. Switzerland: de/fr/it; Belgium: nl/fr.
`retailer`	No	Storefront brand: mediamarkt (including MediaWorld in Italy) or saturn (Germany only).	mediamarkt
`reference`	Yes	Exact product ID or HTTPS product URL from the selected retailer. Use search_products for product names.

Output Schema

Name	Required	Default
`cache`	No
`found`	Yes
`reason`	Yes
`country`	No	de
`product`	Yes
`language`	No	de
`retailer`	Yes
`reference`	Yes
`observed_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.0Nov 11, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose key behavior: offers are limited to page embeds and may be incomplete, and found=false has an ambiguous meaning that does not prove the product is gone. That is exactly the kind of caveat an agent needs to avoid over-reporting. It does not mention read-only nature or caching/freshness implications.

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, front-loaded with the action and scope, then the coverage caveat, then the failure semantics. Every sentence adds distinct information with no filler.

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, so return values need not be spelled out, yet the description usefully explains the found=false contract. Combined with full schema coverage of the five parameters, an agent has enough to call it correctly; only the interaction between fresh/caching and cross-country ID specificity is left to the schema.

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 the schema already documents reference, country, language, retailer, and fresh. The description restates the reference format but adds nothing about country-specific IDs, language defaults, or cache bypass beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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?

"Read product details from the product page" states a specific verb and resource, and "by exact ID or product URL" bounds the scope while enumerating the returned data (description, EAN, images, rating, variants, offers, specifications). It stops short of naming search_products as the name-based alternative inside the description itself, leaving that differentiation implicit.

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 reference form (exact ID or HTTPS URL) tells the agent this is not a lookup-by-name tool, and the schema note points to search_products for names. Edge-case guidance is explicit: 404 URLs and IDs missing from redirects yield found=false. No explicit "do not use when" statement or cache/fresh guidance.

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

Deploy Server