Skip to main content
Glama

Radar Volantini - Prezzi in Vista

by it.prezzinvista
OverviewDiscussionsAdmin

Server Details

Italy only: current offers and weekly price trends from the flyers of Italian store chains.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 5 tools

Disambiguation4/5

The five tools mostly occupy distinct roles, and the descriptions explicitly cross-reference each other (e.g. 'ids come only from search', 'sorting belongs to search_flyer_offers'). The main risk is overlap between `search` and `search_flyer_offers`, both of which return flyer offers, though the no-filters-vs-filters distinction helps disambiguate.

Naming Consistency4/5

All names use snake_case and lead with a verb, which is readable and predictable. Minor inconsistency: `fetch` and `search` are bare verbs while others are verb_noun (`get_price_trend`, `list_current_flyers`, `search_flyer_offers`).

Tool Count5/5

Five tools is well-scoped for a flyer/price lookup service, with each tool covering a distinct need: discovery, detail retrieval, trend, flyer listing, and filtered offer search. No redundant or filler tools.

Completeness4/5

The surface covers the lifecycle well: search/list to discover, fetch for detail, plus trend and filtered offer search. Minor gaps exist, such as no explicit chain/store lookup or comparison-only tool, but agents can reach those via existing tools.

Available Tools

5 tools
fetchLeggi un risultatoA
Read-onlyIdempotent
Inspect

Use this to read one of the documents returned by search, given its id. Returns the full text and the URL to cite. For an offer: price, previous price, pack size, price per kg or litre, chain, validity, and the same product in the other chains' current flyers. For a flyer: validity, number of offers and biggest discounts. For a product: this week's typical and lowest flyer price, the trend and each chain. Ids come only from search. Covers Italy only.

NameRequiredDescriptionDefault
idYesThe id of a document returned by search.

Output Schema

NameRequiredDescription
idYes
urlYesThe page to cite, on prezzinvista.it
textYesThe document, in Italian
titleYes
metadataNoType of document and its key facts

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so safety is covered. The description adds real behavioral context beyond them: the return contract per document type, the citation URL, and the geographic coverage constraint ("Covers Italy only"), which is consistent with openWorldHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose sentence is front-loaded and the Italy-only constraint is useful, but the long per-document-type enumeration of returned fields largely restates what the existing output schema already specifies, so several clauses do not fully earn their place.

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?

With an output schema present, return values need not be re-explained, yet the description still adds id provenance, scope limitation, and a citation-URL note. Nothing an agent needs to invoke it correctly is missing; the only flaw is mild redundancy with the output schema.

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% and the single id parameter is documented in the schema, so the baseline is 3. The description adds a genuine provenance constraint — ids originate only from search — which meaningfully restricts how the parameter may be populated.

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?

States a specific verb and resource (read one document returned by search, given its id) and enumerates exactly what each document type yields. It is clearly distinguishable from siblings like search and get_price_trend, so an agent can select it without opening the schema.

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?

"Use this to read one of the documents returned by search" plus "Ids come only from search" gives a clear precondition and effectively routes the agent from the search tool. It does not explicitly compare against get_price_trend, whose product-level trend data overlaps with what this tool returns, so there is a small gap in exclusions.

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

get_price_trendAndamento del prezzo di un prodottoA
Read-onlyIdempotent
Inspect

Use this when the user asks how much a common grocery or household product costs in Italy this week, whether it is getting cheaper or more expensive, or which chain has it cheapest: e.g. "how much does pasta cost this week", "is coffee more expensive than last week". Returns the typical (median) and lowest flyer price this week, the previous weeks and each chain this week, with the link to the product page on prezzinvista.it. Covers Italy only, and about two hundred staple products (pasta, caffè, olio di oliva, latte, detersivo, pannolini, …), named in Italian; specific brands and models are what search_flyer_offers looks up. In hosts that support MCP Apps the results are also shown to the user as a card with the weekly trend.

NameRequiredDescriptionDefault
productYesThe product, in Italian: e.g. "pasta", "caffè", "olio di oliva", "detersivo lavatrice".

Output Schema

