Skip to main content
Glama

DatiTuristici.it

Read how far the tourism figures go and how recent they are

leggi_copertura_dati
Read-onlyIdempotent

Reads which tourism figures the service holds and how recent they are: the latest year, how many comuni are covered, the last import, what each metric means and the 2025 break in the series. Use it to check how current the figures are, what a metric means or why a comune has a gap; do not use it to read the figures themselves (use leggi_dati_comune instead) or to find a comune by name (use cerca_comune instead). With a 6-digit cod_istat it adds the years with figures and with capacity for that comune and whether it has a projection and why not; without one per_comune is null. aggiornato_il is the time of the last successful import, null if none is recorded, not of the last check for new files; profilo_territoriale gives the year and the last import of the sources of the territorial profile. 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": "leggi_copertura_dati"
  }
}

Input Schema

NameRequiredDescriptionDefault
cod_istatNoOptional: 6-digit ISTAT code of one comune as a string, leading zeros kept ("058091" is Roma), from cerca_comune, to add its own coverage; omit it for the summary of the whole country. An unknown code returns an error that says what to pass.

Output Schema

NameRequiredDescriptionDefault
notaYesNotes in English, null when there is nothing to say: no figures loaded yet, or the comune has no movement figures.
fonteYesSource to cite with the figures: processed by DatiTuristici.it from institutional data (ISTAT).
cadenzaYesHow the figures are kept up to date: when the service checks for new ISTAT files and what makes the figures change.
per_comuneYesThe coverage of the one comune asked for with `cod_istat`; null when `cod_istat` was omitted.
definizioniYesWhat the metrics of classifica_territori mean, one entry per metric, with the same wording as its `filtri` parameter. Presenze are nights spent, not people.
aggiornato_ilYesUTC timestamp of the last successful import of the ISTAT tourism files (ISO 8601): when the figures were last loaded, not when they were last checked. Null if no import is recorded.
comuni_totaliYesNumber of comuni, as counted by elenca_territori.
discontinuitaYesThe break in the series: the year ISTAT changed what its counts include.
comuni_con_datiYesHow many comuni have movement figures in `ultimo_anno_annuale`; the ISTAT rows that group the small comuni of a province are not counted.
ultimo_anno_annualeYesLatest year with yearly movement figures (the default `anno` of the other tools); null only when no figures are loaded.
profilo_territorialeYesThe sources of the `profilo` that leggi_dati_comune gives, one entry each, with the year of their data and the time of their last successful import; null when this server does not serve the profile.
ultimo_periodo_infrannualeYesLatest period with sub-annual (monthly) nights, as YYYY-MM. Only this date is given: the monthly figures themselves are not served here. Null if there are none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / profilo_territoriale
      Added value: +{
      +  "description": "The sources of the `profilo` that leggi_dati_comune gives, one entry each, with the year of their data and the time of their last successful import; null when this server does not serve the profile.",
      +  "items": {
      +    "description": "One source of the territorial profile.",
      +    "properties": {
      +      "aggiornato_il": {
      +        "description": "UTC timestamp of the last successful import of this source (ISO 8601), not of the last check; null if none is recorded.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "anno": {
      +        "description": "Reference year of the data held (the latest year of the ISTAT file, the year Wikidata was read); null if none is loaded.",
      +        "type": [
      +          "integer",
      +          "null"
      +        ]
      +      },
      +      "dati": {
      +        "description": "What this source gives to the profile.",
      +        "type": "string"
      +      },
      +      "fonte": {
      +        "description": "How to cite this source.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "fonte",
      +      "dati",
      +      "anno",
      +      "aggiornato_il"
      +    ],
      +    "type": "object"
      +  },
      +  "type": [
      +    "array",
      +    "null"
      +  ]
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "ultimo_anno_annuale",
      -  "ultimo_periodo_infrannuale",
      -  "comuni_con_dati",
      -  "comuni_totali",
      -  "aggiornato_il",
      -  "cadenza",
      -  "definizioni",
      -  "discontinuita",
      -  "per_comune",
      -  "nota",
      -  "fonte"
      -]New value: +[
      +  "ultimo_anno_annuale",
      +  "ultimo_periodo_infrannuale",
      +  "comuni_con_dati",
      +  "comuni_totali",
      +  "aggiornato_il",
      +  "cadenza",
      +  "definizioni",
      +  "discontinuita",
      +  "per_comune",
      +  "profilo_territoriale",
      +  "nota",
      +  "fonte"
      +]
  2. First observed

TDQS

A4.9/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, but the description adds materially more: public access with no authentication, a 30 req/min rate limit shared across tools, the null semantics of `aggiornato_il` (last successful import, not last file check), and that an unknown code returns a self-explanatory error. This is exactly the operational context annotations cannot express.

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 purpose, then usage routing, then parameter effects, then operational caveats — a sensible order. It is dense with long semicolon-chained clauses, which risks a single overloaded sentence, but nearly every clause carries distinct 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 spelled out, yet the description pre-emptively glosses the key fields (latest year, comuni covered, last import, metric meanings, 2025 break, profilo_territoriale). For a single-optional-parameter read tool, nothing an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds outcome semantics: with a cod_istat the response gains per-comune years with figures, capacity, and projection status with reasons; without it `per_comune` is null. That explains the parameter's effect on the response shape, not just its format.

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 ('Reads') plus the exact resource (coverage metadata of tourism figures: latest year, comuni count, last import, metric meanings, 2025 series break). It explicitly distinguishes itself from the siblings that return data (leggi_dati_comune) and that look up a comune (cerca_comune).

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 both positive triggers ('check how current the figures are, what a metric means or why a comune has a gap') and explicit exclusions with the alternative tool named for each ('do not use it to read the figures themselves... use cerca_comune instead'). No inference required.

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