Skip to main content
Glama

GroceryPulse Canada

by ca.grocerypulse
OverviewDiscussionsAdmin

Plan a Canadian grocery order

plan_grocery_order
Read-onlyIdempotent

Plans a grocery order from a shopping list as the shopper wrote it, in a covered Canadian city. Use when a shopper asks where their list is cheapest or wants to buy groceries online. Takes the list as text (English or French, quantities included, up to 60 lines), the city or the first three characters of a postal code inside it and, optionally, the stores the shopper uses. Returns each line as exact, closest (a different size, variant or brand: not priced and in no total) or not tracked; per-store totals with coverage and price dates; a cheapest store only when every compared item is priced at two or more chains with a clear lead (or, when the only obstacle is a pack item whose count no store's listing gives, a store labelled cheapest for the other lines, with those lines listed apart), otherwise the reason; per-item links to each store's own product page or search; and interpretation notes that state what the result does and does not cover. Read-only: it never orders, adds to a cart, saves a list or contacts a store.

Input Schema

NameRequiredDescriptionDefault
cityNoThe covered Canadian city whose chain prices are compared (the price market): its English or French name, or its slug. Give this or postalCode.
listYesThe shopper's grocery list exactly as they wrote it, one item per line (or comma-separated), English or French, with quantities if they gave them: "2L milk", "dozen eggs", "3 lbs lean ground beef", "oeufs".
storesNoOptional: only the stores the shopper is willing to use (names like "No Frills" or catalogue keys). Omit to compare every tracked chain in the city.
languageNoLanguage for item names and store links. Default en.
postalCodeNoThe first three characters of a Canadian postal code (the forward sortation area, for example K1P), used only to choose the covered city. Areas outside the covered cities are refused, never moved to the nearest one. A full postal code is accepted; only its first three characters are read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / city / description
      Previous value: -"A covered Canadian city (name in English or French, or its slug). Give this or postalCode."New value: +"The covered Canadian city whose chain prices are compared (the price market): its English or French name, or its slug. Give this or postalCode."
    • changedInput schema / properties / postalCode / description
      Previous value: -"A Canadian postal code inside a covered city. Used only to choose the city; areas outside covered cities are refused, never moved to the nearest one."New value: +"The first three characters of a Canadian postal code (the forward sortation area, for example K1P), used only to choose the covered city. Areas outside the covered cities are refused, never moved to the nearest one. A full postal code is accepted; only its first three characters are read."
    • changedInput schema / properties / postalCode / maxLength
      Previous value: -60New value: +10
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/no-destruction, and the description still adds substantial context: the exact/closest/not-tracked classification, per-store totals with coverage and price dates, the strict conditions for declaring a cheapest store, and the 'cheapest for the other lines' partial case. It also explicitly restates the side-effect boundary ('never orders, adds to a cart, saves a list or contacts a store'), which reinforces rather than contradicts 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage trigger are front-loaded in the first sentence, and every clause maps to something the agent needs (inputs, return shape, side-effect boundary). The return-value sentence is very long and run-on, though, packing cheapest-store conditions into one dense block.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does: per-line classifications, per-store totals, cheapest-store logic and its exceptions, per-item links and interpretation notes. Combined with the declared side-effect boundary, an agent has everything needed to call and interpret this 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 largely mirrors the schema ('the list as text', 'the city or the first three characters of a postal code', 'optionally, the stores'), adding only the 'up to 60 lines' list-size hint and the quantity/language guidance that the schema already covers.

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 states a specific verb and resource ('Plans a grocery order from a shopping list') and scopes it to 'a covered Canadian city', so the agent knows exactly what the tool produces. It does not name or contrast itself with the siblings compare_grocery_list or get_grocery_catalog, which is the only thing keeping it from a 5.

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 gives clear triggering conditions: 'Use when a shopper asks where their list is cheapest or wants to buy groceries online.' That is actionable context, but no explicit exclusion ('do not use for X') and no reference to the alternative sibling tools for near-miss cases.

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

All GroceryPulse Canada toolsInspect
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