dm-drogerie-markt

Server Details

Real-time product data, semantic search and more from dm-drogerie markt, Europe's leading drugstore.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.8% over 42 days
Last Tested: 2026-09-28 20:20
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.6/5.0

Scored 2026-09-14 14:51 across 5 tools

Disambiguation4/5

Store lookup (findNearbyStores), availability (getStoreAvailability), and product lookup are clearly separated, and getProductDetails vs renderProductTiles are explicitly distinguished by output format (text fields vs visual cards). The three product-oriented tools share the same DAN/GTIN input pattern, which could cause some hesitation, but the NOT FOR clauses and distinct outputs keep boundaries clear.

Naming Consistency5/5

All five tools use consistent camelCase verb+noun naming (findNearbyStores, getStoreAvailability, getProductDetails, renderProductTiles, searchProducts). The verbs accurately reflect each action and follow a single predictable convention.

Tool Count4/5

Five tools is a lean but sensible surface for a retail store/product assistant: store discovery, product search, product detail, availability check, and visual rendering. Nothing feels redundant, though the set is close to the thin end for the breadth of the dm catalog.

Completeness4/5

The core customer journeys are covered: find a store, search products, inspect product details, check store availability, and display product cards. Minor gaps remain (e.g. no direct store lookup by storeId or store detail/hours tool independent of a location search, no online ordering/click-and-collect), but these are workable given the stated scope.

Available Tools

5 tools

findNearbyStoresA

Read-onlyIdempotent

Inspect

Findet dm-Märkte in der Nähe eines Ortes. Erfordert eine eindeutig identifizierbare Ortsangabe (Stadt, Stadtteil, PLZ, Straße mit Stadt oder vollständige Adresse mit Stadt). Bei Straßenname ohne Stadt oder mehrdeutigen Angaben das Tool NICHT aufrufen, sondern Rückfrage stellen. Tool genau einmal pro Anfrage aufrufen. Filter-Args (storeServices_filter, store_open=true) DÜRFEN in einem zweiten Call NICHT entfernt oder gelockert werden — sonst werden dem Kunden Märkte angezeigt, die seine Anforderungen nicht erfüllen (z.B. ein nicht-barrierefreier Markt bei Filter 'barrierefrei', ein geschlossener Markt bei store_open=true). Eine leere oder kurze Ergebnisliste ist die korrekte Antwort, wenn kein Markt das Kriterium erfüllt. Gibt TOON-formatierte Marktdaten zurück (storeId, Name, Adresse, Telefon, Koordinaten, Öffnungszeiten, Ausstattungsmerkmale, Distanz in km). Märkte aufsteigend nach distanceKm sortiert. Das Feld next7Days enthält die effektiven Öffnungszeiten der nächsten 7 Tage ab heute (Zeitzone Europe/Berlin) — inklusive Sonderschließungen (z.B. Feiertage) und Sonderöffnungszeiten (z.B. verkaufsoffener Sonntag), die die Standardzeiten überschreiben. Pro Tag 'Wochentag TT.MM. HH:MM-HH:MM' (mehrere Spannen mit '; ' getrennt) oder 'Wochentag TT.MM. geschlossen'; die Tage sind mit ' / ' getrennt, der erste Tag ist heute. Beispiel: 'Do 18.06. 09:00-20:00 / Fr 19.06. 08:00-20:00 / Sa 20.06. geschlossen'. Fragen zu einem konkreten Wochentag innerhalb der nächsten 7 Tage (z.B. 'Hat der Markt Samstag geöffnet?') aus diesem Feld beantworten. Tage darüber hinaus sind NICHT enthalten — dafür darauf hinweisen, dass nur die nächsten 7 Tage vorliegen. Das Feld amenities listet die offiziellen Bezeichnungen der Ausstattung und Services. Kunden fragen oft mit Marken-, Umgangs- oder Synonymnamen, die davon abweichen — diese auf die amenities abbilden, z.B. ist der 'Sapur' bzw. 'Sapur-Teppichreiniger' als 'Teppichreiniger ausleihen' gelistet. Ist ein passendes Merkmal vorhanden, die Frage bejahen; nur verneinen, wenn kein entsprechendes Merkmal in amenities steht.

