Real-time product data, semantic search and more from dm-drogerie markt, Europe's leading drugstore.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: findNearbyStores for location-based store search, searchProducts for finding products by query, and getProductDetails for retrieving detailed info by ID. No overlap in their core functions, and the descriptions explicitly clarify when to use which.
All tool names follow a consistent verb_noun camelCase pattern: findNearbyStores, getProductDetails, searchProducts. The naming style is uniform and predictable.
With 3 tools, the server is well-scoped for its apparent purpose of store locator and product information. Each tool covers a distinct need without redundancy or bloat, fitting comfortably within the ideal 3-15 range.
The core workflows are covered: finding nearby stores, searching products, and getting detailed product data. Minor gaps exist, such as lacking a direct store-by-ID lookup, but these can be worked around using existing tools and do not cause dead ends.
findNearbyStoresAFindet 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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 InformationARetrieve 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
| Name | Required | Description | Default |
|---|---|---|---|
| dans | No | DANs (exactly 7 digits, preferred over GTIN) | |
| gtins | No | GTINs (8-14 digits) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint=true and idempotentHint=true, the description adds rich behavioral context: input limits (1-50 IDs), output format (TOON with specific fields), and error handling (validation error for >50 or no identifiers). It also covers how unresolved IDs are represented (found=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into labeled sections (USE WHEN, INPUT, OUTPUT, NOT FOR, ERRORS), making it easy to scan and parse. Every sentence adds value—there is no filler or redundancy, and the structure helps an agent quickly extract the relevant facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers return semantics: it lists the expected fields and explains the found=false behavior for unresolved IDs. It also covers error conditions and explicitly states what the tool is NOT for, which is essential for an agent to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics: combined usage of DANs and GTINs ('and/or'), count limits (min 1/max 50), and the preferred status of DANs over GTINs. These details go beyond the schema and give the agent a fuller understanding of how to use the parameters together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving detailed product information for dm-drogeriemarkt products. It distinguishes itself from the sibling searchProducts by specifying the identifier-based lookup and explicitly listing excluded content (prices, availability, stock, reviews, recommendations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit USE WHEN conditions (ingredients, nutrition facts, allergens, etc.) and NOT FOR exclusions (prices, stock, reviews). It also advises using the search tool when only a product name is known, giving clear guidance on when to choose an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchProductssearchProductsA 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query for dm-drogerie products |
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.
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.
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.
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.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
