offerhopper.ai — AI Supermarket & Drugstore Shopping Assistant for Germany

Plan optimal grocery and drug store shopping trip

plan_optimal_shopping_route

Read-onlyIdempotent

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, Globus), 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).

Input Schema

TableJSON Schema

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 candidate stores to evaluate for 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)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 12, 2026

changedInput schema / properties / max_stores / description

Previous value: -"Maximum number of store stops to allow in the route (default: 100)"New value: +"Maximum number of candidate stores to evaluate for the route (default: 100)"

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "type": "string"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

First observedAug 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description substantially expands on the annotations by explaining how the tool works: matching items to offers across named retailers, weighing prices against travel distance and shopping time, and returning store choices plus per-item picks. It also adds crucial pricing semantics, clarifying that 'price' is the shelf price available to all shoppers and what app_credit and app_price mean. This aligns with the readOnlyHint and gives agents useful behavioral context beyond the structured fields.

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 densely informative, with purpose front-loaded and behavioral notes sensibly grouped. The list of store names and the pricing clarification earn their place for agent decision-making. There is a minor formatting issue ('worth-it Supports') that slightly harms polish, but no unnecessary content.

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?

For a complex tool with nine parameters, the description covers the decision criteria, return contents, travel modes, corridor-trip behavior, and pricing semantics. An output schema exists and the parameters are fully documented in the schema, so the description does not need to restate those. The agent has enough context to select 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%, so the baseline is 3, and the description adds value on top by clarifying travel modes ('Supports car, bicycle, and pedestrian travel modes') and the purpose of end_location for corridor trips. It does not re-explain every parameter, which is appropriate given the schema already documents them fully.

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: it plans an optimal shopping trip for a given list and starting location in Germany. It actively differentiates itself from a nearby concern ('not what's on offer near me') and enumerates the exact decision it answers. This makes the tool's purpose unmistakable and distinct from its sibling.

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 gives clear context for when to use the tool: when the user wants to know where to buy a list, whether the trip is worth it, and which route is cheapest. It also gives a conditional usage instruction for corridor trips ('supply end_location'). However, it does not explicitly contrast itself with the sibling swap_route_item, so the when-to-use versus alternatives guidance is strong but not fully explicit.

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

All offerhopper.ai — AI Supermarket & Drugstore Shopping Assistant for Germany tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?