ParametersJSON Schema

Name	Required	Description
`location`	Yes	Eindeutige Ortsangabe. Ausreichend: 'Calw', 'Stuttgart Mitte', '76131' (PLZ), 'Bahnhofstraße 5 Karlsruhe'. NICHT ausreichend (Rückfrage stellen): 'Kurpfalzstraße' (Straße ohne Stadt).
`store_open`	No	Nur aktuell geöffnete Märkte zurückgeben
`min_results`	No	Minimale Anzahl zurückgegebener Märkte
`storeServices_filter`	No	Filtert Märkte nach Ausstattungsmerkmal, z.B. 'Stillecke', 'Wickeltisch', 'Parkplätze', 'barrierefrei'. Einmal gesetzt, in Folge-Calls derselben Anfrage beibehalten.

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses rich behavioral details: output format (TOON-format, fields), sorting by distance, next7Days semantics including special opening hours and holidays, and amenity synonym mapping. It even clarifies that an empty result is correct. This goes far beyond annotation implications.

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 long but structured logically: purpose, prerequisites, constraints, output format, special field semantics. It front-loads the main purpose and then provides necessary operational details. Some sentences are dense but none are fluff. It earns its length given the lack of an output schema.

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 fully specifies return values (TOON-format, fields, sorting) and handles edge cases (ambiguous location, empty results, days beyond 7, synonym mapping). Combined with annotations, the tool is completely specified for an agent to invoke 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 adds crucial context beyond schema: location disambiguation rules, the correct handling of filter persistence ('DÜRFEN NICHT entfernt oder gelockert werden'), and that store_open=true tightens results. These are not in the schema descriptions, so the description adds meaningful value.

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 'Findet dm-Märkte in der Nähe eines Ortes' — a specific verb ('findet') and resource ('dm-Märkte in der Nähe eines Ortes'). It clearly distinguishes from siblings (getProductDetails, searchProducts) which deal with products, not store locations.

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 explicit when-to-use (eindeutig identifizierbare Ortsangabe) and when-not-to-use (Straße ohne Stadt oder mehrdeutige Angaben → Rückfrage stellen). It also instructs calling exactly once and preserving filters in subsequent calls. However, it doesn't name alternative tools; the differentiation is implicit via sibling names.

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

getProductDetailsGet detailed Product InformationA

Read-onlyIdempotent

Inspect

Retrieve detailed product information for dm-drogeriemarkt products.

USE WHEN: ingredients, nutrition facts, allergens, usage instructions, warnings, hazard info, product URLs/images

INPUT: DANs (7 digits, preferred) and/or GTINs (8-14 digits) multiple products can be requested at once min 1 / max 50. Use search tool first if only product name is known.

OUTPUT: TOON format (compact YAML-like). Fields: name, brand, description, ingredients, nutrition, allergens, usage, warnings, URLs, images. found=false for unresolved IDs.

NOT FOR: prices, availability, stock, reviews, recommendations

ERRORS: validation error if >50 or no identifiers

ParametersJSON Schema

Name	Required	Description	Default
`dans`	No	DANs (exactly 7 digits, preferred over GTIN)
`gtins`	No	GTINs (8-14 digits)

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: output format (TOON, compact YAML-like), the found=false flag for unresolved IDs, error conditions (>50 identifiers or none), and the request limit (min 1 / max 50). This is substantive behavioral disclosure that helps an agent predict outcomes.

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 well-structured with labeled sections (USE WHEN, INPUT, OUTPUT, NOT FOR, ERRORS). It is front-loaded with the purpose and delivers a lot of actionable information in a compact, scannable format. No redundant sentences or fluff; each section 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?

