dm-drogerie-markt is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the dm-drogerie-markt API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 24/100Comprehension
55% of score · 57/100What we found
- An agent looking for dm can actually find and connect to it: dm ships an OFFICIAL remote MCP server (https://mcp.dm.de/mcp) listed in the official MCP Registry, PulseMCP, and Glama, with copy-paste setup for Claude Code, Claude Desktop, VS Code, and Cursor — a deliberate agent-first bet rare for a bricks-and-mortar retailer.
- The dm MCP landing page is genuinely task-oriented: beyond describing its two tools (Search, Product Details) it publishes a rich gallery of end-user jobs (allergy/ingredient checks, vegan filters, nutrition comparisons, 'dupe' finders) framed as what an agent can accomplish, not just the interface.
- There is NO traditional API discovery layer: no OpenAPI/Swagger spec, no valid llms.txt (dm.de/llms.txt silently returns the SPA homepage HTML), no llms-full.txt, no .well-known/mcp.json, and no AGENTS.md in the dm-drogeriemarkt GitHub org — so any agent expecting standard machine-readable discovery files comes up empty.
- An agent hitting an error is on its own: the docs document zero capability boundaries — no rate limits, no error format, no 'what this API cannot do', and no error-recovery guidance — so limits are discoverable only by failing.
- Documentation is clean and token-efficient: the entire offering is understandable from a single well-structured, cleanly-scrapeable page in well under 5,000 tokens — but it is German-only and thin on per-tool parameter/response detail.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add a valid llms.txt (and ideally llms-full.txt) at mcp.dm.de covering the MCP endpoint, the two tools, and the core product-search flow — this is the single highest-leverage discovery fix and directly lifts both the llmsTxt and llmsTxtQuality checks.
- 02Publish a machine-readable tool/interface reference (an OpenAPI spec for any REST surface, or at minimum a documented JSON schema for the Search and Product Details tool inputs/outputs) so agents get realistic request/response examples with concrete values rather than only natural-language prompt ideas.
- 03Document capability boundaries and error recovery: rate limits, request size limits, the error response shape, and 'if you get X, do Y' guidance for the top failure cases (e.g. no results, malformed query). This is currently the biggest comprehension gap.
- 04Serve a .well-known/mcp.json (and/or fix dm.de/llms.txt so it stops returning the homepage) so standards-based agent discovery resolves cleanly at the domain root.
- 05Add an AGENTS.md to the primary public repo and include the mcp.dm.de docs pages in a sitemap so the agent surface is crawlable and discoverable outside the MCP registries.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
dm exposes an official remote MCP server (https://mcp.dm.de/mcp, streamable-http, no auth required) with two tools — semantic product Search and Product Details. Execution characteristics (error format, rate limits, pagination, idempotency) are not documented; tool schemas are delivered at runtime via the MCP protocol rather than in written docs.