DatiTuristici.it

List Italian regions, provinces and comuni

elenca_territori

Read-onlyIdempotent

Lists Italian regions, provinces or comuni in alphabetical order, with how many provinces and comuni each region has and how many comuni each province has. Use it to browse the territory and to get the exact names that classifica_territori accepts; do not use it to rank places by tourism figures (use classifica_territori instead) or to look one comune up by name (use cerca_comune instead). Names ignore case, accents and punctuation, and Trentino-Alto Adige is one region with the two provinces of Bolzano and Trento; an unknown or ambiguous name returns an error with the closest names, a comune without a recorded province has null there, and a page past the end is an empty list. 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": {
      "livello": "<livello>"
    },
    "name": "elenca_territori"
  }
}

Input Schema

Name	Required	Description
`limite`	No	Items per page, 1-200, default 50.
`offset`	No	Items to skip, default 0: for the next page pass the previous `offset` plus `limite` while `ha_altri` is true.
`livello`	Yes	What to list: "regione" (regions), "provincia" (provinces, optionally of one `regione`) or "comune" (comuni, optionally of one `regione` or `provincia`).
`regione`	No	Optional: only the provinces or comuni of this region, by its Italian name in any case ("Toscana", "trentino alto adige").
`provincia`	No	Optional: only the comuni of this province, by its Italian name in any case ("Firenze", "Bolzano", "Monza e Brianza").

Output Schema

Name	Required	Description
`fonte`	Yes	Source to cite with the figures: processed by DatiTuristici.it from institutional data (ISTAT).
`offset`	Yes	Items skipped before this page, as requested.
`totale`	Yes	Number of matching items across all pages.
`elementi`	Yes	The page of regions, provinces or comuni in alphabetical order; an empty list past the last page.
`ha_altri`	Yes	True when more items follow this page: ask again with a larger `offset`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

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 and non-destructive behavior, but the description adds substantial context beyond them: public access with no authentication, a 30 requests-per-minute shared rate limit, error behavior for unknown or ambiguous names, null province handling and empty-page behavior. It also discloses name-matching and Trentino-Alto Adige special cases.

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

Conciseness5/5

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

The description is front-loaded with purpose, then usage and exclusions, then behavioral edge cases. It is dense but every clause is useful for selection or correct invocation, and there is no wasted preamble.

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 the output schema exists, the description does not need to explain return values, yet it still covers the key invocation context: purpose, alternatives, name normalization, pagination edge cases and operational limits. Nothing material is missing for an agent 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 the schema already explains all five parameters in detail. The description still adds meaningful matching semantics beyond the schema, including that names ignore case, accents and punctuation, and clarifies the Trentino-Alto Adige province structure.

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 states a specific verb and resource: lists Italian regions, provinces or comuni in alphabetical order, including count summaries. It clearly distinguishes the tool from classifica_territori and cerca_comune, so an agent can identify its role 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use it: browsing the territory and getting exact names accepted by classifica_territori. It also gives two clear exclusions and names the alternatives: classifica_territori for tourism rankings and cerca_comune for looking up one comune by name.

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?