There is no output schema, so the description must explain the return format — it does, via the TOON format and enumerated fields, plus the found=false failure mode. It also covers input constraints (DAN/GTIN lengths, count limits) and error handling. Combined with the annotations, everything an agent needs to invoke this tool correctly is present.

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 description coverage is 100% — both parameters (dans, gtins) have descriptive text including digit length and preference. The description adds the rule that multiple products can be combined (min 1 / max 50), which is not present in the schema, and clarifies the 'and/or' relationship between the two parameter groups. This goes beyond repeating schema info, though it could have included examples of valid input formats.

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 specific verb and resource ('Retrieve detailed product information for dm-drogeriemarkt products') and enumerates the exact kind of data it returns (ingredients, nutrition, allergens, etc.). It also explicitly lists what it is NOT for (prices, availability, stock, reviews, recommendations), distinguishing it from sibling tools like searchProducts and findNearbyStores.

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 gives an explicit 'USE WHEN' list of use cases and a 'NOT FOR' list of exclusions. It further instructs to 'Use search tool first if only product name is known', directly routing the agent to the appropriate sibling. This is explicit when-to-use and when-not-to-use guidance with an alternative.

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

getStoreAvailabilityGet in-store product availabilityA

Read-onlyIdempotent

Inspect

        Check whether one or more dm-drogeriemarkt products are available in one or more
        specific stores right now.

        USE WHEN: you need to know if one or more products can currently be bought in one or
        more particular physical stores.

        INPUT: one to five storeIds and one to ten DANs (dm product numbers).

        OUTPUT: for each requested DAN, whether it was found and a status per requested
        storeId - VERFUEGBAR (available, includes current stockLevel), NICHT_VERFUEGBAR (not
        available in this store right now), NUR_ONLINE (this product is not carried in ANY
        dm store, not just this one), PRODUKT_UNBEKANNT (DAN not found), or STORE_UNBEKANNT
        (storeId does not exist in our system).

        IMPORTANT: NUR_ONLINE means the product itself is never sold in physical dm stores -
        it will be the same result for every store. Do not check other or nearby stores for
        that product; tell the customer it is online-only right away.

        IMPORTANT: storeIds MUST come from the findNearbyStores tool - call it first to
        resolve the storeId(s) for a location. Never invent, guess, or otherwise make up a
        storeId yourself; a made-up storeId will come back as STORE_UNBEKANNT instead of a
        real availability answer.

        IMPORTANT: if a customer asks about availability for several products, pass ALL of
        their DANs (up to 10) into this single call. Never assume, infer, or extrapolate the
        availability of a product you have not included in a call and gotten a result for -
        not even from a similar or already-checked product, and not even for "usually
        available" items. When reporting back, state the result for every single product
        individually (e.g. one line per product) - never collapse multiple products into one
        summary statement such as "all of them are available".

        TIP: if a product's result is NUR_ONLINE, or it is NICHT_VERFUEGBAR and you already
        know from an earlier product lookup that it is available online, suggest buying it
        online instead and include a link to the product page if you have one.

        NOT FOR: click & collect / express pickup or same-day delivery eligibility (not covered
        by this tool), or repeatedly polling a store's stock over time.

        ERRORS: validation error if any DAN is invalid, dans is empty, more than 10 dans are
        given, storeIds is empty, or more than 5 storeIds are given.

ParametersJSON Schema

Name	Required	Description	Default
`dans`	Yes	DANs (dm product numbers) (1-10)
`storeIds`	Yes	Store IDs of the physical dm stores (1-5)

TDQS

A4.9/5.0

Behavior5/5

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

The description thoroughly explains output statuses (VERFUEGBAR, NICHT_VERFUEGBAR, NUR_ONLINE, etc.) and their meanings, including nuanced cases like NUR_ONLINE being store-independent. It also describes error conditions and required workflow (call findNearbyStores first), going well beyond what annotations provide.

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 well-structured with clear sections (USE WHEN, INPUT, OUTPUT, IMPORTANT, NOT FOR, ERRORS). However, it is somewhat lengthy and repeats similar warnings about not extrapolating results, which could be more concise.

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?

Given the absence of an output schema, the description fully explains return values and their meanings, error conditions, and the necessary workflow. It covers all aspects an agent needs to invoke and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds crucial constraints: storeIds must come from findNearbyStores, and dans are dm product numbers with limits (1-5 storeIds, 1-10 dans). It also emphasizes passing all products in one call rather than making separate requests.

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 specific verb (check availability), resource (dm-drogeriemarkt products), and scope (specific stores, right now). It clearly distinguishes itself from siblings like findNearbyStores, which is named as a prerequisite.

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 USE WHEN and NOT FOR sections, identifies the required alternative (findNearbyStores), and warns against misuse such as inventing storeIds or assuming product availability.

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

