Skip to main content
Glama

DatiTuristici.it

Rank Italian territories by tourism figures

classifica_territori
Read-onlyIdempotent

Ranks and filters Italian comuni, provinces or regions by the tourism figures of one year, with the same rows, order and values as the advanced search (Esplora) on datituristici.it. Use it for questions with criteria, such as the comuni of a region with the most nights or those above a bed occupancy threshold; do not use it to read one known comune (use leggi_dati_comune instead), to look a place up by name (use cerca_comune instead) or to browse names (use elenca_territori instead). Figures are for anno, by default the latest year with data; a figure that is not available is null, an empty list means that no territory meets the criteria, and in 2025 variazione is null because the counts started including privately rented holiday flats (nota explains it). Read-only, public, no authentication; 30 requests per minute per client, shared across tools.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "classifica_territori"
  }
}

Input Schema

NameRequiredDescriptionDefault
annoNoYear of the figures, e.g. 2024; default: the latest year with data. A year outside the years with data returns an error that gives them.
filtriNoOptional thresholds, up to 5 and one per metric: a row is kept when each metric is within its bounds, and a row without that metric is dropped. Example: [{"metrica": "presenze", "min": 100000}, {"metrica": "tasso_occ", "max": 40}].
limiteNoRows per page, 1-50, default 10.
offsetNoItems to skip, default 0: for the next page pass the previous `offset` plus `limite` while `ha_altri` is true.
ordineNo"desc" (default) puts the highest values first, "asc" the lowest.desc
livelloNoWhat to rank: "comune" (default), "provincia" or "regione".comune
regioneNoOptional: keep only these regions, up to 5, by Italian name in any case, e.g. ["Toscana", "Umbria"].
andamentoNoOptional trend of presenze on the previous year: crescita = variazione at least +3%, calo = at most -3%, stabile = in between. Not applied in 2025, where variazione does not exist (see `nota`).
provinciaNoOptional: keep only these provinces, up to 5, by Italian name, e.g. ["Firenze", "Bolzano"]; not with "regione" as `livello`.
ordina_perNoMetric to sort by (meanings under `filtri`), or nome for alphabetical order; default presenze. Rows without the metric come last.presenze

Output Schema

NameRequiredDescriptionDefault
annoYesYear of the figures: the requested one, or the latest with data; null only when no figures are loaded.
notaYesComparability warning in English for 2025 and later (privately rented holiday flats entered the counts), saying in 2025 which arguments were not applied; null otherwise.
fonteYesSource to cite with the figures: processed by DatiTuristici.it from institutional data (ISTAT).
righeYesThe page of ranked rows; an empty list when no territory meets the criteria or past the last page.
offsetYesItems skipped before this page, as requested.
totaleYesNumber of matching items across all pages.
ha_altriYesTrue when more items follow this page: ask again with a larger `offset`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive/closed-world, but the description adds genuinely new context: figures default to the latest year with data, missing figures are null, an empty list means no territory matched, 2025 variazione is null by construction because private holiday flats entered the counts, and there is a 30 req/min shared rate limit with no auth. These are exactly the traits an agent cannot infer from structured fields.

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 purpose, then usage, then exclusions, then edge cases and operational limits — no sentence is filler. It is dense and carries several parenthetical asides (nota, 2025 caveat), which keeps it just short of maximally tight.

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 10-parameter ranking tool with an output schema, the description covers the remaining agent-facing burdens: default year, null vs empty-list reading, the 2025 anomaly, and the shared rate limit. Nothing needed to call it 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 coverage is 100% with rich per-parameter and enum descriptions, so the baseline is 3. The description only restates the anno default and ordering, adding no semantics for filtri, livello, regione/provincia interaction or the pagination contract beyond what the schema already documents.

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 ('Ranks and filters Italian comuni, provinces or regions by the tourism figures of one year') and ties the output to a concrete benchmark (same rows, order and values as Esplora on datituristici.it). An agent can distinguish it from cerca_comune, elenca_territori and leggi_dati_comune without opening any 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?

Gives an explicit use case ('questions with criteria, such as the comuni of a region with the most nights or those above a bed occupancy threshold') and three named exclusions with the sibling to use instead (leggi_dati_comune, cerca_comune, elenca_territori). Routing is fully determined.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources