Radar Volantini - Prezzi in Vista

Volantini in corso

list_current_flyers

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`city`	No	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.
`limit`	No	Flyers to return (default 30). Nearest first with a city or coordinates, largest first otherwise.
`store`	No	Only the flyers of this chain, by name: e.g. "Lidl".
`near_me`	No	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.
`latitude`	No	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.
`longitude`	No	Longitude of the position of the user, together with latitude.
`radius_km`	No	How far to look around the city centre or the coordinates, in km (default 15).

Output Schema

Name	Required	Description
`city`	No	The municipality passed, or the nearest to the coordinates
`note`	No
`flyers`	Yes
`source`	No	Who to credit for the data
`radius_km`	No	The radius searched around the place, in km
`source_url`	No	The page on prezzinvista.it with these flyers and their offers: the URL to cite
`updated_at`	No	When the flyers were last read (ISO 8601). They are read again every three hours
`total_flyers`	Yes
`total_offers`	Yes
`place_assumed`	No	true when the call named no place and the search was limited to the position shared by the client
`distances_from`	No	What distance_km is measured from: the coordinates passed, the approximate position shared by the client (near_me), or the centre of the city

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 13, 2026

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"
+}

Changed1 schema field changedOct 5, 2026

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"
+}

First observedOct 4, 2026

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.

All Radar Volantini - Prezzi in Vista 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?