renderProductTilesShow Products as CardsA

Read-onlyIdempotent

Inspect

Retrieve dm-drogeriemarkt products and render them as a visual card grid (product image, brand, name, link to the product page).

USE WHEN: the user wants to see products, an overview of several products, or a picture/link instead of a text description

INPUT: DANs (7 digits, preferred) and/or GTINs (8-14 digits) multiple products can be requested at once min 1 / max 50. Use search tool first if only product name is known.

OUTPUT: card grid rendered by the host. found=false for unresolved IDs.

NOT FOR: ingredients, nutrition facts, allergens, warnings - the cards do not show them, use getProductDetails for those. Not for prices, availability, stock, reviews, recommendations.

ERRORS: validation error if >50 or no identifiers

ParametersJSON Schema

Name	Required	Description	Default
`dans`	No	DANs (exactly 7 digits, preferred over GTIN)
`gtins`	No	GTINs (8-14 digits)

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds important behavioral context beyond annotations: output is a host-rendered card grid, unresolved IDs yield found=false, and validation errors occur for >50 or no identifiers. This is valuable and consistent with 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 organized into clear labeled sections (USE WHEN, INPUT, OUTPUT, NOT FOR, ERRORS), with each line carrying actionable information. It is longer than average, but every section contributes to correct tool selection and invocation, making it efficient for its purpose.

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?

Given the tool's moderate complexity and lack of output schema, the description covers all key aspects: input constraints, output format, failure semantics for unresolved IDs, validation limits, and alternative tools. An agent can decide when and how to call this tool without ambiguity.

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 input schema already documents parameters with digit constraints and preference, and coverage is 100%. The description adds extra semantics: minimum 1 / maximum 50 products, both DAN and GTIN can be used together, and validation error conditions. This enhances schema-only knowledge.

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 retrieves dm-drogeriemarkt products and renders them as a visual card grid with specified fields (image, brand, name, link). It differentiates itself from siblings by explicitly excluding ingredients, prices, and other details that belong to getProductDetails.

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 provides explicit USE WHEN and NOT FOR guidance, including when to prefer searchProducts if only a product name is known. It names the alternative tool (getProductDetails) for excluded use cases, making selection unambiguous.

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

searchProductssearchProductsA

Read-onlyIdempotent

Inspect

	Search for products available in the German dm-drogerie market (online and local stores).

	USE WHEN: searching dm-drogerie products by name, category, ingredient, property, or any
	natural language query (any language supported). Often answers questions about
	ingredients and properties directly. Covers: dm-drogerie markt brands, make-up,
	skincare, perfume, hair, health, nutrition, baby & child, household, home & living,
	photo, and pets.

	OUTPUT: Returns a maximum of 15 products. GTIN, DAN, brand, title, details, category,
	price, appLink (direct product URL), description, highlights/USPs, and extensive
	attributes including:
	- Dietary/Allergen: vegan, vegetarian, bio, glutenFree, lactoseFree, sugarFree,
	  nutFree, soyFree
	- Cosmetic Ingredients: fragranceFree, alcoholFree, parabenFree, sulfateFree,
	  preservativeFree, dyeFree, oilFree, siliconeFree, naturalCosmetics
	- Product Properties: waterproof, new, limitedEdition, sellout, onlineOnly,
	  exclusiveDm, dmBrand, purchasable

	NOT FOR: nutritional information (calories, protein, carbs, fats), complete allergen
	lists, full ingredient details. For these, use 'getProductDetails' tool with
	the GTINs or DANs.

	LIMITATIONS: Only make claims based on EXPLICITLY stated product highlights/descriptions.
	Do NOT extrapolate or assume properties not mentioned in the results.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search query for dm-drogerie products

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: a maximum of 15 products returned, detailed output structure, and a critical limitation instructing agents to only make claims based on explicitly stated product highlights and not extrapolate. This is significant and does not contradict 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 well-structured with clear sections (USE WHEN, OUTPUT, NOT FOR, LIMITATIONS), front-loaded with the core purpose, and every section earns its place. It is longer than average but appropriately so given the tool's complexity and absence of an output schema.

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?

