Cheapest Grocery Basket

Server Details

Where to buy a whole grocery list today: local prices, per-unit and cross-store comparison.

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-12 10:49
Transport: Streamable HTTP
URL

TDQS

A3.9/5.0

Scored 2026-09-09 18:16 across 5 tools

Disambiguation3/5

price_basket and cheapest_basket both address the same shopping-list task and could easily be confused, though cheapest_basket is positioned as the more comprehensive superset. find_product is clearly distinct, and demand_report/request_data are not confusable with the grocery tools but feel like a different domain.

Naming Consistency4/5

Most tools follow a clear lower_snake_case verb_noun pattern like find_product, price_basket, and request_data. cheapest_basket and demand_report break that pattern as noun phrases, but the names are still specific and predictable enough to navigate.

Tool Count4/5

Five tools is a reasonable, focused count for a grocery comparison service. The two free demand/data-request tools broaden the scope beyond the server's apparent purpose but do not make it bloated.

Completeness4/5

The server covers the core shopper journey: single-item lookup, full-basket pricing, and multi-store optimization with substitutes. It lacks a store or category listing tool, but that is not a clear dead end for answering 'where should I buy this list?'.

Available Tools

5 tools

cheapest_basketCheapest way to buy a whole list, including splitting storesAInspect

The complete buying decision for a shopping list: the cheapest single store that can fill it, AND the cross-store optimum that buys each line wherever it is cheapest, with the dollar savings between them and how many stops that costs. Every line carries substitutes at the other stores with the exact extra cost of choosing them, so a shopper can collapse a two-stop trip into one and see precisely what that convenience costs. Out-of-stock items are skipped in favour of an in-stock option even when it is dearer. Use this as the default for "where should I buy this list today" — it is the one call that answers the whole question. Costs $0.02 USDC per call via x402 on Base.

ParametersJSON Schema

Name	Required	Description
`zip`	Yes	5-digit US ZIP code, e.g. '30501'.
`mode`	No	Optional fulfillment intent: 'pickup' or 'delivery'.
`items`	Yes	Comma-separated shopping list, optionally with quantities, e.g. 'milk x2, eggs, bread, butter, cheese'. A JSON array of {name, quantity} is also accepted.
`stores`	No	Optional comma-separated chains the shopper is willing to visit, e.g. 'aldi,publix'.
`maxAgeDays`	No	Optional freshness limit in days (default 14, max 120). A price read longer ago than this is withheld rather than returned as if current; raise it to accept older readings.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key behaviors: it computes both single-store and cross-store optima, reports savings and stop count, provides substitutes with extra cost, skips out-of-stock items in favor of in-stock even if dearer, and notes a per-call cost of $0.02 USDC. This is substantial behavioral coverage.

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 a bit long but every sentence adds value: it covers purpose, output details, substitution logic, out-of-stock handling, usage guidance, and cost. The core purpose is front-loaded, and the structure is logical. It could be slightly tightened but is appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex optimization tool with no output schema, the description explains what it returns (savings, stop count, substitutes with costs) and its behavior. It mentions cost and out-of-stock handling. It does not detail the exact response structure or error handling, but it gives enough for an agent to understand what to expect and call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with descriptions for all five parameters, so the baseline is 3. The main description does not add new parameter semantics beyond what the schema gives; it only refers to 'shopping list' and 'stores' which are already documented. It adds context about what the tool does with the parameters but not new meaning.

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 very specific verb and resource: it computes the cheapest single store and the cross-store optimum for a shopping list, with savings and stop count. It clearly differentiates itself from siblings by positioning as 'the one call that answers the whole question' and 'the default for where should I buy this list today', making it unmistakable.

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?

It explicitly tells when to use this tool ('Use this as the default for where should I buy this list today') and implies it is the comprehensive option. It does not explicitly name alternatives or exclusions, but the default and 'one call' phrasing provides clear context for when it is the right choice.

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

demand_reportWhat agents are asking for most (free)AInspect

