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

The description adds behavior beyond the annotations: the tool returns immediately rather than waiting for login, the user must manually authenticate via SPID, CIE, CNS, or eIDAS, and the session lasts roughly two hours. These details are essential for correctly sequencing the agent's next action with stato_sessione.

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

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

The description is short, front-loaded, and every sentence carries useful operational information: what opens, what the user must do, what the agent should do next, and how long the session lasts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no input parameters and no output schema, the description provides enough context to invoke it correctly. It explicitly says the tool returns immediately and directs the agent to verify login via stato_sessione, which is the key missing piece an agent would otherwise need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

There are zero parameters, so there is no parameter ambiguity for the description to resolve. The baseline for a parameterless tool is 4, and no additional parameter guidance is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it opens a Chrome or Edge window on the Banca Dati di Merito login page. It clearly distinguishes this action from the sibling stato_sessione by explaining that this tool starts authentication and that the user must complete login separately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear usage context: the user must complete login in the opened window, then the agent should check with stato_sessione. It also notes the session lasts about two hours. It does not explicitly say when not to use it, but the authentication workflow is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds the non-obvious behavioral fact that the output grouping dimension changes with the arguments supplied. It does not describe the shape of the counts or what happens with partial combinations beyond the stated hierarchy, so it stops short of full transparency.

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

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

Front-loaded with the purpose in the first clause, then a compact argument-to-grouping table, then a routing note. Four short sentences, no filler, and each one carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and six optional parameters, the description covers the drill-down logic and the sibling routing well enough to call the tool correctly. It leaves the area/penale distinction and the form of returned counts to the schema or to inference, a modest gap rather than a blocking one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 50%, and the description compensates by explaining the role of distretto, ufficio, materia, anno and mese in the aggregation hierarchy — meaning the schema alone would not convey. It never mentions the area parameter (default CIVILE, which also counts PENALE), leaving one materially relevant parameter explained only by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Conteggi dell'archivio della Banca Dati") and anchors it to a concrete referent (the Archivio section of the site). It explicitly separates itself from cerca_provvedimenti, so an agent can tell counting from listing without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives an explicit drill-down rule keyed to which argument is supplied: no args = per distretto, distretto = per ufficio, ufficio = per materia with optional anno/mese. It also names the alternative tool and the exact criterion to use for listing rulings, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description's '(sola lettura)' mostly repeats structured information. It does add useful behavior beyond annotations by saying results include subfolders, but it does not describe return structure, ordering, or pagination behavior.

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

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

The description is a single well-formed sentence with the verb and resource front-loaded. Every element earns its place by stating scope, read-only behavior, and subfolder inclusion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing tool, the description covers the essential scope and mentions subfolders. It is slightly incomplete because there is no output schema and the description does not clarify what fields each folder result contains, but the operation is simple enough that this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool has zero parameters, so there is no parameter semantics for the description to compensate for. Baseline 4 is appropriate because the empty schema is self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Elenca le cartelle personali' created by the user in the database, including subfolders. That is enough for an agent to understand the operation, though it does not explicitly contrast this listing tool with the sibling 'leggi_cartella_personale' or other folder/search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the scope 'cartelle personali che l'utente ha creato' and the '(sola lettura)' note, which signals a safe listing operation. However, there are no explicit when-to-use or when-not-to-use instructions relative to siblings such as 'leggi_cartella_personale' or 'ricerche_salvate'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover read-only and open-world behavior, so the description's added value is the epistemic warning that an abstract is not an official massima and must be verified in the text, plus the default ordering when no filters are given. That is real context beyond the structured fields, though return shape and pagination limits are left to the schema.

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

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

Four short sentences: purpose, use case, reliability caveat with the exact fallback tool, and default behavior. Front-loaded with the core action and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with nested objects and no output schema, the description covers intent, default behavior, and the critical trust caveat. It does not describe what a result row contains (e.g. how to reach the underlying provvedimento), which would help an agent chain calls, but nothing essential to invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 82%, with pagination (da, quanti), date field semantics, and criteria values already documented in-schema. The description adds only the implicit default of unfiltered results, so the schema does the heavy lifting and baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource and then defines that resource ("le sintesi dei principi affermati nei provvedimenti"), which lets an agent tell abstracts apart from full decisions. It does not explicitly name cerca_provvedimenti as the alternative for full-text decision search, so sibling differentiation is only partial.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

