domustudio-mcp-server

Elenca condomini

domustudio_list_condomini

Read-onlyIdempotent

Lists all condominiums in a Domustudio archive, returning stable IDs for use with other tools. Search by name, city, address, or tax code locally.

Instructions

Elenca i condomini presenti in un archivio Domustudio.

L'endpoint restituisce sempre la lista completa: non è paginato e non accetta filtri lato API. Il parametro "ricerca" filtra i risultati localmente su intestazione, città, provincia, indirizzo e codice fiscale.

L'"id" di un condominio è l'unico identificatore stabile esposto dall'API Domustudio, ed è il valore da passare come "condominio_id" a domustudio_list_persone.

Args:

archivio (string, opzionale): archivio da interrogare
ricerca (string, opzionale): sottostringa, confronto case-insensitive
response_format ('markdown' | 'json'): default 'markdown'

Restituisce (json): { "archivio": string, "conteggio": number, "elementi": [ { "id": number, "intestazione": string, "indirizzo": string, "cap": string, "citta": string, "prov": string, "codFisc": string, "amministratore": { "nome": string, "email": string, ... } } ] } In formato markdown vengono mostrati intestazione, id, indirizzo, codice fiscale e amministratore; il formato json riporta il record completo restituito dall'API.

Usare quando: serve l'id di un condominio, o l'anagrafica dello stabile. Non usare per: elencare le persone di un condominio (domustudio_list_persone) o i fornitori (domustudio_list_fornitori).

L'API Domustudio è di sola lettura: espone solo tre endpoint GET. Domustudio resta il sistema di registrazione — ogni correzione va fatta da un operatore dentro il gestionale.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ricerca`	No	Filtro locale su intestazione, città, provincia, indirizzo, codice fiscale.
`archivio`	No	Nome dell'archivio Domustudio da interrogare. Opzionale se ne è configurato uno solo; usare domustudio_list_archivi per l'elenco.
`response_format`	No	'markdown' per una sintesi leggibile dei campi principali, 'json' per il record completo.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ricerca`	No
`archivio`	Yes
`elementi`	Yes
`conteggio`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Sep 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavior: the endpoint is never paginated, accepts no API-side filters (the 'ricerca' filter runs locally), the 'id' is the only stable identifier, and Domustudio is the system of record. It restates read-only, which duplicates annotations, but the pagination/filter/identifier disclosures are substantial.

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 and scope, then structured into Args / Restituisce / Usare quando sections. Some redundancy between the prose and the explicit Args/Restituisce blocks, but every block earns its place and none is padding.

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?

Despite an output schema already existing, the description explains both markdown and json return shapes and the local-filtering model, which is the non-obvious part an agent needs. Combined with annotations and full schema coverage, an agent has everything required 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 3 baseline applies, but the description adds meaning beyond the schema: 'ricerca' is a case-insensitive substring, and 'id' is framed as the value to pass as 'condominio_id' elsewhere. Only marginal gains over the well-documented schema.

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 ('Elenca i condomini presenti in un archivio Domustudio') and explicitly distinguishes itself from siblings by naming domustudio_list_persone and domustudio_list_fornitori as out-of-scope. An agent can route correctly 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?

Has explicit 'Usare quando' (need a condominio id or building registry data) and 'Non usare per' clauses with the alternatives named, plus a concrete handoff rule: use the returned 'id' as 'condominio_id' in domustudio_list_persone. 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.

Deploy Server