NameRequiredDescription
urlYesThe product page on prezzinvista.it
weeksYesMost recent last
offersNoOffers this week
sourceNoWho to credit for the data
productYes
prices_areYesper kg, per l, per pack (groceries) or per item (appliances)
updated_atNoWhen the flyers were last read (ISO 8601). They are read again every three hours
change_noteNoWhen there is no percentage: how this week compares with the week before
change_percentNoThis week against the week before, only when the change is clear
stores_this_weekYesLowest first
typical_price_eurNoMedian flyer price this week
previous_typical_price_eurNoMedian the week before, when comparable

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds valuable non-structured context: Italy-only coverage, a limited catalogue of ~200 Italian-named staples, and the MCP Apps card rendering. It does not mention rate limits or caching, but the annotation burden is largely met.

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?

Front-loads the when-to-use triggers and examples, then covers scope, alternative, and output. It is somewhat long and the parenthetical product list is close to redundant with the schema examples, but every sentence carries information.

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?

An output schema exists so return values need not be explained, yet the description still summarizes them (median/lowest, weekly and per-chain, link). Combined with the Italy-only and catalogue-size limits and the sibling routing, an agent has everything needed to call it 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% and the single param is documented in the schema, so baseline is 3. The description goes beyond it by clarifying the expected vocabulary is a fixed set of ~200 staple products named in Italian (with examples like detersivo, pannolini), which meaningfully constrains how to fill the parameter.

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?

States a specific resource (weekly price trend of a product) with verb-like intent and explicitly scopes it: median/lowest flyer prices per week and per chain. It also distinguishes itself from the sibling search_flyer_offers, which handles specific brands and models.

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?

Gives concrete trigger conditions ('how much does pasta cost this week', 'is coffee more expensive than last week') and names the alternative tool with the condition that selects it. Nothing is left to inference.

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

list_current_flyersVolantini in corsoA
Read-onlyIdempotent
Inspect

Use this when the user asks which store flyers (volantini) are valid right now in Italy, whether a chain has a flyer this week, or until when a flyer is valid, optionally only for chains with a store near a city or near the position of the user. Returns chain, validity dates, number of offers, distance and address of the nearest store and the link to the flyer on prezzinvista.it. Covers Italy only. Products inside the flyers are what search_flyer_offers looks up. In hosts that support MCP Apps the results are also shown to the user as cards with logo, validity and link.

NameRequiredDescriptionDefault
cityNoItalian municipality (comune) to search around: where the user is, or the place they ask about, e.g. "Milano", "Reggio Emilia", "Sesto San Giovanni". Only flyers valid in stores within radius_km of its centre are returned. Without a place the search covers all of Italy.
limitNoFlyers to return (default 30). Nearest first with a city or coordinates, largest first otherwise.
storeNoOnly the flyers of this chain, by name: e.g. "Lidl".
near_meNoWhether to search around the approximate position of the user that some clients share with the call (ChatGPT does). When omitted, that position is used if the call names no city and no coordinates. true: the same, and the answer is an error when no position came with the call. false: all of Italy.
latitudeNoLatitude of the position of the user (WGS84, decimal degrees), together with longitude. Distances are then measured from this point, and only flyers valid in stores within radius_km of it are returned. Takes precedence over city. Used for this answer only, never stored.
longitudeNoLongitude of the position of the user, together with latitude.
radius_kmNoHow far to look around the city centre or the coordinates, in km (default 15).

Output Schema

NameRequiredDescription
cityNoThe municipality passed, or the nearest to the coordinates
noteNo
flyersYes
sourceNoWho to credit for the data
radius_kmNoThe radius searched around the place, in km
source_urlNoThe page on prezzinvista.it with these flyers and their offers: the URL to cite
updated_atNoWhen the flyers were last read (ISO 8601). They are read again every three hours
total_flyersYes
total_offersYes
place_assumedNotrue when the call named no place and the search was limited to the position shared by the client
distances_fromNoWhat distance_km is measured from: the coordinates passed, the approximate position shared by the client (near_me), or the centre of the city

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds useful behavior beyond that: Italy-only coverage, the returned fields (chain, validity dates, offer count, distance, address, link), and that MCP Apps hosts render cards. It does not discuss pagination or limits, but the schema covers those.

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?

Front-loaded with the usage triggers and dense with information, with little waste. It runs long across multiple clauses, but each clause carries scope, return, or sibling-routing information that earns its place.

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?

With an output schema present, the description need not enumerate return values, yet it still notes key fields. Combined with Italy-only scope, geo-search semantics, and the MCP Apps rendering note, nothing needed to call this correctly 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?

