Skip to main content
Glama
Swissgroceries MCP

Swissgroceries MCP

by nicktcode

get_product

Fetch full product details by chain and product ID to check price, size, unit price, tags, category, image, and active promotions after a search result.

Instructions

Fetch full product details for a specific chain + product ID pair. Returns { product, fetchedAt, fromCache }: the product carries price, brand, size, unit price, tags, category, image URL, and active promotions, while fetchedAt + fromCache report how fresh the data is. Obtain product IDs from search_products. Useful for drilling into a search result. Use for "get details for this Migros product" or "what is the unit price of this item?".

Input Schema

NameRequiredDescriptionDefault
idYesChain-specific product identifier, e.g. Migros cumulus ID or Coop product number. Obtain via search_products.
chainYesThe grocery chain that owns this product ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • changedInput schema / properties / chain / enum
      Previous value: -[
      -  "migros",
      -  "coop",
      -  "aldi",
      -  "denner",
      -  "lidl",
      -  "farmy",
      -  "volgshop",
      -  "ottos",
      -  "coopcity"
      -]New value: +[
      +  "migros",
      +  "coop",
      +  "aldi",
      +  "denner",
      +  "lidl",
      +  "volgshop",
      +  "ottos",
      +  "coopcity"
      +]
  2. Changed1 schema field changedv0.11.0
    • changedInput schema / properties / chain / enum
      Previous value: -[
      -  "migros",
      -  "coop",
      -  "aldi",
      -  "denner",
      -  "lidl",
      -  "farmy",
      -  "volgshop",
      -  "ottos"
      -]New value: +[
      +  "migros",
      +  "coop",
      +  "aldi",
      +  "denner",
      +  "lidl",
      +  "farmy",
      +  "volgshop",
      +  "ottos",
      +  "coopcity"
      +]
  3. First observedv0.7.10

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 and does meaningful work: it discloses that responses include a cached-data signal (fromCache) and a timestamp (fetchedAt), which tells the agent data may be stale. It does not state behavior for unknown/invalid product IDs or any auth/rate constraints, leaving one real gap.

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 comes first, then return shape, then how to get IDs, then example phrasings — a sensible front-loaded order. Slightly padded by the enumerated field list and two example utterances, but nothing is genuinely wasteful.

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?

No output schema exists, so the description correctly compensates by naming the top-level response fields and the product payload. For a simple two-parameter lookup this is nearly complete; only error/miss behavior is unaddressed.

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% and both parameters are already documented with the chain enumeration and ID provenance, so the schema does the heavy lifting. The description reinforces the pairing constraint (ID is chain-specific) but adds no format or validation detail beyond that. 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?

Opens with a specific verb and resource ("Fetch full product details for a specific chain + product ID pair"), which immediately separates it from the listing-style sibling search_products. The scope is unambiguous: one chain/product pair, full detail rather than search results.

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?

Explicitly routes the agent through search_products to obtain IDs and frames the tool as the drill-down step after a search, with two concrete example utterances. It stops short of stating exclusions (e.g., don't use this to browse or to look up stores), but the sequencing guidance is clear.

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