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

The annotations already declare readOnlyHint=true, and the description's 'Cerca' (search) is consistent. However, the description adds no behavioral context beyond what the annotation and tool name imply, such as result limits, default sorting, pagination, or any search idiosyncrasies.

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, direct Italian sentence with no redundancy. It front-loads the verb and target, making it immediately clear what the tool does.

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 tool with 21 optional parameters, no output schema, and no parameter descriptions, a one-line description is insufficient. It fails to mention how filters interact, default behavior, or what the response contains, leaving significant gaps for an agent to navigate.

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?

With 21 parameters and 0% schema description coverage, the description does nothing to explain the meaning or usage of parameters like tipo_ricerca, sort_field, or max_results. It only identifies the general search target, leaving agents to infer parameter semantics from names alone.

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 ('Cerca' / 'search') and a clear resource ('abstract/massime redazionali' / editorial abstracts/headnotes) in the context of the Merit Database of the Ministry of Justice. This clearly distinguishes the tool from sibling search tools such as cerca_provvedimenti, which targets rulings rather than abstracts.

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 provides no guidance on when to use this tool versus alternatives like cerca_provvedimenti or leggi_abstract. There are no usage scenarios, exclusions, or mentions of how this search differs from searching full court decisions.

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 readOnlyHint annotation already declares this as a safe read operation. The description adds no behavioral traits beyond that, such as scoping constraints (e.g., date ranges, filtering), pagination behavior, or authentication requirements. It merely repeats the resource scope.

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 sentence that immediately states the action and resource without redundancy. It is front-loaded and contains no filler, making it maximally concise for its limited 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?

Given the high complexity (19 parameters) and absence of an output schema, the description is far too thin. It does not explain search behavior, result shape, default sorting, or how to combine filters. A tool of this complexity requires much more contextual guidance than one line.

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?

With 19 parameters and 0% schema description coverage, the description carries the full burden of explaining parameters. It only hints at the 'tipo' parameter by listing 'sentenze, decreti, ordinanze', but does not explain the meanings of 'query', 'data_da', 'sort_field', or other fields. This is inadequate for correct invocation.

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 clearly identifies the tool as a search operation for provvedimenti (sentenze, decreti, ordinanze) within a specific database (Banca Dati del Merito del Ministero della Giustizia). The verb 'Cerca' plus the resource and subtypes distinguishes it from sibling search tools like 'cerca_abstract'.

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 for finding judicial decisions but provides no explicit guidance on when to use this tool versus alternatives such as 'cerca_abstract' or 'naviga_archivio'. No exclusions or contextual cues are 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 the tool as read-only and idempotent, and the description aligns by saying 'Legge' (reads). The description adds that it reads the full text of an abstract including precedents, which is useful content-wise, but it does not disclose additional behavioral traits such as return format, authentication, or error handling. Since annotations already cover the safety profile, the added value is moderate.

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, concise sentence that front-loads the verb and clearly states the resource and its special features. No filler or redundant information is present.

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-parameter read-only tool with no output schema, the description adequately conveys that the tool retrieves the full text of an abstract, including precedents, which effectively describes the return value. It lacks explicit details about output format or error behavior, but these are not critical for a simple retrieval task. The context is complete enough for an agent to understand the tool's role.

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 schema has 100% description coverage for the single 'url' parameter, clearly stating it is the detail page URL from specific search tools. The tool description adds no additional parameter explanation. With high schema coverage, the baseline of 3 is appropriate.

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 'Legge' (reads) and a clear resource: the full text of a BDP abstract, further specifying that it includes conforming and non-conforming precedents. This distinguishes it from sibling tools like leggi_dettaglio_provvedimento and leggi_testo_provvedimento, which target different resources.

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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. However, the input schema for the 'url' parameter indicates that the URL comes from cerca_provvedimenti or cerca_abstract, which implies a search-and-read workflow. This gives a clear context but no explicit comparison to other tools.

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 idempotentHint, and the description's 'Legge' aligns with these. The description adds that three data types are retrieved (metadata, timeline, abstracts), but does not disclose potential behaviors like pagination, error conditions, or rate limits. With annotations covering safety, this is acceptable 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.

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

