Server Quality Checklist

Tool Scores

• verifica_spesa_detraibileC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose and does not mention what the output looks like, whether it is a safe read operation, or any side effects. The user is left without insight into the tool's behavior beyond the high-level action.

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

  Conciseness4/5

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

  The description is concise and front-loaded, with the main purpose stated in the first sentence. The 'Args' block is slightly verbose but adds an example. There is no irrelevant information, and it is appropriately sized for a one-parameter tool.

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

  Completeness2/5

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

  Although the tool is simple, the description lacks completeness. It does not specify valid values for 'tipo_spesa' or clarify what 'con quali regole' entails (e.g., does it return a text explanation, a boolean, or rules?). The output schema exists but does not compensate for this missing contextual information about the input domain and expected behavior.

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

  Parameters2/5

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

  The schema provides no description for 'tipo_spesa' (0% coverage), so the description must compensate. It offers one example ('es. "spese_sanitarie"') but does not enumerate valid values, format requirements, or a list of possible expense types. This is insufficient for correct invocation without additional knowledge.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Verifica se una spesa è detraibile/deducibile e con quali regole.' This uses a specific verb ('verifica') and resource ('spesa detraibile/deducibile'), and it distinguishes from sibling tools like 'calcola_*' that calculate amounts rather than verify deductibility rules.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or specific scenarios where this tool is preferred (e.g., for checking eligibility vs. calculating amounts), leaving the agent to infer usage context.

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

• calcola_addizionale_regionale_toolB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only describes the tax concept and lists available regions, without stating side effects, error handling, or limitations. There is no indication of what happens with invalid inputs or how results are returned.

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

  Conciseness4/5

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

  The description is well-structured with a clear opening sentence, a brief background paragraph, and organized Args and region lists. The background paragraph adds domain context but could be trimmed; overall, it earns its place.

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

  Completeness3/5

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

  The description covers the main inputs and lists available regions, which is helpful. However, the default year discrepancy and lack of error-handling details leave some ambiguity. Since an output schema exists, return values are not required in the description.

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

  Parameters3/5

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

  The description includes an Args section explaining each parameter's meaning and lists available region values, compensating for the schema's lack of descriptions. However, it incorrectly states the default for anno as 2024 while the schema specifies 2025, creating conflicting guidance.

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

  Purpose5/5

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

  The first sentence clearly states the tool calculates the regional IRPEF surcharge for a specific region, using the verb 'Calcola' and identifying the resource 'addizionale regionale IRPEF'. This distinguishes it from sibling tools like calcola_irpef.

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

  Usage Guidelines3/5

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

  Provides context about the tax being separate from IRPEF and retained by the withholding agent, but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. Usage is implied by the tool's name and sibling set, but no explicit guidance is given.

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

• calcola_detrazioni_familiari_toolA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does disclose important behavior: it excludes under-21 children and explains parameter roles. However, it does not describe the return format or edge-case behavior, and it contains a notable discrepancy: the description states 'Default: 2024' while the schema specifies default 2025, which undermines trust.

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

  Conciseness4/5

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

  The description is well-structured: a clear one-line summary, a prominent warning, and then a detailed Args section with an example. It is a bit long but every part adds value, and the example helps clarify the expected format for familiari.

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

  Completeness3/5

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

  The tool has moderate complexity with nested familiari objects, and the description covers the critical AUU context and parameter formats. However, it lacks details about the calculation logic, invalid input handling, or what the output structure looks like (though an output schema exists). The default year mismatch is also a gap in completeness.

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

  Parameters4/5

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

  The schema provides zero parameter descriptions, so the description's Args section is essential. It thoroughly explains reddito_complessivo, familiari (including sub-fields like tipo, mesi_a_carico, percentuale_carico, eta_inferiore_21), and anno. The value is slightly diminished by the default year mismatch and lack of enforcement of the documented sub-field values in the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('Calcola le detrazioni per carichi di famiglia') and resource scope ('coniuge, figli ≥21, altri'), immediately distinguishing it from sibling tools like calcola_irpef or calcola_detrazione_lavoro. The additional warning about under-21 exclusions further clarifies what it does and does not cover.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool (for family dependents excluding under-21 children) and an explicit when-not-to-use condition (under-21 children, which are handled by AUU). However, it does not explicitly name an alternative tool from the sibling list, so it stops short of a full alternative recommendation.

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

