DatiTuristici.it

Search Italian comuni by name

cerca_comune

Read-onlyIdempotent

Searches Italian municipalities (comuni) by name, tolerating partial names and typos, and returns each match with its 6-digit ISTAT code, province and region. Use it when you have a place name and need the code; when you already have the 6-digit code, do not search again and use leggi_dati_comune instead, to pick comuni by criteria use classifica_territori, and to browse a province use elenca_territori. All homonyms are returned, most similar first (narrow them with provincia or regione); an empty list means nothing resembles the text and is not an error. 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": {
      "nome": "<nome>"
    },
    "name": "cerca_comune"
  }
}

Input Schema

Name	Required	Description
`nome`	Yes	Name of the comune, full or partial, 2-80 characters, in any case; typos, missing accents and apostrophes are tolerated ("cassano adda" finds Cassano d'Adda).
`limite`	No	Maximum number of matches, 1-20, default 10.
`regione`	No	Optional: keep only comuni of this region, given by its Italian name ("Toscana", not "Tuscany"; Bolzano and Trento are in "Trentino-Alto Adige").
`provincia`	No	Optional: keep only comuni of this province, given by its Italian name in any case ("Trento", "Bolzano", "Monza e Brianza").

Output Schema

Name	Required	Description
`nota`	No	Set only when `provincia` or `regione` excluded every match: how many comuni with a similar name exist elsewhere. Null otherwise.
`fonte`	Yes	Source to cite with the figures: processed by DatiTuristici.it from institutional data (ISTAT).
`risultati`	Yes	Matching comuni, most similar name first, at most `limite`; empty when nothing resembles the text.

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 declare readOnly/idempotent/non-destructive/closed-world, yet the description adds substantive context beyond them: a 30 requests/minute shared rate limit, no authentication needed, homonyms returned most-similar-first, and that an empty list is a valid result rather than an error. These are exactly the behavioral facts an agent cannot derive 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.

Conciseness5/5

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

Dense but every clause earns its place: purpose first, then the code-already-known exclusion, then sibling routing, then result semantics and rate limit. No filler or repetition of the title.

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 detailed, and the description still names the key fields (ISTAT code, province, region). For a 4-parameter read-only search with full annotation coverage, nothing an agent needs 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.

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3; the description earns an extra point by explaining the relationship between homonyms and the optional filters ('narrow them with provincia or regione') — a usage-level insight the schema does not state. It does not add format detail beyond the schema, so it is not a 5.

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 ('Searches Italian municipalities (comuni) by name') plus the matching behavior (partial names, typos) and the returned payload. It explicitly differentiates itself from three named siblings, so an agent can route 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 explicit when-to-use ('you have a place name and need the code') and when-not-to-use ('when you already have the 6-digit code, do not search again'), each paired with the correct alternative: leggi_dati_comune, classifica_territori, elenca_territori. Nothing 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?