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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-07 15:55
Transport: Streamable HTTP
URL

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

A5/5.0

Behavior5/5

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

Annotations already mark the tool readOnly, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: what each status means (especially NUR_ONLINE being store-independent), that made-up storeIds yield STORE_UNBEKANNT, that availability must not be extrapolated across products, and that stockLevel is included in VERFUEGBAR.

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 long but every section earns its place: USE WHEN, INPUT, OUTPUT, IMPORTANT, TIP, NOT FOR, ERRORS. It is front-loaded with the core purpose, and the structured sections make the density navigable rather than rambling.

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 documents the return statuses and their meanings, including stockLevel and the NUR_ONLINE caveat. It also enumerates validation error conditions, prerequisite tool usage, and post-result recommendation behavior, making the tool safely callable end-to-end.

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?

Schema coverage is 100%, but the description adds meaning the schema lacks: valid count ranges (1-5 storeIds, 1-10 DANs), the rule that storeIds must be resolved via findNearbyStores, and how invalid or unknown parameter values map to output statuses. This goes well beyond the schema's terse property descriptions.

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 a specific verb-resource statement: 'Check whether one or more dm-drogeriemarkt products are available in one or more specific stores right now.' It clearly distinguishes itself from siblings by defining its scope, and the 'NOT FOR' line explicitly rules out adjacent use cases like click & collect.

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' guidance, states what it is 'NOT FOR', and gives a hard prerequisite: storeIds MUST come from findNearbyStores and must never be invented. It also instructs when to suggest online buying instead, giving the agent concrete decision rules.

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. Dates show when Glama detected each change.

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

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

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
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
shelfatlas-catalog
io.github.SlambertDK
Danish grocery catalog as MCP tools: live offers across all major chains, stores, EAN lookup, stock.
E-commerce & Retail Search
1

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 8 days 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)
16
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 2 months ago (2026-06-30 03:34 UTC)
2
41
3
Apache 2.0

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation4/5

Each tool has a clear primary purpose: searching products, retrieving detailed product info, rendering product cards, finding nearby stores, and checking in-store availability. Minor overlap exists between searchProducts and getProductDetails on ingredient-level answers, but the descriptions clearly delineate full ingredient/allergen details from highlighted attributes.

Naming Consistency5/5

All tool names follow a consistent verb-noun camelCase pattern (findNearbyStores, getProductDetails, getStoreAvailability, renderProductTiles, searchProducts). The verbs vary but are appropriate to each action, and there is no mixing of naming styles or conventions.

Tool Count5/5

Five tools is a well-scoped count for a retail/drugstore information server. Each tool covers a distinct need—search, product details, visual presentation, store location, and availability—without redundancy or unnecessary bloat.

Completeness4/5

The tool set covers the core retail information workflows: searching, full product details, visual product tiles, nearby store lookup, and in-store stock checks. Minor gaps exist (e.g., no direct store lookup by storeId alone, no click-and-collect or ordering support), but these are outside the clearly stated scope of the server.

Resources

Need Help?

Server Details

Available Tools

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Shoptera Product Intelligenceofficial

idealo MCP Serverofficial

Glama MCP Gateway

Resources