"Usalo per gli orientamenti su una questione" gives a clear use condition, and the caveat routes the agent to leggi_testo_provvedimento for verification. It also states the no-filter default (latest published), but gives no explicit when-not condition against cerca_provvedimenti.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover read-only and open-world nature, yet the description still adds real behavioural content: default ordering, the fact that excerpts are highlighted fragments, and that abstracts are linked rather than embedded. The explicit warning that fragments are insufficient to determine the outcome is valuable beyond any structured field.

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

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

Four short sentences with zero filler: capability, default behaviour, return shape, then the reliability caveat and the escape hatch. The most decision-relevant constraint (don't report holdings from excerpts) lands before the reader stops reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with nested objects and no output schema, the description covers what is returned (estremi, metadati, estratti, abstract) and the main usage trap. It leans on the schema for field-level detail, which is appropriate given 82% coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is high (82%), including enum meanings and paging semantics, so the schema carries most parameter meaning. The description only adds that search works by text, field criteria and dates; it says nothing extra about quanti/da paging limits or the criteria-vs-escludi split. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (search judgments, orders and decrees in the Banca Dati) plus the three search axes: text, field criteria and dates. It also declares the no-filter default (latest published) and what is returned. It differentiates from leggi_testo_provvedimento but not from near neighbours such as cerca_abstract or cerca_valori.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives clear operating context: without filters it returns the most recently published items, and it explicitly routes the agent to leggi_testo_provvedimento before asserting what a decision held. It does not say when to prefer this over cerca_abstract or when field criteria should come from risolvi_criteri (that is only in the schema).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuine behavioral semantics beyond them: matching is substring/containment based, not exact, as shown by the '1453' inside 'ART. 1453 C.C.' example. It does not mention that results are currently limited to CIVILE, though that constraint lives in the area parameter's schema description.

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

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

Two sentences, front-loaded with the core purpose, then the disambiguation rule. No filler, and the example is compact and load-bearing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a read-only lookup tool with no output schema: purpose, scope, and alternative are all covered. However, it says nothing about return shape (list of distinct values? ranked? paged?) or about the CIVILE-only result limitation, which materially affects whether a call is useful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 33%, and 'campo' and 'testo' carry no schema descriptions, so the description must compensate—it does, mapping the four enum values to natural-language labels and illustrating the matching behavior for 'testo'. 'area' is left to the schema, which does document it, so the gap is minor rather than critical.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Cerca') and resource ('valori di un singolo campo che contengono un testo') and enumerates the concrete fields (uffici, giudici, parole chiave, riferimenti normativi). The worked example ('1453' → 'ART. 1453 C.C.') makes the operation unambiguous and distinguishes it from the broader sibling risolvi_criteri.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly routes the agent: 'Per risolvere un nome senza sapere il campo usa risolvi_criteri' names the alternative and the exact condition that selects it. The single-field constraint is also stated up front, which implicitly excludes multi-field resolution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one behavioral detail beyond them — that results are grouped by court of appeal district — but says nothing about matching semantics for the filter (exact name? case sensitivity?), pagination, or what happens with an unknown district.

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

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

Two short sentences with no filler; the default behavior (grouped by district) is front-loaded and the optional filter behavior follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only enumeration tool with one fully documented optional parameter and no output schema, the description covers what the tool returns and how to filter it. Only the fine detail of district-name matching is left implicit, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% and the single `distretto` parameter is documented with an example (BOLOGNA), so the schema carries the detail. The description only restates that the parameter filters the output to that district, adding little beyond the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it enumerates the judicial offices present in the Banca Dati and says they are grouped by court of appeal district. That is clearly distinguishable from sibling tools such as cerca_provvedimenti or elenca_valori, though it does not name an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The second sentence implies usage of the optional filter (pass `distretto` to narrow the result to one district, omit it to list everything), which is helpful context. However, there is no explicit when-to-use versus when-not guidance and no named alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already flag this as a read-only, open-world operation, so the safety profile is covered. The description adds that the returned values are exhaustive ("tutti") and authoritative in form, but says nothing about whether results vary by area or how they should be consumed.

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

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

A single front-loaded sentence with no filler; the purpose and the output contract are packed into one clause without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description does not state the return shape beyond implying a list of strings, nor whether the enumeration is scoped by 'area'. For a two-parameter lookup tool this is adequate but leaves real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 50%: the 'area' parameter is well documented in the schema, while 'campo' relies on its enum. The description maps onto 'campo' by naming materia and ruolo, but adds nothing about 'area' or the fact that current searches only return CIVILE results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("elenca") and resource ("tutti i valori ammessi di materia o ruolo"), so the agent knows this is an enumeration of allowed lookup values rather than a search. It does not differentiate itself from the near-sibling cerca_valori, which an agent could easily confuse with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The clause "nella forma esatta da usare come criterio di ricerca" implies the intended downstream use (feeding search criteria), which is useful implied guidance. However, it never says when to prefer this over cerca_valori or risolvi_criteri, nor whether the list depends on the area parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that results are paired with document counts, which is useful behavioral content, but it omits how many keywords are returned, how they're ordered, whether a limit exists, and the schema's important caveat that statistics include PENALE while searches do not.

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

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

A single front-loaded sentence with no filler; the resource and the returned value come first. It is efficient, though so short that it leaves obvious questions unanswered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no required parameters, so the description is the only place a caller could learn the shape, size, or ordering of the keyword list — and it says nothing about those. Adequate for a simple read tool, but it leaves the return contract partially undefined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100% and both parameters carry their own descriptions with an enum and a default, so the schema does the work. The description adds no meaning about area/tipo beyond restating that both domains exist, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Restituisce le parole chiave più usate nei provvedimenti o negli abstract, con il numero di documenti" names a specific operation (frequency aggregation) over a specific resource, which distinguishes it from the cerca_*/leggi_* siblings. It just doesn't explicitly name any sibling to contrast with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The verb "più usate" plus "numero di documenti" implies statistical/aggregate usage rather than document retrieval, so the intended use case is inferable. But the description never says when to prefer this over cerca_provvedimenti or elenca_valori, and gives no exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds genuinely useful context beyond them by detailing the returned payload, including that personal notes and cross-referenced conforming/non-conforming precedents are included. It stops short of noting behavior when the id is missing or how the area/includi_cartelle flags affect retrieval.

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

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

A single sentence that leads with the verb and payload, with no rhetorical padding; every clause names a distinct piece of returned content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates well by enumerating the fields of the returned abstract. It is slightly short on failure behavior and on how area/includi_cartelle modify the result, but an agent can call it correctly from this definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, so the schema already explains id, area (CIVILE-only search results) and includi_cartelle. The description mentions personal notes being returned, which loosely links to includi_cartelle, but adds no syntax or conditional detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Restituisce) and resource (un abstract completo) and enumerates exactly what the returned object contains: title, principle text, provision details, linked precedents, personal notes. It clearly reads as a fetch-by-id tool versus the search siblings, though it never names cerca_abstract or cerca_provvedimenti to make the distinction explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the notion of fetching a complete abstract presupposes you already hold an identifier (the schema's id param says 'Identificativo restituito dalle ricerche'). There is no explicit when-to-use versus cerca_abstract/leggi_provvedimento and no stated exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so "(sola lettura)" is largely redundant confirmation. The description does add the useful fact that results contain heterogeneous items (documents, abstracts, subfolders), but says nothing about pagination, ownership/permission requirements for a "personal" folder, or behavior on an unknown id.

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

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

A single front-loaded sentence with the resource first and the returned contents enumerated at the end. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with full schema coverage and no output schema, stating the composition of the returned folder is close to sufficient. The remaining gap is disambiguating the id's provenance and distinguishing this tool from the cartelle_personali listing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100% and there is only one parameter, so the schema carries the semantics. The description adds only mildly by implying the id refers to a personal folder; it does not clarify whether that id comes from cartelle_personali or from the general searches.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ("Restituisce") with a precisely scoped resource ("contenuto di una cartella personale dell'utente") and enumerates what is returned (provvedimenti, abstract, sottocartelle). It stops short of naming how it differs from the sibling cartelle_personali, which an agent could reasonably confuse with this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the caller must already have a folder id (schema says "Identificativo restituito dalle ricerche"), so the read-a-known-folder scenario is inferable. No explicit when-to-use/when-not or routing to cartelle_personali versus leggi_provvedimento is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful disclosure about what content is returned (including 'note personali dell'utente' and adjacent provvedimenti in the same giudizio), which hints at scope expansion, but says nothing about the effect of includi_cartelle or about data-access implications of pulling personal notes.

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

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

A single front-loaded sentence with the return scope enumerated; dense but every clause carries information about the payload. Slightly list-heavy, but no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of explaining what comes back, and it does so thoroughly: estremi, giudici, materia, parole chiave, riferimenti normativi, esito, abstract, prev/next provvedimento, personal notes. Combined with full schema coverage and read-only annotations, an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, so both optional parameters (area, includi_cartelle) are already documented with defaults and caveats. The description adds no parameter-level meaning beyond implying the tool works on a single 'provvedimento'; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (returns complete metadata of a provvedimento) and enumerates exactly which metadata fields come back, which implicitly separates it from siblings like leggi_testo_provvedimento or leggi_abstract. It never names those siblings, so the differentiation is inferential rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the schema note 'Identificativo restituito dalle ricerche' suggests the flow search-then-read, but the description itself gives no when-to-use guidance and no routing (e.g., 'use leggi_testo_provvedimento for the full text'). The agent must infer the alternative from the field list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnly/openWorld annotations, the description discloses two non-obvious behaviors: text is pseudonymized by the Banca Dati (parties become Parte_1, Controparte_1) and long texts are returned in chunks. The weak point is that it references `continua` and `prossimo_da`, which appear in neither the input schema nor an output schema, leaving their origin unexplained.

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

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

Two dense sentences with no filler; the core purpose comes first and the pagination mechanics follow. The backtick-heavy continuation clause is compact but slightly opaque on a first read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and low schema coverage, the description carries the burden well by explaining pseudonymization, chunking and the continuation loop. It is not fully complete: the response fields `continua` and `prossimo_da` are never defined, and `max_caratteri` behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 33% (only `id` is documented), so the description must compensate. It explains the role of `da_carattere` in continuation but says nothing about `max_caratteri`, its 20000 default or 60000 cap, which materially affects how many calls are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it returns the full text ('testo integrale') of the provvedimento, which distinguishes it from the abstract/metadata siblings (leggi_abstract, leggi_provvedimento). It does not name those siblings explicitly, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives concrete guidance for repeated calls (if `continua` is true, call again with `da_carattere` = `prossimo_da`), which is real usage instruction. However, it never says when to prefer this over leggi_provvedimento or leggi_abstract, nor any preconditions (e.g., the id must come from a prior search).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: results are aggregated two different ways and include areas other than CIVILE, which could otherwise mislead an agent. It says nothing about result format, size, or refresh recency.

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

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

A single compact sentence that front-loads the core question ('Quanti ... ha pubblicato') followed by the two aggregation modes. Nothing is wasted, though the trailing clause about non-CIVILE areas is slightly cryptic in placement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-parameter read-only count tool with no output schema, the description gives enough: what is counted, the two grouping levels, and the caveat about other areas. The exact response fields are not spelled out, but the shape (totals per district / per office) is conveyed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining what the parameter changes: without it you get district-level totals, with it you get a row per office within that district. That grouping semantics is not derivable from the schema's 'Distretto di corte d'appello, per esempio BOLOGNA'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource pair ('Quanti provvedimenti e abstract ... ha pubblicato'), making clear this is a counting/aggregation tool rather than a document retriever like the cerca_* siblings. It does not name any sibling explicitly, so the distinction from cerca_provvedimenti or frequenze_parole_chiave is only implicit in the word 'Quanti'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage (ask for totals when you want counts, add `distretto` for per-office breakdown) but never states when to prefer this over cerca_provvedimenti or elenca_uffici, nor any prerequisites. The conditional phrasing 'oppure, con `distretto`' is a useful usage hint but not an explicit when/when-not rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The parenthetical "(sola lettura)" merely restates readOnlyHint=true from the annotations, adding no new information. Nothing is said about pagination, result limits, what a saved search record contains, or the openWorldHint implication that results may include external/unknown entries.

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

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

One short sentence with the resource front-loaded and zero filler. It is efficient, though the terseness is part of why other dimensions are thin.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-parameter read tool with annotations covering safety and a fully documented schema, the essential information is present. Still missing is whether the tool requires an authenticated session and how many saved searches are returned, which matters given the openWorld annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100% and the single enum parameter 'tipo' is fully documented in the schema, including both values and their meanings. The description adds nothing about it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: "Elenca le ricerche che l'utente ha salvato nella Banca Dati", telling the agent this returns a list of saved searches rather than documents. It does not, however, distinguish itself from plausible siblings such as cartelle_personali or archivio, which an agent could easily confuse with saved-search listings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no statement of when to use this tool, what prerequisites exist (e.g. being logged in via accedi), or which sibling to prefer when the user wants folders or documents instead of saved searches. Usage is only inferable from the name and the resource noun.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description meaningfully adds the key behavioral constraint — that downstream search only accepts the exact value returned — which an agent would not infer from the schema. It does not say what happens when a name cannot be resolved (no match, ambiguity), which keeps it below 5.

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

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

Two sentences, zero waste, with the purpose front-loaded and the usage rule immediately after. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete on intent, usage and the exact-value constraint, and there is no output schema to explain. However, since no output schema exists, the description could have said what form the resolved criteria take (field/value pairs) so the agent knows how to feed them downstream. That is the only remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, so the schema already explains area (CIVILE-only results, PENALE for statistics), tipo enum, and testo. The description adds that 'testo' is the raw user-spoken name, but nothing beyond the schema about area/tipo. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it transforms a user-spoken name (court, city, judge, topic) into exact Banca Dati criteria with the correct field. This clearly separates it from the search siblings (cerca_provvedimenti, cerca_valori) by framing it as a pre-search resolver.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

"Usalo prima di cercare per ufficio, distretto, giudice, parola chiave o materia" gives explicit ordering and target cases, plus the rationale that criteria only work with exact values. It lacks an explicit "when not to use" or a named alternative such as elenca_valori/cerca_valori for browsing, 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.

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

Beyond the annotations it discloses that a file is written to a user-configured folder with a concrete default path, that existing files are never overwritten (consistent with idempotentHint=false and destructiveHint=false), that the file path is returned, and that PDF generation can exceed thirty seconds. These are exactly the operational facts an agent needs and none of them are recoverable from the annotations.

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

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

Three tight sentences: what it does and where, the overwrite policy, the latency caveat, then the alternative tools. Every sentence carries distinct information with no repetition of the title or name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by stating that the file path is returned. Combined with the latency warning, the non-overwrite policy and the routing to reader tools, nothing an agent needs in order to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, so the schema already explains id, tipo and the nome_file default. The description adds no parameter-level meaning such as how nome_file interacts with the no-overwrite rule, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: saving the PDF of a provvedimento or abstract to the configured download folder. It also distinguishes itself from the reader siblings by naming leggi_testo_provvedimento and leggi_abstract as the tools for content, so an agent can tell the tools apart without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It states the condition that selects this tool (need the PDF file on disk) and explicitly routes content-reading needs to leggi_testo_provvedimento or leggi_abstract. The alternative is named directly rather than left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the description only needs to add context. It adds that the tool reflects both a session check and any in-progress access, but says nothing about what happens when no session exists, whether it triggers authentication, or how it behaves under the open-world hint (network dependency, failure modes).

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

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

Two short sentences with zero filler; the substantive scope (validity, expiry, in-progress access) comes first and the call-timing guidance follows. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, read-only tool with full annotation coverage and no output schema, the description conveys what information the result holds (validity, expiry, access state) and when to invoke it. The main residual gap is what the agent should do on an invalid session, which is left to the sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry; baseline applies. Nothing is missing or contradicted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resources: it reports whether a valid session with the Banca Dati di Merito exists, when it expires, and the status of any access in progress. That is more than a restatement of the name, and it is distinguishable from search siblings, though it never explicitly names the sibling it differs from (e.g. accedi).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

"Chiamalo prima di una serie di ricerche" gives an explicit precondition and timing for calling it, which is clear actionable context. It stops short of naming the alternative action (calling accedi) when the session turns out to be invalid, so it is not a full when/when-not/alternative statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile is known. The description adds that the result is the sequence of gradi di giudizio as displayed by the Banca Dati, but it does not describe empty results, ordering, or output shape.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the returned resource and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with one fully documented parameter and no output schema, the description is mostly complete: it says what is returned and ties it to a provvedimento. Minor gaps remain around result structure and behavior when no linked degrees exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, and the only parameter 'id' is already documented as the identifier returned by searches. The description does not add further parameter semantics beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns the sequence of litigation levels linked to a provvedimento. This is clearly different from siblings such as leggi_provvedimento or cerca_provvedimenti, but it does not explicitly name an alternative or contrast with one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the phrase 'collegati a un provvedimento': the tool should be used when an agent needs the procedural timeline for a known measure id. However, it gives no explicit when-to-use/when-not-to-use guidance or alternatives such as using leggi_provvedimento for full document content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.