Schema description coverage is 100%, so every parameter is already documented in the schema. The description only conceptually restates the optional city/position filtering without adding syntax or precedence details beyond what the schema provides, matching the baseline 3.

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?

States a specific verb and resource (list store flyers valid right now) and bounds the scope to Italy. It explicitly distinguishes itself from the sibling search_flyer_offers by noting that tool looks up products inside the flyers, so an agent can route without opening either schema.

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?

Opens with explicit when-to-use triggers ('user asks which store flyers are valid right now', 'whether a chain has a flyer this week', 'until when a flyer is valid'). It also names the alternative for product-level queries, giving both when-to-use and when-not-to-use.

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

search_flyer_offersCerca offerte nei volantiniA
Read-onlyIdempotent
Inspect

Use this when the user wants to know where a product is on offer in Italy this week, at what price, at which chain and until when, and you need filters or sorting: a city or the position of the user, specific chains, a price cap, lowest price, lowest price per kg or nearest store first. Searches the offers currently valid in the flyers (volantini) of Italian supermarkets, discount stores and electronics chains. Flyers are local: with the city or the coordinates of the user the answer keeps the chains with a store near them; without a place it covers the whole country. Product names are in Italian: pass Italian words in query ("caffè", "pasta barilla", "lavatrice"). Returns price, previous price, the conditions printed with it (loyalty card, minimum purchase), brand, pack size, price per kg or litre, department, chain, validity dates, the page of the flyer and the link to the offer on prezzinvista.it; with a city or coordinates, also the distance, address and opening hours of the nearest store of each chain. Covers Italy only: not for other countries, not for online-shop prices. Flyer prices are indicative; the price displayed in store prevails. In hosts that support MCP Apps the results are also shown to the user as cards with photo, price and link.

NameRequiredDescriptionDefault
cityNoItalian municipality (comune) to search around: where the user is, or the place they ask about, e.g. "Milano", "Reggio Emilia", "Sesto San Giovanni". Only flyers valid in stores within radius_km of its centre are returned. Without a place the search covers all of Italy.
pageNoPage of results (default 1).
sortNorelevance (default with a query), price (lowest first), unit_price (lowest price per kg or litre first; only offers that state it), discount (biggest first; default without a query), nearest (closest chain first; needs a city or coordinates).
limitNoOffers per page (default 10).
queryNoProduct to look for, in Italian. Brand and product words are combined ("olio extravergine monini"). Omit to browse the biggest discounts.
storesNoOnly these chains, by name: e.g. ["Lidl", "Esselunga"].
near_meNoWhether to search around the approximate position of the user that some clients share with the call (ChatGPT does). When omitted, that position is used if the call names no city and no coordinates. true: the same, and the answer is an error when no position came with the call. false: all of Italy.
latitudeNoLatitude of the position of the user (WGS84, decimal degrees), together with longitude. Distances are then measured from this point, and only flyers valid in stores within radius_km of it are returned. Takes precedence over city. Used for this answer only, never stored.
longitudeNoLongitude of the position of the user, together with latitude.
radius_kmNoHow far to look around the city centre or the coordinates, in km (default 15).
max_price_eurNoOnly offers at or below this price.
discounted_onlyNoOnly offers whose flyer states a higher previous price.

Output Schema

NameRequiredDescription
cityNoThe municipality the search was limited to: the one passed, or the nearest to the coordinates
noteNo
pageYes
pagesYes
queryNo
totalYesOffers matching, across all pages
offersYes
sourceNoWho to credit for the data
radius_kmNoThe radius searched around the place, in km
search_urlYesThe same search on prezzinvista.it
updated_atNoWhen the flyers were last read (ISO 8601). They are read again every three hours
place_assumedNotrue when the call named no place and the search was limited to the position shared by the client
typical_priceNoFor everyday products: the typical (median) price in all Italian flyers this week, to judge the offers against
distances_fromNoWhat distance_km is measured from: the coordinates passed, the approximate position shared by the client (near_me), or the centre of the city
nearest_storesNoWith a city or coordinates: for each chain in the offers, its nearest store, closest first
chains_searchedNoHow many chains have a current flyer that was searched: with a city or coordinates, those valid there. No offer among 3 chains and no offer among 50 are different answers

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive and openWorld=false, yet the description still adds real behavioural context: flyer data is local so results narrow to chains with a nearby store, prices are indicative and the in-store price prevails, the corpus is Italian-only, and results render as cards in MCP Apps hosts. These are non-obvious traits an agent could not derive from 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?