FREE, no payment. The aggregate of what agents have told us they are looking for, most-requested first, with the categories nothing available yet serves. Useful if you are deciding what to build or sell into the agent economy.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Window in days, default 30, max 90.

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses that the tool is free, returns aggregated demand data sorted by most-requested first, and covers underserved categories. It does not mention authentication, rate limits, data freshness, or output structure, but for a simple read-only report it provides reasonable behavioral context.

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 short and front-loaded with the most important fact: it is free. The second sentence covers content and use case. Minor redundancy exists because the title already says '(free)' and the description repeats 'FREE, no payment,' but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple report tool with one optional parameter and no output schema, the description gives enough context: what the report contains, how it is ordered, and when to use it. It does not detail the exact output format, but the description provides a workable mental model for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single optional parameter 'days' is already fully documented in the schema with default and maximum. The description adds no additional parameter-level meaning, which is acceptable given the baseline of 3 for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool provides: an aggregate of what agents are looking for, most-requested first, including categories with no current supply. The title reinforces this as a free demand report. It is not as explicit as naming a distinct sibling, but it is unambiguous enough to be understood.

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 a concrete use case: "Useful if you are deciding what to build or sell into the agent economy." This clearly signals when to use the tool, though it does not explicitly mention when not to use it or name an alternative sibling.

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

find_productCompare one grocery item across nearby storesAInspect

Compare a single grocery item across every collected store in a ZIP. Returns each store's actual current shelf price, whether it is on sale (and the regular price), the package size, the price normalized per comparable unit, stock, a purchase link, and when that price was last read. Use this to answer "who has the cheapest milk near me" — and note the answer reports BOTH the lowest sticker price and the best value per unit, which frequently disagree because the cheap sticker is a smaller package. For a whole shopping list use price_basket or cheapest_basket instead; calling this per item costs more and cannot optimize across stores. Costs $0.005 USDC per call via x402 on Base.

ParametersJSON Schema

Name	Required	Description
`q`	Yes	The item to price, in ordinary shopper language, e.g. 'milk', 'eggs', 'ground beef'.
`zip`	Yes	5-digit US ZIP code to price against, e.g. '30501'. Coverage is per collected ZIP; an uncovered ZIP returns an explicit error and is not charged.
`stores`	No	Optional comma-separated chains to restrict to, e.g. 'aldi,publix'. Omit to compare every collected store.
`maxAgeDays`	No	Optional freshness limit in days (default 14, max 120). A price read longer ago than this is withheld rather than returned as if current; raise it to accept older readings.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it enumerates return fields (shelf price, sale status, regular price, package size, normalized price, stock, purchase link, timestamp), discloses the caveat that lowest sticker price and best unit price can disagree, and states the $0.005 per-call cost. It does not mention auth or rate limits, but for a read-only comparison query the described behavior is substantial.

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?

Purpose appears in the first sentence, return values in the second, usage and caveat in the third, alternative routing in the fourth, and cost in the last. Each sentence earns its place and the most decision-relevant information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates by enumerating all major return fields and explaining the dual-price caveat. The input schema covers all four parameters including ZIP coverage and error behavior. Minor omissions like output format and authentication are not critical for this simple read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description references 'milk' as an example and relates per-item vs. basket cost, but does not add new parameter-level semantics beyond what the schema already documents for q, zip, stores, and maxAgeDays.

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 and resource: 'Compare a single grocery item across every collected store in a ZIP.' It also names sibling alternatives (price_basket, cheapest_basket) and clarifies this tool is for single-item comparison, so an agent can distinguish it from siblings without opening their schemas.

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?

It explicitly states when to use it ('who has the cheapest milk near me') and when not to: 'For a whole shopping list use price_basket or cheapest_basket instead; calling this per item costs more and cannot optimize across stores.' This provides both positive and negative selection criteria.

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

price_basketPrice a whole shopping list at each storeAInspect

Price an entire shopping list at every collected store in a ZIP, one complete basket per store. Returns per-store line items with quantities and line totals, the basket subtotal, exactly which requested items that store is missing, whether the basket is complete, stock flags, and the oldest price in the basket so staleness is visible. Use this when the shopper will make one trip and wants to know where the whole list is cheapest. Accepts quantities as 'milk x2'. Costs $0.01 USDC per call via x402 on Base.

ParametersJSON Schema