There is no output schema, so the description must explain return values. It does this thoroughly, listing output fields (GTIN, DAN, brand, title, etc.) and extensive attribute categories. It also covers limitations and sibling-tool differentiation, making it highly complete for an agent to understand and invoke 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 100% but the schema description for 'query' is generic. The tool description enriches the parameter meaning by specifying that the query accepts natural language, any language, and can target name, category, ingredient, property, etc. This goes beyond the schema's 'The search query for dm-drogerie products'.

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 verb+resource+scope: 'Search for products available in the German dm-drogerie market.' It also distinguishes from the sibling tool getProductDetails by explicitly stating what it is NOT for and pointing to the alternative, making the purpose unmistakable.

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 provides explicit 'USE WHEN' conditions (searching by name, category, ingredient, property, or natural language) and 'NOT FOR' exclusions (nutritional info, complete allergen lists, full ingredient details) with a direct pointer to getProductDetails. This fully covers when to use versus alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 14, 2026
- ChangedgetStoreAvailability1 field changed
  - addedInput schema / $schema
```
Added value: +"https://json-schema.org/draft/2020-12/schema"
```
2 tool updatesSep 9, 2026
- AddedgetProductDetails
- AddedrenderProductTiles
2 tool updatesSep 9, 2026
- RemovedgetProductDetails
- RemovedrenderProductTiles
1 tool updateSep 3, 2026
- AddedgetStoreAvailability
1 tool updateAug 28, 2026
- AddedrenderProductTiles
1 tool updateAug 27, 2026
- ChangedgetProductDetails1 field changed
  - addedInput schema / $schema
```
Added value: +"https://json-schema.org/draft/2020-12/schema"
```
1 tool updateAug 12, 2026
- AddedfindNearbyStores

Related MCP Connectors

offerhopper.ai — AI Supermarket & Drugstore Shopping Assistant for Germany A
ai.offerhopper.mcp
Live prices, deals & optimal multi-stop shopping routes for German grocery & drug stores.
E-commerce & Retail Location Services
21
Shoptera Product Intelligence A
io.github.shoptera-ai
Search ~8.5M products from 2,500+ Central European e-shops. Semantic, keyword, GTIN lookup.
E-commerce & Retail Search RAG Systems
2
Agent Utilities Hosted A
dev.workers.agent-utilities.agent-utilities
Product identity, pack sizes and feed/page checks. Free small trials; paid calls from $0.0003.
E-commerce & Retail App Automation
481
glowjakt A
se.glowjakt
Nordic beauty price comparison: 500k+ EAN-matched products, 70+ stores, true landed-cost pricing.
E-commerce & Retail Search Web Scraping
71

Related MCP Servers

Czech DIY Retail MCP Server
E-commerce & Retail Web Scraping
uskaritel
A
license
A
quality
C
maintenance
Enables searching products, retrieving product details, listing stores, checking stock availability, and comparing prices across Czech DIY retailers.
Updated a month ago (2026-08-30 19:48 UTC)
5
MIT
Shoptera Product Intelligenceofficial
E-commerce & Retail Search
shoptera-ai
A
license
Not graded
quality
D
maintenance
Search product catalogs across thousands of Central European e-shops. Semantic search, keyword matching, GTIN/EAN lookup — via REST API or MCP. \~2,500 e-shops | ~8.5M products | 7 countries (CZ, SK, PL, HU, RO, DE, AT)
Updated 5 months ago (2026-04-15 13:49 UTC)
MIT
idealo MCP Serverofficial
E-commerce & Retail Search
idealo
A
license
Not graded
quality
F
maintenance
Enables product search, price comparison, and price history analysis across 6 European marketplaces (DE, AT, GB, FR, IT, ES).
Updated 4 months ago (2026-05-20 10:01 UTC)
19
MIT
ShopGraph
E-commerce & Retail Web Scraping Payments & Billing
laundromatic
A
license
A
quality
B
maintenance
Structured product data from the open web — where platform APIs don't reach. Schema.org + AI extraction. Pay per call via Stripe MPP.
Updated 3 months ago (2026-06-30 03:34 UTC)
2
41 npm
3
Apache 2.0