open-parlamento-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.3
Disambiguation4/5
The tools are organized around distinct Italian legal/parliamentary domains (e.g., constitutional case law, EU law, parliamentary bill status, open data), and each description clarifies its unique source and purpose. A few pairs like 'giurisprudenza_su' and 'cerca_sentenze_cost' could overlap in intent, but their descriptions make the article-focused vs. keyword-focused boundary clear.
Naming Consistency2/5
There is a strong but incomplete 'cerca_' verb_prefix convention covering about half the tools, while the remainder use noun phrases or question-style names ('novita_normative', 'cosa_modifica', 'chi_modifica', 'indice_di_forza'). This mixed convention makes tool discovery less predictable, despite the Italian naming being readable.
Tool Count3/5
With 24 tools, the server is at the high end of the 'heavy' range. The breadth is understandable given the domain spans Italian legislation, EU law, parliamentary workflow, open data, and statistics, but the count borders on excess and could be trimmed by consolidating some rare-purpose tools.
Completeness4/5
The toolset covers an unusually wide range of legal and parliamentary workflows: searching laws, case law, pending challenges, legislative amendments, bills, parliamentary members, votes, and open-data statistics. Minor gaps exist, such as no direct full-text retrieval of an arbitrary law article and limited ability to track a single bill across both chambers, but most reasonable queries can be satisfied.
Average 3.9/5 across 24 of 24 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the data source ('Dati Openpolis') and implies a read-only search operation, but does not disclose any behavioral traits such as response structure, pagination, rate limits, or whether filters combine additively. For a search tool, this is a notable gap.
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?
The description is a single, comma-laden sentence that packs in key features without redundancy. It is concise and information-dense. However, the flow is slightly dense with overlapping qualifiers, and no line breaks aid scannability, but this is a minor issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five optional parameters and no annotations, the description lacks essential context such as default behavior when no filters are supplied, how filters interact, and what a typical response contains. An output schema exists but is not shown in the description, so it does not substitute for missing guidance. This makes the tool under-specified for correct invocation in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It only explicitly clarifies 'esito' with examples and mentions 'fiducia' and 'chiavi' generically. The parameters 'testo', 'solo_finali', and 'solo_voti_chiave' are not meaningfully explained, leaving the agent without enough semantic information to populate them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches parliamentary votes ('Cerca VOTAZIONI') and lists key filtering aspects (by theme, result, confidence votes, key votes). This distinguishes it from siblings like cerca_legge or cerca_sentenze. However, the phrase 'per tema' is not directly reflected in the schema parameters (only 'testo'), and some mentioned concepts like 'voto segreto' and 'coesione' are not explicit parameters, slightly obscuring exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or conditions that would help an agent choose between this and sibling tools. Without such direction, an agent must infer usage from the tool's self-description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must compensate. It mentions 'Esclusiva Openpolis' but provides no behavioral details such as read-only nature, authorization requirements, or data update semantics. No side effects or limitations are disclosed.
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?
The description is concise and structured: first the primary purpose, then a note on data exclusivity, then parameter guidance. Each sentence earns its place; no redundant content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters, the description explains one well but leaves 'limite' undefined and does not clarify default behavior when 'ramo' is omitted. An output schema exists, so return values need not be described, but the missing parameter semantics create a small gap in callability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining the 'ramo' parameter with allowed values ('camera' o 'senato'), which the schema does not provide via enums. However, it completely omits the 'limite' parameter, leaving its meaning to be inferred from name/default only. Since schema coverage is 0%, this partial compensation brings it to a marginal pass.
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 clearly states a specific verb ('Classifica') and resource ('parlamentari per INDICE DI FORZA'), making it distinct from sibling tools like 'cerca_parlamentari' or 'profilo_parlamentare'. It conveys the ranking purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the optional 'ramo' parameter values but does not explain when to use this tool versus alternative search or profiling tools. No explicit when-to-use or exclusion criteria are given, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. 'Cerca' clearly indicates a read/search operation, and 'Dati curati Openpolis' adds data provenance. However, it does not mention potential behavior like returning all results when no filters are provided, pagination, or any rate limits. The read-only nature is implied by the verb, not explicitly stated.
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?
The description is concise and front-loaded: the main action and scope appear first, followed by data source and a key parameter hint. There is no fluff. The only minor issue is that the 'ramo' hint is placed at the end, but it is still clearly attached to the parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four optional string parameters with no schema descriptions, the tool is more complex than a simple search. The description explains only the 'ramo' parameter and leaves 'tipo', 'stato', and 'testo' ambiguous. Although an output schema exists, the agent still lacks sufficient guidance to construct a valid query, especially for status or type filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'ramo' parameter with allowed values 'Camera' or 'Senato'. The parameters 'tipo' and 'stato' are indirectly referenced via 'con tipo, iniziativa, fase dell'iter', and 'testo' may correspond to 'per tema', but no formats, allowed values, or examples are provided. This is insufficient for an agent to confidently populate all four parameters.
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 clearly states the tool searches ATTI/DDL across all branches ('tutti i rami') and lists the searchable dimensions: type, initiative, phase, first signatories, and rapporteurs. This specific verb-resource combination distinguishes it from sibling tools like cerca_ddl_senato or cerca_atti_camera, which are branch-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'tutti i rami' implicitly signals this is the cross-branch search tool, which contrasts with branch-specific siblings. However, it does not explicitly state when to use this tool instead of cerca_ddl_senato or cerca_atti_camera, nor does it provide exclusions or alternative guidance. Usage context is present but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns dataset-level aggregates (lists/statistics) rather than individual ruling texts, which is valuable behavioral context. However, it lacks details on pagination, rate limits, authentication needs, or potential error cases. The provided context helps but remains incomplete.
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 compact and front-loaded: two sentences deliver the tool's purpose, scope, and limitations without any fluff. Every phrase earns its place, and the dataset-level caveat is well positioned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one string parameter) and the presence of an output schema (though not shown), the description provides the essential context about data granularity. However, it omits usage guidance and any relationship to sibling tools, leaving an agent unsure when to choose this over comparable search tools. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate for documenting the sole parameter 'parole_chiave'. The description implicitly suggests topical keywords via examples like 'appalti', 'edilizia', 'ambiente', but it never explicitly states that the parameter accepts keywords or explains expected format, impact, or valid values. This is insufficient.
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 clearly states a specific verb (Cerca), a specific resource (GIUSTIZIA AMMINISTRATIVA including Consiglio di Stato + TAR), and the dataset-level scope. It explicitly mentions the data source (OpenGA portal) and topical categories, distinguishing it from sibling tools like cerca_sentenze_cassazione or cerca_sentenze_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for administrative justice dataset queries but does not state exclusions, prerequisites, or conditions that would route an agent to this tool over siblings. No when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output ('Restituisce gli atti modificanti con tipo di intervento ed evidence') and the data source (Normattiva), but it does not mention failure modes, input validation, or exact response behavior beyond the high-level return types.
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?
The description is two sentences long, front-loaded with the core purpose, and includes a useful example. Every phrase contributes, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description covers the essential input example and the type of output. It lacks explicit differentiation from sibling tools, but the scope is simple enough that the provided information is largely sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides an example ('Codice Penale art 575') that implies the expected format, but it does not formally define the 'norma' parameter, supported formats, or whether article references are flexible. Some compensation exists, but full clarity is missing.
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 clearly states a specific verb-resource pair: it identifies WHO modified a norm or article, using authoritative Normattiva relations. The example ('Codice Penale art 575') makes the input format concrete, and the tool is easily distinguishable from the sibling 'cosa_modifica', which likely answers the inverse question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by giving an example, but it does not explicitly state when to use this tool versus alternatives, nor does it name related siblings such as 'cosa_modifica'. There are no clear when-to-use or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the result contents (conversion status, conversion act, Normattiva link) and a cross-tool integration (concatenating normattiva_urn with cosa_modifica). However, it does not specify how the parameters behave (e.g., whether empty parameters retrieve all decrees, how 'stato' filters, or any restrictions such as date/coverage limits), leaving some behavioral ambiguity.
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 entire description is two short sentences that waste no words. It front-loads the main action and packs result details and an integration hint without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter search tool with an output schema, the description covers the core query and result fields, and even connects to a sibling tool via the normattiva_urn field. It lacks examples and a precise list of possible 'stato' values, but the presence of an output schema and default-empty parameters makes the remaining gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies that 'stato' refers to the 'stato di CONVERSIONE in legge' and that search is 'per tema,' which maps loosely to the 'testo' parameter. Yet it never names the parameters explicitly and doesn't describe allowed values, formatting, or the relationship between the two filters.
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 opens with 'Cerca DECRETI LEGGE', a specific verb and resource, and specifies the search scope ('per tema') as well as additional result details. It is unambiguous and distinguishes this tool from siblings like cerca_legge or cerca_ddl_senato by targeting a distinct legal act type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool instead of the many sibling search tools. There is no mention of alternatives, exclusions, or conditions that would route an agent toward or away from this tool; selection must rely only on the tool's name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful context by enumerating the types of organs and noting the data source (Openpolis), but it does not mention side effects, limitations, or behavior on invalid inputs. It is not misleading, but it lacks depth.
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 two sentences with no filler. It front-loads the main purpose and then adds the tipo values and data source. Every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. However, with no annotations and 0% schema coverage, the description should fully explain how to call the tool. It documents tipo but not ramo, and gives no indication of pagination or error handling. For a relatively simple listing tool, it is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly provides the allowed values for 'tipo' (groups|presidency|commission_councils), which is beyond the schema. However, it does not explain the 'ramo' parameter, leaving a gap for one of two parameters.
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 uses a specific verb 'Elenca' and names the resource 'ORGANI PARLAMENTARI' with clear subtypes (gruppi, presidenza, commissioni). It also distinguishes this tool from siblings by focusing on parliamentary bodies and specifying the tipo values, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing what the tool lists, but it never explicitly says when to choose this tool over alternatives like cerca_parlamentari or other research tools. No exclusions or alternative comparisons are provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool reads authoritative relationships from Normattiva and returns interventions grouped by type with norm/article and evidence, which adequately signals a read-only retrieval operation. It does not cover rate limits, matching details, or error behavior, but those are less critical for a query tool.
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 compact and front-loaded: it states the core question, gives a concrete example, and then describes the output shape. Every sentence contributes useful information, and there is no filler or repeated schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description covers the input, the output structure, and the data source, and an output schema is present to fill in return details. It would be slightly more complete if it clarified accepted input formats beyond the single example and explicitly distinguished the direction of the query from chi_modifica.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the single 'norma' parameter depends entirely on the description. The phrase 'una legge o decreto' and the example 'DL 19/2024' add real meaning beyond the bare string type, but accepted citation variants, normalization rules, and date or article handling remain unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete resource ('una legge o decreto') and the specific legal operations it resolves (MODIFICA/ABROGA/SOSTITUISCE/INSERISCE), while also describing the returned grouping by type. It is clear, but it does not explicitly contrast itself with the sibling chi_modifica, so it misses the top-level sibling-differentiation credit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example 'DL 19/2024' makes the intended input pattern clear and implies the use case: given a norm, find what it modifies or replaces. However, the description never states when to choose this tool instead of chi_modifica or any other sibling, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the output elements (titolo, data, link, numero/data GU) and the filtering behavior, but does not mention potential limitations like feed lag or that this is a read-only operation. This is adequate but not rich.
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?
The description is concise, with no fluff, and effectively front-loads the core purpose. It packs useful details in a compact paragraph. Slightly redundant use of the term 'GAZZETTA UFFICIALE' in both the first sentence and the usage examples, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 optional parameters and an output schema, the description covers the essential behavior, default series, filtering option, and return content. The only minor gap is not elaborating on serie possible values, but that is not critical given the default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'argomento' as a keyword in the title and mentions 'Serie Generale per default', which partially clarifies 'serie'. However, it does not enumerate possible serie values beyond the default, leaving some ambiguity.
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 ('Restituisce') and resource ('atti pubblicati in GAZZETTA UFFICIALE'), and clarifies the default series. It clearly distinguishes this tool from sibling tools focused on searching legislation by content, jurisdiction, or parliamentary activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage scenarios are provided: 'novità normative', 'ultimi decreti/leggi', 'cosa è uscito in Gazzetta di recente'. However, it does not explicitly state when not to use this tool or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Il sistema non fornisce annotazioni, quindi la descrizione deve dichiarare tutti i trattamenti. La descrizione elencai campi restituiti (numero, capienza, ente gestore, costo) e la fonte, ma non aggiunge particolari sul comportamento, come limitazioni sui risultati, paginazione o eventuali errori grafici. È sufficiente per un uso di base, ma non offre una trasparenza comportamentale approfondita.
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?
La descrizione è breve e diretto: un solo periodo che enuncia scopo, campi delegati, esempio e fonte, senza parole superflue. La struttura fronta il contenuto essenz% e l'esempio, combinandola in modo efficace.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Un solo parametro e output schema più ricco potrebbe coprire il ritorno, quindi la descrizione fornisce quanto necessario per un uso corretto: termine da inserire, campi cercati e fonte. Rispetto alla complessità bassa, è appropriato, anche se non tratta limiti o formati di output oltre la schema.
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?
Lo schema per il parametro 'luogo' ha copertura 0%, quindi la descrizione deve compensare. Essa specifica che il parametro è un luogo (comune/provincia/regione) e fornisce esempi, rendendo chiaro il significato senza necessità di ulteriori dettagli sul formato, sebbene non definisca regole precise sulla forma o validazione.
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?
La descrizione indica chiaramente l'oggetto della ricerca (centri di accoglienza per migranti) e specifica le informazioni restituite (numero, capienza, ente gestore, costo giornaliero). Fornisce inoltre esempi di input, distinguendosi dagli altri strumenti del contesto che riguardano ambiti giuridici o affini.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La descrizione spiega cosa fa e fornisce esempi (Napoli, Lombardia) ma non indica esplicitamente quando usare questo strumento rispetto ad alternative o quando non usarlo. Il contesto è chiaro per il dominio dei dati di accoglienza, ma manca una guida diretta sulle condizioni d'uso.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the search function and status field, but omits any behavior like data sources, freshness, limits, or how results are ordered. This is minimal coverage.
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?
Two concise sentences: the first states the core function and status, the second gives usage patterns. No redundant words; front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description need not detail return structure. It provides function, scope (Senate), status values, and usage examples. It lacks caveats like 'only current legislature' or accuracy disclaimers, but given the simplicity, it is reasonably complete.
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?
The input schema has only 'argomento' with no description, but the textual description clarifies that 'argomento' is the topic ('per tema') and supplies concrete examples (nucleare, sicurezza, fisco). This adds meaning beyond the bare 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?
The description clearly states the tool searches for pending legislation (DDL) in the Senate ('al SENATO') by topic and includes status. This distinguishes it from sibling tools like cerca_atti_camera (Chamber) or cerca_legge (generic laws).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit example queries ('quali DDL su <tema>' or 'a che punto è il DDL su <tema>') and sample topics. However, it does not mention when not to use it or point to alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Non ci sono annotazioni, quindi la descrizione deve compensare. Specifica la fonte (Openpolis) e le informazioni coperte, ma non chiarisce aspetti come la disponibilità di dati in tempo reale, eventuali limitazioni o cosa succede se il nome non viene trovato. Pur essendo utile, manca una piena trasparenza comportamentale.
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?
La descrizione è una singola frase compatta e informativa, con tutte le informazioni essenziali: contenuto della scheda, fonte e uso suggerito. Nessuna ridondanza.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considerando la semplicità dello strumento (un solo parametro, output schema presente), la descrizione copre gli elementi principali: cosa contiene, da dove provengono i dati e come usarlo. Manca solo dettaglio su eventuali errori o formati di risposta, ma il quadro è sufficiente per un uso corretto.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Lo schema ha un solo parametro 'nome' senza descrizione (copertura 0%). La descrizione aggiunge significato indicando che <nome> va sostituito con il nome del parlamentare, ma non specifica il formato (es. nome completo, maiuscole, gestione di omonimie). Quindi fornisce un minimo chiarimento ma non completo.
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?
La descrizione identifica chiaramente l'oggetto (scheda di un parlamentare) e specifica il contenuto (gruppo, ruolo, collegio, statistiche). Include anche un esempio d'uso ('profilo/scheda/presenze di <nome>') che aiuta a distinguerlo da strumenti simili come cerca_parlamentari.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La descrizione fornisce un contesto d'uso esplicito ('Usa per profilo/scheda/presenze di <nome>'), suggerendo quando impiegare lo strumento. Non menziona esplicitamente alternative o quando non usarlo, ma il contesto è abbastanza chiaro.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description takes the full burden of informing about behavior. It mentions the ordering by 'indice di forza', inclusion of photo/roles/state, and data source 'Openpolis'. It is not exhaustive (no pagination, rate limits, or error behavior), but these are not essential for a read-only search tool, and the essentials are covered.
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 extremely concise: a single sentence stating the purpose and followed by three short usage examples. Every word is informative, and the most essential information is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a search tool with an output schema, it does not need to detail return values. It provides all needed valuable context: purpose, examples, and data specifics. It could detail the default for 'solo_attivi', but the schema covers that, so overall this is complete enough.
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?
The schema has no published descriptions (0% coverage), so the description must compensate. It does so by stating searching by name and role, which maps to 'testo' and 'ruolo', and the description of 'stato in radius' suggests the ' solo_attivi' parameter. However, it does not explicitly explain each parameter further, leaving some implication to the name of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it searches for parliamentarians by name or role, with specific output features (photo, roles, status). The use cases given ('chi è <nome>', 'lista senatori', 'deputati di <gruppo>') reinforce its purpose and help distinguish it from other non-personal search tools, though it does not explicitly contrast with sibling tools like profilo_parlamentare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage scenarios ('chi è', 'lista senatori', 'deputati di <gruppo>'), which clearly indicate when to use the tool. It does not include explicit exclusions or alternatives, but the examples given are sufficient for a typical agent to pick the right tool without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the tool searches by topic and returns the legislative process status, which is useful. However, it does not mention limits, ordering, filters, or any operational caveats, leaving some behavioral aspects implicit.
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?
Two concise sentences with no filler. The core action and scope are front-loaded, followed by a practical usage example. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so return structure is covered. The description provides the purpose, usage context, and parameter meaning. Minor gaps like result limitations or error behavior exist but are not critical for such a straightforward search tool.
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 0%, but the description compensates by stating 'per tema', clarifying that 'argomento' is a topic/subject. For a single required parameter, this provides the essential meaning needed to invoke the tool correctly, though a concrete example value would have made it stronger.
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 clearly states a specific verb ('Cerca') and resource ('atti/proposte di legge alla CAMERA'), plus the search dimension ('per tema') and the returned information ('stato dell'iter'). It is easily distinguishable from sibling tools like cerca_ddl_senato by explicitly scoping to the Camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit example use cases ('quali proposte alla Camera su <tema>' or the state of a Camera bill), which clearly indicates when to use the tool. However, it does not explicitly mention when not to use it or point to alternatives, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It clearly states the source scope, the output type (explanation), and the citation format with examples. It could mention limitations such as non-mutating behavior or coverage boundaries, but for a search tool it is reasonably transparent.
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 three purposeful sentences: action and scope, return format, and usage cases. It is concise, well-structured, and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema and no annotations, the description covers what the tool searches, what to pass in, what it returns, and typical use cases. An example query would improve it further, but it is complete enough for agent selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that the single parameter 'domanda' is a legal question and gives topic categories, but it does not provide a concrete example query or phrasing guidance. The meaning is adequate but not deeply specified.
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 uses a specific verb and resource: it searches Italian law (Constitution + Penal Code) for an answer to a legal question. The explicit source scope distinguishes it from siblings such as cerca_legge_ue, cerca_sentenze_cost, and case-law tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases: 'cosa prevede/dice la legge, reati, pene, diritti, doveri, principi costituzionali', so an agent knows when to select it. However, it does not explicitly say when not to use it or name alternative tools, so it stops short of the highest rating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It discloses the return contents (relevant acts with CELEX, title, and EUR-Lex link) and the search source (EUR-Lex), but does not mention whether it is read-only, pagination, or error behavior. For a search tool this is adequate but not exhaustive.
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?
Two sentences, front-loaded with the action and resource, followed by return type and use case. No wasted words; examples are concise and illustrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, search action, output schema exists), the description covers what the tool does, its parameter, its returns, and when to use it. It lacks details like result limits or error handling, but these are likely covered by the output schema and not critical for a search tool.
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 has 0% description coverage, so the description must compensate. It explains the single parameter 'argomento' through context ('per argomento') and examples ('protezione dei dati', 'intelligenza artificiale', 'rifiuti'). This gives the agent sufficient understanding of the expected input.
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 clearly states the tool searches EU legislation (regulations, directives, decisions) by topic via EUR-Lex. It distinguishes itself from sibling tools like 'cerca_sentenze_ue' by explicitly targeting normative acts, not case law, and from 'cerca_legge' by specifying EU law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use it: 'Usa per il diritto UE o quando serve la base normativa europea' with examples. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return content (importo finanziato, fase dell'iter) and the data source (OpenPNRR, ODbL 1.0), which is useful. However, it does not mention potential side effects, rate limits, or any search behavior nuances, though a read-only search is implied by the tool type.
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 compact and front-loaded: the first sentence defines the tool's function and expected output, the second gives usage patterns and data provenance. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter search tool with an output schema, the description provides sufficient context: what it searches, what it returns, when to use it, and where the data comes from. It does not address error cases or pagination, but that is not essential for a basic query tool.
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 0% and the only parameter 'tema' has no schema description. The description compensates by explaining that tema can be a subject or a place, with examples. This gives the agent enough semantic understanding to populate the parameter correctly, even without explicit schema documentation.
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 ('Progetti del PNRR') with clear scoping by tema or luogo, and includes concrete examples ('asilo nido', 'ospedale Bari', 'banda larga'). It distinguishes this tool from the sibling tools, which all concern legal or parliamentary topics, not PNRR projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage patterns ('Usa per 'progetti PNRR su <tema>', 'fondi PNRR a <luogo>'') that tell the agent when to invoke this tool. It does not explicitly mention when not to use it, but the domain separation from siblings makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It does disclose the output structure ('Restituisce valore, unità, periodo e link alla fonte') and the authoritative source (Eurostat), but it does not mention potential side effects, permissions, or data latency. For a read-only search tool, this is adequate but not encompassing.
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 compact and well-structured: it states the resource, the return fields, and the usage condition in three short sentences. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the core aspects: what it does, what it returns, and when to use it. It lacks an explicit statement about the parameter's exact format, but the topic list provides sufficient guidance for correct invocation. Minor gaps around error handling or data freshness do not undermine usability.
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?
The schema coverage for 'argomento' is 0% and the schema only provides the type string. However, the description lists example topics (disoccupazione, occupazione, inflazione...), which implicitly tells an agent what values to pass. This compensates for the lack of schema description, though it does not explicitly state that 'argomento' should be one of these topics.
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 specifies the exact resource ('STATISTICHE UFFICIALI sull'Italia (Eurostat)') and a clear verb ('Cerca'), while listing concrete topics (disoccupazione, inflazione, PIL, etc.) and return fields. This clearly distinguishes it from sibling legal/legislative tools like cerca_legge or cerca_sentenze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage trigger: 'Usa quando la domanda chiede un NUMERO/tasso/percentuale', which tells an agent when to invoke this tool. It does not explicitly mention alternatives or when not to use it, so it lacks the exclusion clause for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Non sono presenti annotazioni, quindi la descrizione porta il peso del contesto. Spiega che lo strumento cerca 'casi PENDENTI' da 'Atti di promovimento', ma non dettaglia il comportamento oltre la ricerca (es. se restituisce un elenco, come interpretare l'assenza di risultati, o l'autorevolezza della fonte). Manca trasparenza sul formato di risposta o su eventuali limitazioni, ma la natura di sola lettura è implicita.
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?
La descrizione è compatta e ben strutturata: inizia con l'azione principale, fornisce due esempi concreti e conclude con le domande d'uso tipiche. Non contiene parole superflue; ogni frase contribuisce a chiarire scopo e utilizzo.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Per un tool con un solo parametro, la descrizione fornisce input esempi, scopo e domande d'uso, coprendo gli elementi essenziali. L'assenza di output schema nel contesto non pesa perché viene segnalato che esiste. Manca solo qualche dettaglio su casi limite o su cosa restituisce esattamente in caso di risultati multipli, ma non è bloccante.
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?
Nonostante la copertura dello schema sia 0%, la descrizione compensa pienamente fornendo esempi espliciti del formato del parametro 'norma' (es. 'legge 197/2022 art 1', 'DL 145/2024 art 16'). Questo spiega chiaramente come costruire il valore atteso, aggiungendo significato oltre al semplice tipo stringa.
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?
La descrizione specifica chiaramente che lo strumento verifica se una norma/articolo è attualmente impugnata davanti alla Corte Costituzionale, usando il verbo 'è attualmente IMPUGNATA' e indicando la risorsa 'Corte Costituzionale'. Fornisce anche esempi concreti ('legge 197/2022 art 1', 'DL 145/2024 art 16') che aiutano a distinguerlo da strumenti simili come cerca_sentenze_cost, focalizzandosi su casi pendenti.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La descrizione esplicita quando usare lo strumento con domande esemplificative ('Usa per 'è sotto giudizio della Consulta?' o 'ci sono ricorsi pendenti su <norma>?''). Non menziona esplicitamente quando non usarlo o alternative, ma il contesto d'uso è chiaro e lascia poco all'inferenza.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does convey the input constraint (1-3 parole chiave), the output structure (titolo, ente, fonte e URL), and the real-data nature. However, it does not mention potential network dependencies, timeouts, or how results are ranked or limited — typical for a search tool but absent here.
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 compact and front-loaded: the core function appears in the first clause, followed by input limits, output content, and use cases. Every sentence adds value with no redundancy.
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?
For a single-parameter search tool, the description covers function, data sources, input requirements, output fields, and target use cases. An agent has enough to decide when to invoke it and what to pass. The presence of an output schema further reduces the need to explain return formats.
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?
With 0% schema description coverage, the description fully defines the only parameter 'parole_chiave' by giving format guidance (1-3 keywords) and concrete examples ('ponte stretto', 'qualità aria', 'bilancio comune'). This adds meaning far beyond the bare string type in the 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?
The description uses a specific verb ('Cerca') and a clear resource ('dataset di dati pubblici REALI sui portali open-data italiano ed europeo'), making its function unambiguous. It also names the specific portals (dati.gov.it, data.europa.eu), which distinguishes it from sibling tools that search legislation, statistics, or parliamentary records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('Usa per opere pubbliche, costi, bilanci, appalti, ambiente, statistiche o numeri/fatti verificabili'), providing clear context without excluding any specific alternatives. It stops short of naming when NOT to use it or pointing to sibling tools, but the use cases are sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output structure (returns pronouncements with CELEX, title, and link) but does not describe pagination, empty-result behavior, or any rate/access limitations. For a search tool, the disclosed return format is useful, but richer behavioral context is missing.
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?
Three sentences with no filler: purpose is front-loaded, the return content is stated in the second sentence, and usage guidance with examples lands last. Every sentence earns its place.
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?
For a one-parameter search tool with an output schema available, the description covers the purpose, the scope (CELEX sector 6), the return content, and the usage context with examples. The output schema handles the return shape, so nothing essential is missing for an agent to invoke this tool.
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 0%, so the description must compensate. It defines the one parameter 'argomento' through the phrase 'per argomento' and reinforces the meaning with examples ('protezione dei dati', 'concorrenza'), which adds significant semantic value beyond the bare name 'argomento' in the 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?
The description uses a specific verb ('Cerca'), names the precise resource (sentences of the European Union - EU Court of Justice / General Court), specifies the source (EUR-Lex CELEX sector 6) and distinguishes this from siblings by focusing on EU case law. It clearly says what the tool does and, by naming the courts and sector, implicitly separates it from tools like cerca_sentenze_cassazione (Italian case law) or cerca_legge (laws).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on when to use the tool: 'Usa per la giurisprudenza UE o come la Corte di Giustizia ha interpretato il diritto dell'Unione' and provides concrete examples ('protezione dei dati', 'concorrenza'). It does not explicitly state when not to use it or name an alternative tool, but the context is clear enough given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the data source (SentenzeWeb), temporal limitation (ultimi ~6 anni), and the return fields (numero/anno/sezione, tipo, articoli citati, link). This is solid transparency for a search tool, though it does not mention potential absence of results or rate limits.
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?
Two sentences, front-loaded with the core purpose and scope, followed by output summary and usage examples. No filler or redundant content; every sentence contributes to effective tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, the presence of an output schema, and the clear scope/examples, the description is nearly complete. It covers source, time window, legal domains, and typical use cases. Minor omissions such as explicit exclusions compared to sibling tools prevent a perfect score.
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 0%, so the description must compensate for the undocumented 'argomento' parameter. It does so effectively by framing it as a topic or reato and giving four concrete examples (omicidio stradale, licenziamento, truffa, diffamazione), adding meaning beyond the bare string type.
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 clearly states the tool searches Cassation Court judgments (civil and criminal) by topic, via SentenzeWeb, and specifies the time range. It also distinguishes itself from siblings by explicitly naming the Court of Cassation and 'giurisprudenza di legittimità', making it easy to differentiate from constitutional or administrative justice tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Usa per la giurisprudenza di legittimità su un reato o un tema' with concrete examples. It does not explicitly state when not to use it or name alternatives, but the examples and court-specific scope make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Non ci sono annotations, quindi la descrizione deve coprire il comportamento. Spiega che il tool restituisce le sentenze e il loro esito, ma non dettaglia il formato di ritorno, eventuali limiti o assunzioni (es. se la ricerca è per corrispondenza esatta). Per un tool di sola lettura semplice, il livello è minimo sufficiente ma manca qualche precisione operativa.
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?
Tre frasi dense: la prima definisce chiaramente cosa fa il tool, la seconda dà esempi, la terza mostra le domande utente. Nessun contenuto ridondante, tutto è utile e ben organizzato con la funzione front-loaded.
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?
Il tool ha un solo parametro, è semplice e la descrizione copre scopo, formato dell'input e casi d'uso tipici. La presenza di un output schema (indicato nei segnali) solleva la descrizione dal dover spiegare il ritorno. L'insieme è completo per un uso corretto.
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?
Il parametro 'norma' non ha alcuna descrizione nello schema (coverage 0%), quindi la descrizione è l'unica fonte di significato. Fornisce esempi concreti di formato ('art. 21 Cost.', 'art. 186 codice della strada') e chiarisce il tipo di input atteso, compensando completamente la mancanza nel JSON 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?
La descrizione usa un verbo specifico ('decidere') e una risorsa chiara (sentenze della Corte Costituzionale), con l'esito discriminante (incostituzionale/infondata/inammissibile). Include esempi concreti e si distingue nettamente dai sibling come cerca_sentenze_cassazione o cerca_giustizia_amministrativa per il riferimento esplicito alla Consulta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Fornisce chiaramente le domande tipiche che l'agente può gestire ('la Consulta si è pronunciata su...?' o 'è mai stato dichiarato incostituzionale...?'), indicando il contesto d'uso. Non esclude esplicitamente casi alternativi (es. altre corti), ma la specificità 'Corte Costituzionale' orienta la scelta rispetto ai sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains what is searched (official massime), the time span covered (1956→oggi), and what is returned (numero/anno, massima sintetica, link). This goes beyond the schema, although it does not mention potential limitations like result limits or ordering, so it is strong but not exhaustive.
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 two sentences long, with every sentence earning its place. The first sentence states the core action and scope, the second sentence describes the output and gives direct usage guidance. There is no redundant or filler content, and the key differentiator ('CORTE COSTITUZIONALE') is front-loaded.
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?
For a simple one-parameter search tool, this description is complete: it specifies the corpus, the temporal coverage, the output fields, and the kinds of queries that are appropriate. An output schema exists, so the description need not detail the exact response structure. The sibling context further clarifies that this tool is specifically for Italian constitutional court decisions.
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?
The input schema only provides 'argomento' as an unadorned string with no description, giving 0% schema coverage. The description compensates fully by explaining that the parameter is a legal topic, right, or article, and provides three concrete examples ('libertà di stampa', 'fine vita', 'ergastolo ostativo'), which clearly disambiguates the expected value 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?
The description clearly identifies the verb 'Cerca' and the precise resource 'SENTENZE della CORTE COSTITUZIONALE', further narrowing the scope with 'per argomento' and 'nelle massime ufficiali'. It also states the date range and even gives examples of appropriate queries, making it easily distinguishable from sibling tools focused on other courts or legal sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Usa per la giurisprudenza costituzionale su un tema/diritto/articolo', with concrete examples. It does not explicitly mention alternatives or say when not to use it, but the reference to 'costituzionale' and the sibling tool names like cerca_sentenze_cassazione and cerca_sentenze_ue make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![open-parlamento-mcp MCP server](https://glama.ai/mcp/servers/giuliogarofalo/open-parlamento-mcp/badges/card.svg)](https://glama.ai/mcp/servers/giuliogarofalo/open-parlamento-mcp)

Score Badge

Copy to your README.md:

[![open-parlamento-mcp MCP server](https://glama.ai/mcp/servers/giuliogarofalo/open-parlamento-mcp/badges/score.svg)](https://glama.ai/mcp/servers/giuliogarofalo/open-parlamento-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/giuliogarofalo/open-parlamento-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server