The description is a single, front-loaded sentence that lists the key output components without repetition or fluff. It is concise and immediately comprehensible to a domain-aware agent.

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 one parameter and no output schema, the description adequately outlines the expected data (metadata, timeline, abstracts). It does not detail the exact return structure, but for a simple read tool this provides sufficient context for the agent to understand the tool's role.

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 parameter description already explains that the URL must come from search tools. The tool description adds no extra meaning about the parameter, but the baseline for high schema coverage is met.

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 clearly states the tool reads ('Legge') complete metadata, judgment timeline, and linked abstracts for a BDP provision. This specific verb+resource scope differentiates it from siblings like leggi_abstract and ottieni_timeline, which focus on individual components.

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 use when a comprehensive detail view is needed, but does not explicitly state when to use this tool versus alternatives. The parameter schema adds context that the URL comes from cerca_provvedimenti or cerca_abstract, but the main description lacks direct usage guidance.

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 idempotentHint, so the safety profile is clear. The description adds valuable behavioral details beyond those annotations: it reveals that the tool navigates to the detail page, clicks 'Mostra', and that the full text is located in the DOM under '.visually-hidden' inside '#document-modal'. This gives concrete expectations of tool 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 two sentences long and front-loaded with the primary purpose. The first sentence states exactly what the tool does, and the second provides a precise implementation detail. Every sentence earns its place without unnecessary fluff.

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 the simple nature of the tool (one parameter, no output schema), the description is quite complete: it explains what is extracted, where it comes from, and where the data resides in the DOM. It stops short of explicitly describing the return format or how the agent should consume the extracted text, but for a one-parameter read-only extraction tool 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?

Schema description coverage is 100%, with the single 'url' parameter clearly described as the detail page URL from 'cerca_provvedimenti' or 'cerca_abstract'. The description does not add any extra parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly states the tool extracts the full anonymized text of a provision ('Estrae il testo integrale anonimizzato di un provvedimento'), using a specific verb and resource. It distinguishes itself from siblings like 'leggi_abstract' and 'leggi_dettaglio_provvedimento' by emphasizing complete text extraction via the detail page.

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 provides procedural guidance ('aprendolo dalla pagina dettaglio e cliccando "Mostra"') and implies the tool is used when full text is needed, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or other tool recommendations.

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 indicate readOnlyHint=true, so the read-only nature is covered. The description adds the hierarchy path but does not disclose important behaviors like handling of partial parameters, default values, or response format. It provides modest additional context beyond 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?

The description is a single, efficient sentence with no redundancy. It is front-loaded and to the point, though it may be slightly under-specified given the tool's complexity; still, every word 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 tool with 7 optional parameters and no output schema, the description is not complete enough to enable correct invocation. It omits details about required parameter combinations (if any), the role of target, the expected output, and how the navigation results are structured.

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?

With 0% schema description coverage, the description partially compensates by naming the hierarchy levels, which map to distretto, ufficio, materia, anno, and mese. However, it does not explain the target or max_results parameters, nor does it clarify how parameters combine, leaving gaps.

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 clearly states the tool's action ('Naviga la struttura gerarchica') and specific resource (the BDP archive hierarchy with levels Distretto → Ufficio → Materia → Anno → Mese). This is distinct from sibling tools like search and read, making it easy to understand what this tool does.

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 for browsing the archive hierarchy, but does not explicitly state when to use it over alternatives such as cerca_provvedimenti or leggi_dettaglio_provvedimento. No exclusions or alternative references are provided.

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 idempotentHint, so the agent knows it's a safe read operation. The description adds valuable context by stating the data is 'live, non hardcoded', which informs the agent that results are dynamically fetched and not a static list. This goes beyond 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?

The description is a single, concise sentence that immediately states the tool's action and resource. Every word earns its place; it is front-loaded with the purpose and includes the key behavioral note about live data.

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, zero-parameter tool with an output schema and safety annotations, the description is sufficient. It clearly communicates what the tool does, the source of the data, and the live nature, leaving no critical 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?