• genera_checklist_730A
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explains the tool's output (which forms, documents, deadlines) but does not explicitly state that it is read-only, deterministic, or has no side effects. The behavior is self-evident as a generator, but lacks explicit notes about limitations or edge cases.

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

  Conciseness4/5

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

  The description is well-structured as a docstring, starting with the primary purpose, followed by a clear 'Args:' section. While it is lengthy, every line adds value by documenting parameters. It is appropriately sized for the tool's complexity, though it could be marginally more concise by grouping similar parameters.

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

  Completeness4/5

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

  Given the tool's complexity (15 parameters) and the presence of an output schema, the description is complete in explaining what the tool does and what input it expects. It does not detail return values, but that is covered by the output schema. It also does not provide examples, but they are not essential for this straightforward checklist generator.

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

  Parameters5/5

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

  The schema has 0% description coverage, but the description extensively documents each parameter with explanatory text (e.g., 'ha_figli_under_21: Ha figli under 21 (coperti da Assegno Unico, non detraibili)'). This fully compensates for the schema's lack of descriptions, providing clear meaning for all 15 boolean inputs and the anno integer.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Genera una checklist personalizzata per la compilazione del 730' (generate a personalized checklist for 730). It further details what the checklist includes (which forms, documents, deadlines), making the purpose specific and distinguishing it from sibling tools like guida_quadro or calcola_* which handle specific aspects.

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

  Usage Guidelines3/5

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

  The description implies usage context ('Basandosi sulla situazione del contribuente') but does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of exclusions or comparisons to sibling tools, so the 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.

