DatiTuristici.it

Compare tourism figures of Italian comuni side by side

confronta_comuni

Read-onlyIdempotent

Compares 2 to 5 Italian comuni side by side in the same year: nights, arrivals, bed places, establishments, population, average stay and share of arrivals from abroad. Use it when the question is about several comuni at once and you have their 6-digit codes from cerca_comune; do not use it for one comune (use leggi_dati_comune instead) or to rank many by a criterion (use classifica_territori instead). anno defaults to the latest year with figures for every comune, so the numbers stay comparable; a comune without figures in that year keeps null values and nota names it, also flagging 2025 and later, when the counts changed scope. Fewer than 2 or more than 5 codes, a repeated code or an unknown one returns an error that says what to pass. Read-only, public, no authentication; 30 requests per minute per client, shared across tools.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cod_istat": "<cod_istat>"
    },
    "name": "confronta_comuni"
  }
}

Input Schema

Name	Required	Description	Default
`anno`	No	Year of the figures for every comune, e.g. 2024; default: the latest year they all have. A year outside their years with data returns an error that gives them.
`cod_istat`	Yes	2 to 5 different 6-digit ISTAT codes as strings, leading zeros kept, e.g. ["058091", "015146"] for Roma and Milano; they come from cerca_comune.

Output Schema

Name	Required	Description
`anno`	Yes	The one year of every figure: the requested one, or the latest year with figures for every comune; null if none of them has figures.
`nota`	Yes	Notes in English, null when there is nothing to say: from 2025 ISTAT counts include privately rented holiday flats, so totals and non-hotel figures are not comparable with years before 2025 (hotel figures are); comuni without figures in `anno`; capacity from an earlier year.
`fonte`	Yes	Source to cite with the figures: processed by DatiTuristici.it from institutional data (ISTAT).
`comuni`	Yes	The comuni in the requested order, each with its figures of `anno`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/no-auth, but the description adds real behavioral context beyond them: the `anno` default logic (latest year every comune has data, to keep numbers comparable), that missing comuni keep nulls and are named in `nota`, that 2025+ counts changed scope, and the 30 req/min per-client shared rate limit. No contradictions with readOnlyHint.

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 and metric list, then usage disambiguation, then behavioral notes. Dense but well organized; the metric enumeration is long yet each item is informative, with minimal waste.

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?

Given an output schema exists (so return formatting needn't be explained), the description covers validation rules, defaults, null/nota handling, scope changes, and rate limits. 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%, so baseline is 3; the description adds value with the 'anno defaults to the latest year with figures for every comune' rationale and the error behavior for out-of-range years, plus concrete code examples. It doesn't add much for cod_istat beyond the schema, keeping it just above baseline.

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?

Specific verb (compares), specific resource (2-5 Italian comuni in the same year), and an explicit metric list (nights, arrivals, bed places, establishments, population, average stay, share from abroad). It names the sibling tools it is not (leggi_dati_comune, classifica_territori), so an agent can differentiate without opening schemas.

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?

Explicit when-to-use (several comuni at once with 6-digit codes from cerca_comune), explicit when-not (single comune → leggi_dati_comune; ranking → classifica_territori), plus error conditions for <2, >5, duplicate or unknown codes. Nothing material 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.

All DatiTuristici.it 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?