The input schema is empty with zero parameters, so the baseline is 4. The description naturally does not add parameter details since there are none, and it correctly implies no inputs are required.

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 clearly states the verb 'estrae' (extracts) and the resource 'distretti giudiziari' (judicial districts), and further specifies the source as the BDP search select. This distinctively identifies the tool's purpose and differentiates it from sibling tools like ottieni_materie.

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 provides context (it's for the BDP search select) and notes that data is live rather than hardcoded, implying it is the appropriate tool for fetching current district options. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions.

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 and idempotentHint, indicating a safe, non-mutating operation. The description adds useful behavioral context: 'live, non hardcoded' means the data is dynamically extracted from the actual select, not from a static list. This gives the agent insight into the data source and freshness beyond 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?

The description is a single, front-loaded sentence that clearly states the action and resource: 'Estrae le materie disponibili dal select della ricerca BDP'. There is no filler or redundant information. It is appropriately sized for the tool's simplicity.

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?

The tool has no parameters, read-only/idempotent annotations, and an output schema exists, so return values are covered. The description explains the core function and adds the 'live' qualifier. For a simple retrieval tool, this is sufficiently complete, though it does not describe exact usage context relative to the search process.

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?

This tool has zero parameters, so the input schema is fully covered by default. The description correctly does not need to explain parameter semantics. Per the baseline for 0 params, a score of 4 is appropriate.

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 the specific verb 'Estrae' (extracts) with a clear resource: 'le materie disponibili dal select della ricerca BDP' (available subjects from the BDP search select). It distinguishes itself from siblings like 'ottieni_distretti' by indicating it returns subject data. The additional 'live, non hardcoded' further clarifies the data source.

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 for retrieving the subjects available in the BDP search form, but does not explicitly state when to use this tool versus alternatives like 'ottieni_distretti' or 'ottieni_timeline'. No exclusions or conditions are mentioned. The context is clear, but there is no explicit guidance on alternatives.

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 idempotentHint, so the safety profile is clear. The description adds that the tool works on the detail page and supports conformi/difformi types, but does not disclose further behavior such as output format, pagination, or error conditions. 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.

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

The description is a single, front-loaded sentence that states the action, object, and source without any filler. Every word adds value.

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 extraction tool with clear annotations and only two parameters, the description is largely complete. It could optionally mention the return structure or prerequisites, but the detail-page source and type selection are communicated. No output schema exists, yet the description's simplicity suffices.

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 50%: url has a description, tipo has an enum but no text description. The description and title clarify the meaning of tipo via 'conformi e/o difformi', which partially compensates. However, the description does not explicitly map parameters to their roles, so it stays at baseline.

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 'Estrae' (extracts) with a clear resource 'lista di precedenti' and scopes the operation to 'pagina dettaglio di un abstract BDP'. This clearly distinguishes it from sibling tools like leggi_abstract or ottieni_timeline, none of which mention precedents.

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 when to use the tool (when needing precedents from an abstract detail page) but does not explicitly state alternatives or exclusion criteria. It lacks a 'when not to use' or reference to sibling tools, so usage guidance is only implicit.

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 (readOnlyHint=true, idempotentHint=true) already cover safety and idempotency. The description adds context about operating on a page detail but does not disclose additional behavior such as error handling or authentication needs.

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 that directly states the purpose with no unnecessary words or duplication.

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 tool with one parameter, read-only/it idempotent annotations, and no output schema, the description provides the essential purpose and input context. The output concept ('catena dei gradi di giudizio') is implied but not detailed in structure, which is acceptable for this simplicity.

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 input schema has only 'url' with format uri and 0% description coverage. The description compensates by specifying that the URL should point to the detail page of a BDP provision, adding meaningful semantic context to the parameter.

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 clearly states the specific action (Estrae/extracts) and resource (catena dei gradi di giudizio/chain of judgment degrees) from a provision detail page. It distinguishes itself from siblings like leggi_dettaglio_provvedimento (full detail) and cerca_provvedimenti (search).

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 by explaining what the tool does but does not explicitly state when to use it over alternatives or provide exclusions. There is no direct comparison to sibling tools.

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 provide readOnlyHint=true, and idempotentHint=false. The description adds that the verification is performed 'navigando la BDP,' which clarifies the operation is a navigation (likely a read). It does not contradict the annotations. However, it does not provide additional context about side effects, authentication, or what 'BDP' entails, so it adds minimal value beyond 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?

The description is a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant information, and it fully fits in one line. Every word adds value.

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 the tool's simplicity (no parameters, output schema exists), the description is sufficiently complete. It conveys what the tool does and how. It does not explain acronyms like BDP or what happens on session expiry, but with an output schema provided and annotations covering safety, these are minor omissions. It is adequate for the tool's scope.

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 the baseline is 4. There are no parameters to describe, and the description does not need to compensate for schema gaps. The mention of 'navigando la BDP' is a behavioral action, not a parameter, so the score aligns with the zero-param baseline.

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 clearly states the tool's purpose: to verify if the CIE session is still active. It uses a specific verb ('verifica') and resource ('sessione CIE'), and the method ('navigando la BDP') adds distinctiveness. None of the sibling tools perform a session check, so it is well differentiated.

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: when you need to confirm an active CIE session by navigating the BDP. It does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The guidance is limited to the implication that this is a session verification step.

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