The trigger, scope and exclusions are front-loaded and each sentence is dense with operative detail. Some padding exists: the location behaviour (city/coordinates vs. whole country) is restated three times and the return-value inventory duplicates the output schema.

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 12-parameter, all-optional, highly geographic search tool, the description covers placement rules, language of the query, sort/filter semantics, exclusions and the local nature of flyers. With an output schema present it need not explain return values, and its do so is only redundant, not a gap.

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, but the description goes further by grouping the filters into user intents (place, chains, price cap, lowest price / price-per-kg / nearest-first sorting) and by stressing that `query` must carry Italian product and brand words. That reinforces how combinations are meant to be used, though most individual field meaning still lives in the schema.

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 names a specific verb+resource (searching currently valid flyer offers from Italian supermarkets, discount and electronics chains) and immediately scopes it to 'this week' and Italy. It is clearly distinguishable from siblings like get_price_trend or list_current_flyers, which do different jobs.

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 opens with an explicit trigger ('Use this when the user wants to know where a product is on offer in Italy this week...') and states exclusions ('not for other countries, not for online-shop prices'). It never names a sibling tool as the alternative to use instead, so routing between near-neighbours such as list_current_flyers or get_price_trend is left to inference.

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.

  1. 2 tool updates
    • Changedlist_current_flyers16 fields changed
      • changedInput schema / properties / city / description
        Previous value: -"Italian municipality (comune) to search around, e.g. \"Milano\", \"Reggio Emilia\", \"Sesto San Giovanni\". Only flyers valid in stores within 15 km are returned. Omit for all of Italy."New value: +"Italian municipality (comune) to search around: where the user is, or the place they ask about, e.g. \"Milano\", \"Reggio Emilia\", \"Sesto San Giovanni\". Only flyers valid in stores within radius_km of its centre are returned. Without a place the search covers all of Italy."
      • addedInput schema / properties / latitude
        Added value: +{
+  "description": "Latitude of the position of the user (WGS84, decimal degrees), together with longitude. Distances are then measured from this point, and only flyers valid in stores within radius_km of it are returned. Takes precedence over city. Used for this answer only, never stored.",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}
      • changedInput schema / properties / limit / description
        Previous value: -"Flyers to return (default 30). Nearest first with a city, largest first otherwise."New value: +"Flyers to return (default 30). Nearest first with a city or coordinates, largest first otherwise."
      • addedInput schema / properties / longitude
        Added value: +{
+  "description": "Longitude of the position of the user, together with latitude.",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}
      • addedInput schema / properties / near_me
        Added value: +{
+  "description": "Whether to search around the approximate position of the user that some clients share with the call (ChatGPT does). When omitted, that position is used if the call names no city and no coordinates. true: the same, and the answer is an error when no position came with the call. false: all of Italy.",
+  "type": "boolean"
+}
      • addedInput schema / properties / radius_km
        Added value: +{
+  "description": "How far to look around the city centre or the coordinates, in km (default 15).",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "number"
+}
      • addedOutput schema / properties / city / description
        Added value: +"The municipality passed, or the nearest to the coordinates"
      • addedOutput schema / properties / distances_from
        Added value: +{
+  "description": "What distance_km is measured from: the coordinates passed, the approximate position shared by the client (near_me), or the centre of the city",
+  "enum": [
+    "coordinates",
+    "client_location",
+    "city_centre"
+  ],
+  "type": "string"
+}
      • changedOutput schema / properties / flyers / items / properties / nearest_store / description
        Previous value: -"With a city: the nearest store of the chain"New value: +"With a city or coordinates: the nearest store of the chain"
      • changedOutput schema / properties / flyers / items / properties / nearest_store / properties / distance_km / description
        Previous value: -"From the centre of the city"New value: +"From the place in distances_from"
      • addedOutput schema / properties / flyers / items / properties / nearest_store / properties / latitude
        Added value: +{
+  "description": "Position of the store (WGS84)",
+  "type": "number"
+}
      • addedOutput schema / properties / flyers / items / properties / nearest_store / properties / longitude
        Added value: +{
+  "type": "number"
+}
      • changedOutput schema / properties / flyers / items / properties / stores_nearby / description
        Previous value: -"Stores of the chain within 15 km of the city"New value: +"Stores of the chain within radius_km"
      • addedOutput schema / properties / note
        Added value: +{
+  "type": "string"
+}
      • addedOutput schema / properties / place_assumed
        Added value: +{
+  "description": "true when the call named no place and the search was limited to the position shared by the client",
+  "type": "boolean"
+}
      • addedOutput schema / properties / radius_km
        Added value: +{
+  "description": "The radius searched around the place, in km",
+  "type": "number"
+}
    • Changedsearch_flyer_offers17 fields changed
      • changedInput schema / properties / city / description
        Previous value: -"Italian municipality (comune) to search around, e.g. \"Milano\", \"Reggio Emilia\", \"Sesto San Giovanni\". Only flyers valid in stores within 15 km are returned. Omit for all of Italy."New value: +"Italian municipality (comune) to search around: where the user is, or the place they ask about, e.g. \"Milano\", \"Reggio Emilia\", \"Sesto San Giovanni\". Only flyers valid in stores within radius_km of its centre are returned. Without a place the search covers all of Italy."
      • addedInput schema / properties / latitude
        Added value: +{
+  "description": "Latitude of the position of the user (WGS84, decimal degrees), together with longitude. Distances are then measured from this point, and only flyers valid in stores within radius_km of it are returned. Takes precedence over city. Used for this answer only, never stored.",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}
      • addedInput schema / properties / longitude
        Added value: +{
+  "description": "Longitude of the position of the user, together with latitude.",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}
      • addedInput schema / properties / near_me
        Added value: +{
+  "description": "Whether to search around the approximate position of the user that some clients share with the call (ChatGPT does). When omitted, that position is used if the call names no city and no coordinates. true: the same, and the answer is an error when no position came with the call. false: all of Italy.",
+  "type": "boolean"
+}
      • addedInput schema / properties / radius_km
        Added value: +{
+  "description": "How far to look around the city centre or the coordinates, in km (default 15).",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "number"
+}
      • changedInput schema / properties / sort / description
        Previous value: -"relevance (default with a query), price (lowest first), unit_price (lowest price per kg or litre first; only offers that state it), discount (biggest first; default without a query), nearest (closest chain first; needs city)."New value: +"relevance (default with a query), price (lowest first), unit_price (lowest price per kg or litre first; only offers that state it), discount (biggest first; default without a query), nearest (closest chain first; needs a city or coordinates)."
      • changedOutput schema / properties / chains_searched / description
        Previous value: -"How many chains have a current flyer that was searched: with a city, those valid there. No offer among 3 chains and no offer among 50 are different answers"New value: +"How many chains have a current flyer that was searched: with a city or coordinates, those valid there. No offer among 3 chains and no offer among 50 are different answers"
      • changedOutput schema / properties / city / description
        Previous value: -"The municipality the search was limited to"New value: +"The municipality the search was limited to: the one passed, or the nearest to the coordinates"
      • addedOutput schema / properties / distances_from
        Added value: +{
+  "description": "What distance_km is measured from: the coordinates passed, the approximate position shared by the client (near_me), or the centre of the city",
+  "enum": [
+    "coordinates",
+    "client_location",
+    "city_centre"
+  ],
+  "type": "string"
+}
      • changedOutput schema / properties / nearest_stores / description
        Previous value: -"With a city: for each chain in the offers, its nearest store, closest first"New value: +"With a city or coordinates: for each chain in the offers, its nearest store, closest first"
      • changedOutput schema / properties / nearest_stores / items / properties / distance_km / description
        Previous value: -"From the centre of the city"New value: +"From the place in distances_from"
      • addedOutput schema / properties / nearest_stores / items / properties / latitude
        Added value: +{
+  "description": "Position of the store (WGS84)",
+  "type": "number"
+}
      • addedOutput schema / properties / nearest_stores / items / properties / longitude
        Added value: +{
+  "type": "number"
+}
      • changedOutput schema / properties / offers / items / properties / availability / description
        Previous value: -"With a city: verified_nearby = the chain lists a store within 15 km of it; nationwide_flyer = the flyer is valid in the whole country, a store nearby is not verified"New value: +"With a city or coordinates: verified_nearby = the chain lists a store within radius_km; nationwide_flyer = the flyer is valid in the whole country, a store nearby is not verified"
      • changedOutput schema / properties / offers / items / properties / distance_km / description
        Previous value: -"Distance of the nearest store of the chain from the centre of the city"New value: +"How far the nearest store of the chain is, from the place in distances_from"
      • addedOutput schema / properties / place_assumed
        Added value: +{
+  "description": "true when the call named no place and the search was limited to the position shared by the client",
+  "type": "boolean"
+}
      • addedOutput schema / properties / radius_km
        Added value: +{
+  "description": "The radius searched around the place, in km",
+  "type": "number"
+}
  2. 1 tool update
    • Changedsearch_flyer_offers10 fields changed
      • addedOutput schema / properties / chains_searched
        Added value: +{
+  "description": "How many chains have a current flyer that was searched: with a city, those valid there. No offer among 3 chains and no offer among 50 are different answers",
+  "type": "integer"
+}
      • addedOutput schema / properties / offers / items / properties / availability
        Added value: +{
+  "description": "With a city: verified_nearby = the chain lists a store within 15 km of it; nationwide_flyer = the flyer is valid in the whole country, a store nearby is not verified",
+  "enum": [
+    "verified_nearby",
+    "nationwide_flyer"
+  ],
+  "type": "string"
+}
      • addedOutput schema / properties / offers / items / properties / conditions
        Added value: +{
+  "description": "What the flyer prints next to the price, in Italian: loyalty card required, minimum purchase, price for several pieces. The price holds under these conditions",
+  "type": "string"
+}
      • addedOutput schema / properties / offers / items / properties / flyer_edition
        Added value: +{
+  "description": "For a regional or single-store edition of the flyer: the territory it is valid in. Absent when the flyer is the same for the whole country",
+  "type": "string"
+}
      • addedOutput schema / properties / offers / items / properties / flyer_page
        Added value: +{
+  "description": "Page of the flyer where the price is printed",
+  "type": "integer"
+}
      • addedOutput schema / properties / offers / items / properties / official_flyer_url
        Added value: +{
+  "description": "The flyer on the website of the chain, where the price can be checked at the source",
+  "type": "string"
+}
      • addedOutput schema / properties / offers / items / properties / price_doubt
        Added value: +{
+  "description": "Present only when something makes this price, or its discount, doubtful: what and why. It is a reason to check the flyer page before relying on the number, not a correction",
+  "type": "string"
+}
      • addedOutput schema / properties / offers / items / properties / requires_loyalty_card
        Added value: +{
+  "description": "true when the conditions say the price needs the loyalty card, app or coupon of the chain. Absent otherwise: the flyer may not say",
+  "type": "boolean"
+}
      • changedOutput schema / properties / offers / items / properties / url / description
        Previous value: -"The offer on its flyer page at prezzinvista.it"New value: +"The offer on its flyer page at prezzinvista.it: the page of the flyer with the price on it"
      • addedOutput schema / properties / offers / items / properties / valid_from
        Added value: +{
+  "description": "First day of the offer, YYYY-MM-DD",
+  "type": "string"
+}
  3. 1 tool update
    • Changedlist_current_flyers1 field changed
      • addedOutput schema / properties / source_url
        Added value: +{
+  "description": "The page on prezzinvista.it with these flyers and their offers: the URL to cite",
+  "type": "string"
+}
  4. 5 tool updates
    • First observedfetch
    • First observedget_price_trend
    • First observedlist_current_flyers
    • First observedsearch
    • First observedsearch_flyer_offers

Related MCP Connectors

Related MCP Servers

  • my-grocery-mcp

    yifei-ding
    A
    license
    A
    quality
    B
    maintenance
    Enables natural-language search of Swiss grocery products, price comparison, and weekly promotion lookup across retailers including Migros, Coop, Aldi, Denner, Lidl, Farmy, Volgshop, and Otto's.
    7
    MIT

  • SwitchAI

    US1929
    A
    license
    A
    quality
    C
    maintenance
    AI agent for Italian energy tariff comparison. Analyzes electricity and gas bills, compares 44+ offers from 13 providers, estimates savings with full ARERA regulated cost breakdown
    7
    MIT

  • PriceAtlas MCP Server

    musaceylan
    A
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to track global food prices, search products by barcode or name, and compare costs across 27 countries. It provides tools for real-time price scraping and data aggregation from major international supermarket chains.
    8
    4
    MIT
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