Name	Required	Description
`zip`	Yes	5-digit US ZIP code, e.g. '30501'.
`mode`	No	Optional fulfillment intent: 'pickup' or 'delivery'. Recorded on the response; delivery fees and minimums are not collected yet and are returned as null rather than estimated.
`items`	Yes	Comma-separated shopping list, optionally with quantities, e.g. 'milk x2, eggs, bread, butter'. A JSON array of {name, quantity} is also accepted.
`stores`	No	Optional comma-separated chains to restrict to, e.g. 'aldi,publix'.
`maxAgeDays`	No	Optional freshness limit in days (default 14, max 120). A price read longer ago than this is withheld rather than returned as if current; raise it to accept older readings.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses the $0.01 USDC x402 payment cost, staleness visibility via oldest-price reporting, missing-item behavior, and the limitation that delivery fees and minimums are returned as null rather than estimated.

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 dense but every sentence earns its place: function, return contents, use case, and cost/payment. It is front-loaded with the core behavior and contains no fluff or tautology.

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 tool with no output schema and no annotations, the description is unusually complete: it explains the return fields, the trip-planning use case, the pricing model, missing-item handling, staleness, and mode limitation. Nothing essential is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all five parameters. The description adds little beyond the schema, only restating the 'milk x2' quantity convention already present in the items examples. Baseline 3 is appropriate.

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 and resource: 'Price an entire shopping list at every collected store in a ZIP, one complete basket per store.' It clearly differentiates from siblings like cheapest_basket by emphasizing per-store line-item baskets, missing-item reporting, and completeness flags.

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 explicit context: 'Use this when the shopper will make one trip and wants to know where the whole list is cheapest.' It does not name alternative tools or state when not to use it, so it stops short of a perfect 5.

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

request_dataTell us what data you are looking for (free)AInspect

FREE, no payment. Describe in your own words the data you are trying to buy — anything, not just groceries — and get back whether we operate a service that supplies it, with the MCP endpoint if so. Every request is catalogued so that repeatedly-requested data gets built; call it whenever you cannot find a source for something. Nothing about you is stored: not your wallet, your address, or any identifying header — only the words of the request.

ParametersJSON Schema

Name	Required	Description	Default
`need`	Yes	What you are looking for, e.g. 'live electricity spot prices by ZIP' or 'used car values by VIN'.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses that the request is free, that every request is catalogued, that no identifying personal data is stored, and that the response indicates service availability and an MCP endpoint. This is unusually transparent about side effects and privacy.

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?

Three sentences, each earns its place: the first conveys the core action and differentiator, the second explains the cataloguing side effect and when to call, the third addresses privacy. The key selling points ('FREE', 'anything, not just groceries') are front-loaded with no fluff.

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 simple one-parameter tool with no output schema, the description is complete: it explains purpose, response behavior, when to use it, side effects, and privacy. Nothing an agent needs to decide whether and how to call this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for the single parameter 'need' with a description and example. The tool description adds context that the wording is free-form and not limited to groceries, but it does not materially extend the parameter semantics beyond the schema, so the baseline 3 applies.

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 action ('Describe in your own words the data you are trying to buy') and the expected result ('get back whether we operate a service that supplies it, with the MCP endpoint if so'). It explicitly broadens beyond groceries, distinguishing it from the sibling tools focused on specific data products.

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 a clear usage trigger: 'call it whenever you cannot find a source for something.' This implies a decision rule and distinguishes the tool from more targeted siblings, though it does not explicitly name alternatives or state when not to use it.

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.

5 tool updatesSep 4, 2026
- Changedcheapest_basket5 fields changed
  - addedInput schema / properties / items / examples
```
Added value: +[
+  "milk x2, eggs, bread, butter, cheese"
+]
```
  - addedInput schema / properties / maxAgeDays / examples
```
Added value: +[
+  14
+]
```
  - addedInput schema / properties / mode / examples
```
Added value: +[
+  "pickup"
+]
```
  - addedInput schema / properties / stores / examples
```
Added value: +[
+  "aldi,publix"
+]
```
  - addedInput schema / properties / zip / examples
```
Added value: +[
+  "30501"
+]
```
- Changeddemand_report1 field changed
  - addedInput schema / properties / days / examples
```
Added value: +[
+  "30"
+]
```
- Changedfind_product4 fields changed
  - addedInput schema / properties / maxAgeDays / examples
```
Added value: +[
+  14
+]
```
  - addedInput schema / properties / q / examples
