MediaMarkt & Saturn MCP

Overview Schema Source Related Servers Discussions Admin

find_stores

Locate MediaMarkt or Saturn stores by city, postal code, or store name in a selected country and language, then use the returned store ID to check pickup availability.

Instructions

Find stores in the selected country and language by location. Choose the intended store ID before checking pickup; do not assume the first result is the right one.

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": {
      "query": "<query>"
    },
    "name": "find_stores"
  }
}

Input Schema

Name	Required	Description	Default
`fresh`	No	Bypass the process cache and request current shop data.
`query`	Yes	City, postal code, or store name in the selected country.
`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

Output Schema

Name	Required	Default
`cache`	No
`count`	Yes
`query`	Yes
`stores`	Yes
`country`	No	de
`language`	No	de
`retailer`	Yes
`observed_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.0Nov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses that multiple results are expected and that ordering should not be trusted ('do not assume the first result is the right one'), but it never states that this is a read-only lookup, nor does it mention caching behavior, which the schema only hints at via the 'fresh' parameter.

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 short sentences with no filler, and the core purpose is front-loaded ahead of the operational warning. Every clause contributes either scope or guidance, with nothing redundant.

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 explained, and all five parameters are fully documented in the schema. What remains thin is the relationship to list_storefronts and the absence of any statement about read-only semantics, which matters for a lookup tool with no annotations.

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 100%, so the schema already documents query, country, language, retailer, and fresh in detail, including country-specific IDs and the Switzerland/Belgium language rules. The description adds only the high-level framing ('selected country and language by location') and no syntax or format detail beyond the schema, making baseline 3 appropriate.

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 specific verb and resource ('Find stores') plus the scoping dimensions (country, language, location), which is enough to distinguish it from search_products or get_product. It does not, however, contrast itself with the closest sibling, list_storefronts, leaving the boundary between 'find stores by location' and 'list storefronts' implicit.

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 second sentence gives real workflow guidance by placing this tool before pickup checking ('Choose the intended store ID before checking pickup'), which implies the downstream dependency on check_pickup_availability. It stops short of stating when not to use it or how it differs from list_storefronts, so usage is implied rather than fully specified.

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

Deploy Server