Live prices, deals & optimal multi-stop shopping routes for German grocery & drug stores.
plan_optimal_shopping_route creates a new route from a shopping list, while swap_route_item modifies an existing route by exchanging one offer. Their inputs and outputs are distinct, and the descriptions clearly frame the create-vs-adjust relationship.
Both tools follow a clear snake_case, verb-first naming pattern: plan_optimal_shopping_route and swap_route_item. The route concept appears consistently in both names, and there is no mixing of conventions or vague verbs.
Two tools is on the low end of the typical range, but the pair covers the core route-planning and route-adjustment workflow without redundancy. It is slightly under-scoped rather than bloated, so the count remains reasonable.
The plan-and-swap loop covers the primary use case end-to-end, including alternatives, route recomputation, and share_url updates. Minor gaps exist if a user wants broader offer browsing or multi-item edits without re-planning, but these are workarounds rather than dead ends.
Plans the optimal shopping trip for a given list and starting location in Germany. Answers 'where should I go to buy this list, and is the trip worth it?' — not 'what's on offer near me'. Matches each item on the list to the best current offer across German supermarkets and drug stores (REWE, Aldi, Lidl, Penny, Netto, Norma, Edeka, DM, Rossmann, Mueller), then computes the cheapest realistic route by weighing product prices against travel distance and shopping time. Returns the chosen store(s), the per-item picks with live prices, the trip's savings and a worth-it Supports car, bicycle, and pedestrian travel modes. For corridor trips (A-to-B), supply 'end_location' to route stores along the way. Pricing note: 'price' is the standard shelf price available to all shoppers (do NOT say discounts require an app). 'app_credit' is optional wallet cashback (e.g. REWE Bonus: plus €0.50 into wallet). 'app_price' is an app-exclusive checkout price (e.g. Lidl Plus).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | The shopping list in natural language (e.g. '3x milk, eggs, bread') | |
| km_cost | No | Travel cost penalty per kilometer (forced to 0.0 for bicycle/pedestrian) | |
| location | Yes | Starting location (ZIP code, city, or address in Germany) | |
| hour_cost | No | Time cost penalty in EUR per hour (defaults to 12.0) | |
| max_stores | No | Maximum number of store stops to allow in the route (default: 100) | |
| travel_mode | No | Travel mode to use | car |
| end_location | No | Optional destination location if not a round trip | |
| max_radius_km | No | Maximum search radius in kilometers (defaults: car=15km, bicycle=5km, pedestrian=2km) | |
| shopping_time_per_store | No | Base shopping minutes spent per store (defaults to 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, open-world, and non-destructive. The description adds that it compares live offers across named chains, weighs price against distance and time, returns per-item picks/savings/worth-it, and clarifies price vs app_credit vs app_price semantics with an explicit instruction not to claim discounts require an app. This goes well beyond the 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 front-loads purpose and packs dense, relevant detail: store list, travel modes, pricing semantics. It is slightly long and has a run-on/typo around 'worth-it Supports', but each clause contributes actionable information.
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 9 parameters and an output schema, the description is complete enough: it covers what is returned, pricing field meanings, travel modes, and the corridor-trip case. It leaves parameter details to the schema and does not omit any critical usage behavior.
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 meaning beyond the schema by instructing to supply 'end_location' for corridor trips and by noting supported travel modes, which map to the travel_mode parameter. It does not describe every parameter, but the schema already covers them.
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 uses a specific verb ('Plans', 'Matches', 'computes') and resource ('optimal shopping trip') and scopes to German supermarkets and drug stores. The explicit 'not what's on offer near me' disambiguates from a nearby-offers search. It clearly communicates what the tool does and what it does not do.
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?
It states the tool answers 'where should I go to buy this list, and is the trip worth it?' and gives a concrete trigger ('given a list and starting location'). It provides an exclusion ('not what's on offer near me') and an edge-case instruction (use end_location for corridor trips), but it does not name the sibling swap_route_item or explicitly differentiate when to choose that tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Swaps one item's chosen offer on an existing shopping route (from a prior plan_optimal_shopping_route result) for one of its alternatives, then returns the RECOMPUTED route with corrected costs and the honest worth-it verdict. Use this to correct a poor pick (e.g. the engine matched a soup hen instead of a roasting chicken) or to take a cheaper/better option the agent spotted in the item's 'alternatives'. The alternative may be at the SAME store or at ANOTHER store ALREADY ON THE ROUTE — it must be the same item category, and its store must already be a stop (no new stores; for that, call plan_optimal_shopping_route again). Keys on stable offer ids: pass the current item's offer_id and the target alternative's offer_id (both taken verbatim from the prior response's products_to_buy / alternatives). The shared route (share_url) is updated in place so the interactive map reflects the swap.
| Name | Required | Description | Default |
|---|---|---|---|
| share | Yes | The share_url (or its 8-char id) returned by plan_optimal_shopping_route | |
| alt_id | Yes | offer_id of the alternative to swap in (from that item's 'alternatives') | |
| offer_id | Yes | offer_id of the item currently on the route (from products_to_buy) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals important behaviors: the route is recomputed with corrected costs, the shared route 'is updated in place so the interactive map reflects the swap,' and swaps key on stable offer IDs. It also clarifies constraints such as same item category and no new stores.
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 detailed yet efficient; each sentence adds necessary information about purpose, use cases, constraints, IDs, or side effects. Core behavior is front-loaded, with supporting details arranged logically.
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?
The description fully equips an agent to invoke the tool correctly: it explains prerequisites, input provenance, constraints, side effects, and return value. Given the output schema and sibling signal, nothing essential is missing.
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 description adds significant semantic context: offer_id comes from products_to_buy, alt_id from the item's alternatives, and share is the share_url returned by plan_optimal_shopping_route. It even instructs to take IDs 'verbatim from the prior response,' reducing ambiguity.
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?
States a specific verb, resource, and outcome: 'Swaps one item's chosen offer on an existing shopping route ... for one of its alternatives, then returns the RECOMPUTED route.' It clearly distinguishes itself from plan_optimal_shopping_route by scoping to existing routes and prior results.
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?
Explicitly says when to use it: 'correct a poor pick' or 'take a cheaper/better option' from alternatives. It also gives a clear exclusion: the alternative's store must already be a stop, and if a new store is needed, 'call plan_optimal_shopping_route again.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
swap_route_itemplan_optimal_shopping_routeClaiming 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.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Where to buy a whole grocery list today: local prices, per-unit and cross-store comparison.
Turn any shopping list into a ready-to-checkout grocery cart across 26 European supermarkets.
Shopping search across 100M+ products, with every retailer's offer and live price in one place.
Live Dutch supermarket prices and promotions (Albert Heijn, Jumbo, Lidl, Aldi and more) for AI.