• calcola_oneriA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and discloses several behaviors: the €129.11 franchise for health expenses, automatic €260 reduction for high incomes, and an extensive list of accepted expense types. However, it fails to mention output structure and contains a factual discrepancy (default year 2024 vs schema's 2025), which slightly undermines transparency.

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

  Conciseness4/5

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

  The description is well-structured: a clear opening sentence, a behavioral note, an Args section, and an enumerated list of allowed types. It is somewhat long, but every sentence adds needed detail given the tool's complexity. The list of 15 expense types is essential and not bloated.

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

  Completeness4/5

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

  For a complex tax calculation tool, the description covers a wide range of expense types, the main calculation rule, and parameter shapes. The output schema (not shown here) likely explains return values, so that omission is acceptable. However, the default year mismatch and the lack of error-handling details (e.g., invalid 'tipo') are gaps.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate, and it does thoroughly: it explains reddito_complessivo (euros), spese (list of dicts with tipo/importo/note), and anno (default 2024, though schema says 2025). It also provides the list of allowed 'tipo' values, which is absent from the schema. The incorrect default year is the main flaw.

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

  Purpose5/5

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

  The description clearly states it calculates deductions and deductions for Quadro E expenses, listing specific categories and a precise rule for income over €50,000. This distinguishes it from sibling tools like calcola_irpef (IRPF) and calcola_detrazioni_familiari (family deductions), which focus on different tax domains.

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

  Usage Guidelines3/5

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

  The description implies use when calculating deductions for the listed expense types but does not explicitly contrast with alternatives such as verifica_spesa_detraibile or calcola_irpef. It lacks direct 'use this when' or 'use that instead' guidance, though the domain is clear.

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

• calcola_risultato_dichiarazioneA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool combines inputs to determine an outcome, which is useful, but it does not mention side-effect-free behavior, error handling, or any validation logic. The algorithmic summary is present but not deeply transparent about failure modes or limitations.

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

  Conciseness5/5

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

  The description is well-structured: a brief purpose statement followed by a bulleted Args list. It is appropriately sized for a 9-parameter tool, front-loads the key outcome, and every line adds value. No fluff or repetition.

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

  Completeness3/5

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

  The output schema covers return values, and the description explains all parameters well. However, it omits explicit notes on optionality (though schema shows defaults/nullable) and contains the anno default mismatch, which reduces reliability. For a 9-parameter tool, these gaps make it slightly less complete than ideal.

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

  Parameters4/5

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

  The description includes a detailed Args section explaining every parameter, including units, examples, and defaults, which is essential given the schema has zero descriptions. However, there is a discrepancy: the description says anno default 2024, while the schema says 2025, which could mislead agents relying on the text. This prevents a perfect score.

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

  Purpose5/5

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

  The description states the tool calculates the final 730 declaration result (refund or IRPEF debt), combining gross IRPEF, deductions, and withholdings. This is a specific verb+resource that clearly distinguishes it from sibling tools like calcola_irpef or calcola_detrazione_lavoro, which feed into this final aggregation.

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

  Usage Guidelines4/5

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

  The description implies usage context by referencing sibling tools for input parameters ('vedi calcola_detrazioni_familiari', 'vedi calcola_oneri'), indicating this is the final computation after those are obtained. It does not explicitly state when to use vs. alternatives, but the context is clear enough for an agent to infer the appropriate workflow.

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

• lista_documenti_spesaA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly implies a non-mutating retrieval operation and lists accepted values, but it does not specify behavior for invalid input, empty results, or potential side effects. This is adequate but not exhaustive.

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

  Conciseness4/5

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

  The description is front-loaded with the purpose, followed by usage guidance and parameter details. The long list of allowed values is necessary because the schema lacks an enum, and there is no redundant or filler content. It is well-structured and appropriately sized.

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

  Completeness4/5

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

  With only one simple parameter and an output schema available, the description covers purpose, usage, and the complete input domain. It could mention error handling or output shape, but the output schema and the tool's straightforward lookup nature reduce the need for such details.

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

  Parameters5/5

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

  The input schema only defines 'tipo_spesa' as a string with no enum. The description compensates fully: it explains the parameter's meaning, provides an example, and lists all 15 accepted values, giving the agent complete information to construct valid input.

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

  Purpose5/5

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

  The description clearly states the tool 'restituisce la lista dei documenti necessari per una specifica tipologia di spesa', using a specific verb and resource. This distinguishes it from sibling tools like calcola_oneri or verifica_spesa_detraibile, which perform different calculations or checks.

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

  Usage Guidelines4/5

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

  The description explicitly notes the tool is useful 'prima di recarsi al CAF o compilare il 730', giving clear context for when to use it. It does not name alternatives or exclusion criteria, but the intended use case is obvious relative to the sibling tools.

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

• analizza_certificazione_unicaA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses specific behavioral checks (IRPEF plausibility, days range) which go beyond a generic statement. It doesn't explicitly state read-only nature or error handling, but the analysis focus and detailed validation logic provide good transparency.

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

  Conciseness5/5

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

  The description is well-structured: a two-sentence summary followed by a necessary Args list. There is no redundant text, and the Args list is essential given the 0% schema description coverage.

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

  Completeness4/5

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

  The description covers purpose, validation logic, and all parameters comprehensively, and the output schema covers return values. The only gaps are the minor default value discrepancy and no explicit mention of side effects, but overall it is complete for an analysis tool.

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

  Parameters4/5

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

  The description offers extensive parameter explanations with CU point references (e.g., 'reddito_lordo: Reddito lordo (punto 1 CU)'), which the schema completely lacks. However, it incorrectly states the default for 'anno' as 2024, while the schema says 2025, creating a conflicting instruction that undermines the guidance.

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

  Purpose5/5

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

  The description begins with a specific verb 'Analizza' and names the resource 'Certificazione Unica' followed by the action 'rileva eventuali anomalie'. It clearly distinguishes from sibling tools like calcola_irpef or calcola_detrazione by focusing on validation and anomaly detection rather than calculation.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool: when you have CU data and need to verify internal coherence and plausibility. However, it does not explicitly mention alternatives or when not to use it, stopping short of the highest score.

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

• calcola_detrazione_lavoroA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple statement by detailing the 2025 deduction brackets, the gradual bonus percentages, and the decreasing deduction mechanism. It also lists the parameters with ranges and defaults. While it doesn't cover edge cases like invalid inputs or rounding rules, the main calculation logic is transparent enough for a tax calculation tool.

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

  Conciseness4/5

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

  The description is well-structured with a clear first sentence, a bulleted list for 2025 rules, and a clean Args section. Each part serves a purpose, though the Args section repeats defaults already present in the schema (e.g., 'Default: 365'). Given that schema descriptions are absent, this repetition is justified and aids clarity, but it prevents a perfect score for conciseness.

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

  Completeness4/5

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

  The tool has four parameters, an output schema (not shown), and no annotations. The description covers the calculation rules, parameter meanings, and supported years, which is substantial. It lacks explicit details about how giorni_lavoro is applied (pro-rating) or how the calculation differs for 2023/2024, but the output schema likely covers return structure, and the description is sufficiently complete for an agent to invoke the tool correctly.

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

  Parameters5/5

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

  The schema has no field descriptions (0% coverage), so the description's Args section is the only source of parameter meaning. It explains each parameter thoroughly: reddito_complessivo in euro, giorni_lavoro range 1-366 with default, tipo_reddito with explicit allowed values, and anno with supported years. This fully compensates for the missing schema descriptions and adds semantics beyond the basic type/default info.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Calcola la detrazione per lavoro dipendente, pensione o redditi assimilati.' This provides a specific verb and resource, and the mention of 'lavoro dipendente, pensione o redditi assimilati' distinguishes it from sibling tools like calcola_detrazioni_familiari_tool and calcola_irpef. The additional detail about the 2025 cuneo fiscale further sharpens the purpose.

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

  Usage Guidelines4/5

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

  The description implies when to use the tool by specifying the eligible income types and supported tax years (2023-2025). It also highlights the automatic inclusion of the cuneo fiscale for 2025, giving context for expected behavior. However, it does not explicitly state when not to use it or point to alternatives, so it stops 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.

• guida_quadroA
  4.4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It discloses that the 'quadro' parameter is case-insensitive and lists valid values, which is useful behavioral information. However, it does not state whether the tool is read-only, what happens on invalid input, or what the output format is (though an output schema exists). The description implies a safe informational tool but does not explicitly guarantee no side effects.

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

  Conciseness5/5

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

  The description is well-structured and appropriately sized. It opens with a clear purpose sentence, then details what the guide explains in a bullet point, followed by parameter documentation and a list of available quadri. Every sentence adds value, and the format is easy to parse.

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

  Completeness5/5

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

  The tool is simple: one parameter and presumably a textual guide output. The description covers the tool's purpose, parameter meaning, valid inputs, and content scope. Since an output schema exists, the description does not need to explain return values, and it provides sufficient context for an agent to select and use this tool correctly.

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

  Parameters5/5

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

  The schema provides only a parameter name and type with no description. The description compensates fully by explaining that 'quadro' is the letter of the section, providing examples, noting case-insensitivity, and listing all valid values (A, B, C, D, E, F, G, I, K, L, M, T, W). This gives the agent complete information needed to invoke the tool correctly.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Fornisce una guida dettagliata per la compilazione di un quadro del Modello 730' (provides a detailed guide for filling out a section of Form 730). It uses a specific verb ('fornisce') and resource ('quadro del Modello 730'), and the purpose distinguishes it from sibling tools that perform calculations or validations.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: when you need explanatory guidance on what to declare, main fields, notes, and documents for a specific section. It lists the available sections (quadri), which helps the agent select the tool. However, it does not explicitly mention alternatives or when not to use it, such as pointing to sibling tools for calculations.

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

• valida_codice_fiscale_toolA
  4.5/5.0
  Behavior4/5

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

  The description discloses concrete behaviors: validation of format, length, and the 16th check character, plus extraction of sex, birth date, and birth code. It also notes input normalization (case-insensitive, spaces ignored). Missing is behavior for invalid inputs, but the core traits are well covered.

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

  Conciseness5/5

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

  The description is compact and front-loaded. The first sentence states the purpose, followed by concise bullet-like lists of verifications and extracted outputs. Every sentence carries useful information with no redundancy.

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

  Completeness4/5

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

  The description covers the verification steps, extracted fields, and input handling, which is sufficient for a moderately simple tool. The presence of an output schema makes the return representation less critical. Only invalid-input behavior and potential error conditions are missing.

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

  Parameters5/5

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

  Despite 0% schema description coverage, the Args section fully documents the only parameter `codice_fiscale` and adds meaningful semantics: case-insensitive, spaces ignored. This is exactly the kind of compensation needed for a sparse schema.

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

  Purpose5/5

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

  The description opens with a specific action and resource: 'Valida un codice fiscale italiano e ne estrae i dati anagrafici codificati.' This clearly distinguishes it from the sibling tax-calculation tools by focusing on validation and data extraction rather than computation.

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

  Usage Guidelines4/5

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

  The intended use is implicit but clear: use when a codice fiscale needs validation or when demographic data must be extracted from it. It does not explicitly name alternatives or exclusions, but the sibling tools are sufficiently distinct that no ambiguity arises.

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

• calcola_irpefA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses the use of official brackets, the reference to the 2024-2025 IRPEF reform, and that the output is total tax with per-bracket detail. It does not fully detail 2023 bracket behavior, but it is a pure calculation tool with no side effects, so this is acceptable.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the main purpose, and uses a clear Args list for parameters. Every sentence contributes meaningful information without redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity (two params, no nested objects), an output schema exists, and the description covers inputs, supported years, calculation basis, and output form. The description is complete enough for reliable invocation.

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

  Parameters5/5

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

  The input schema provides only titles, while the description adds crucial semantics: unit (euro), minimum value (>=0), supported tax years (2023-2025), and default year. This greatly helps an agent supply correct arguments.

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

  Purpose5/5

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

  The description uses a specific verb-plus-resource ('Calcola l'IRPEF lorda') and clearly distinguishes this tool from siblings like detrazione or addizionale calculators. It unambiguously states what it computes and for which tax years.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: for a given comprehensive income and tax year. It does not explicitly name alternative tools or state when not to use it, but the scope is well defined by the resource and supported years.

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