```
Added value: +[
+  "milk"
+]
```
  - addedInput schema / properties / stores / examples
```
Added value: +[
+  "aldi,publix"
+]
```
  - addedInput schema / properties / zip / examples
```
Added value: +[
+  "30501"
+]
```
- Changedprice_basket5 fields changed
  - addedInput schema / properties / items / examples
```
Added value: +[
+  "milk x2, eggs, bread, butter"
+]
```
  - addedInput schema / properties / maxAgeDays / examples
```
Added value: +[
+  14
+]
```
  - addedInput schema / properties / mode / examples
```
Added value: +[
+  "pickup"
+]
```
  - addedInput schema / properties / stores / examples
```
Added value: +[
+  "aldi,publix"
+]
```
  - addedInput schema / properties / zip / examples
```
Added value: +[
+  "30501"
+]
```
- Changedrequest_data1 field changed
  - addedInput schema / properties / need / examples
```
Added value: +[
+  "live electricity spot prices by ZIP"
+]
```

3 tool updatesAug 24, 2026

Changedcheapest_basket1 field changed

addedInput schema / properties / maxAgeDays

Added value: +{
+  "description": "Optional freshness limit in days (default 14, max 120). A price read longer ago than this is withheld rather than returned as if current; raise it to accept older readings.",
+  "maximum": 120,
+  "minimum": 1,
+  "type": "integer"
+}

Changedfind_product1 field changed

addedInput schema / properties / maxAgeDays

Added value: +{
+  "description": "Optional freshness limit in days (default 14, max 120). A price read longer ago than this is withheld rather than returned as if current; raise it to accept older readings.",
+  "maximum": 120,
+  "minimum": 1,
+  "type": "integer"
+}

Changedprice_basket1 field changed

addedInput schema / properties / maxAgeDays

Added value: +{
+  "description": "Optional freshness limit in days (default 14, max 120). A price read longer ago than this is withheld rather than returned as if current; raise it to accept older readings.",
+  "maximum": 120,
+  "minimum": 1,
+  "type": "integer"
+}

2 tool updatesAug 24, 2026
- Addeddemand_report
- Addedrequest_data
3 tool updatesAug 23, 2026
- First observedcheapest_basket
- First observedfind_product
- First observedprice_basket

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
splitbasket-prices
io.github.voicearc
Cached US grocery prices, age disclosed on every row - search, compare across banners, coverage.
E-commerce & Retail Search Open Data
1
Pepesto Agent-to-Cart A
io.github.pepesto-solutions
Turn any shopping list into a ready-to-checkout grocery cart across 26 European supermarkets.
E-commerce & Retail Search
12
commerce A
today.lmk
Cross-merchant product search with real price history, comparisons, and demand signals.
E-commerce & Retail Search
132

Related MCP Servers

mcp-supermercados-cl
E-commerce & Retail Web Scraping
NLACE-COM
A
license
A
quality
A
maintenance
Enables searching products, comparing prices, and building optimal shopping lists across major Chilean supermarkets, using your local machine to access real-time prices and loyalty deals.
Updated a month ago (2026-08-02 02:09 UTC)
14
44
66
MIT
Commerce Price MCP
E-commerce & Retail Search
smrutiranjanp
F
license
Not graded
quality
B
maintenance
Enables searching and comparing product prices across major Indian quick-commerce and e-commerce platforms, ranking results by landed price, returning product links, storing price history, and providing 15–30 day price direction forecasts with best-buy recommendations.
Updated a day ago (2026-09-11 02:47 UTC)
-
Israel Grocery MCP
E-commerce & Retail Search
danielJL-altius
F
license
Not graded
quality
D
maintenance
Enables cross-store price comparison and recipe-driven cart automation for Israeli grocery stores Shufersal and Tiv Taam, with an extensible architecture for additional stores.
Updated 6 months ago (2026-03-14 15:14 UTC)
-
Grocery Search MCP Server
Search E-commerce & Retail Health & Wellness
ajaykallepalli
F
license
Not graded
quality
D
maintenance
Provides grocery price and nutritional information search capabilities, allowing AI agents to search for food products, compare prices, and analyze nutritional content across different grocery stores.
Updated a year ago (2025-06-10 00:55 UTC)
1
-

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.

Resources

Need Help?