Delegum

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

Annotations mark readOnlyHint: true, and the description confirms it is a calculation/comparison tool with no side effects. It adds context about comparing options and recommending, but no hidden behaviors are mentioned.

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 very concise, front-loading the purpose in two sentences. Every sentence adds value, with no unnecessary words.

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 description explains what the tool does and what it compares, but does not describe the output format. Given that there is no output schema, this is a minor gap, but overall the tool functionality is well communicated.

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% with descriptions for all parameters. The description does not add extra meaning beyond what is in the schema, such as the relationship between 'reducir cuota' and 'reducir plazo' options.

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 it calculates the effect of early mortgage amortization under the French system, compares two bank options (reducing monthly payment or term), and recommends the best one. It is specific and distinct from sibling tools which cover different financial calculations.

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 it (for early mortgage amortization analysis) but does not explicitly state when not to use it or mention alternative tools. However, the sibling list shows many distinct tools, so context 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?

The description discloses that the tool calculates and returns results without side effects. The annotations include readOnlyHint=true, and the description aligns with this by describing a read-only computation. No destructive or mutating behavior is implied or mentioned.

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 purpose and includes all necessary information: calculation rules, input types, and output summary. No extraneous text.

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 lack of an output schema, the description compensates by stating what the tool returns (daily, monthly, total subsidy, and loss compared to usual salary). The parameters are well-covered by the schema and description. The tool's complexity is moderate but the description is sufficient for an AI agent to use 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?

The schema covers all parameters with descriptions. The description adds value by explaining the calculation algorithm (e.g., percentages for different days and contingencies), which helps users understand how parameters like 'tipo_baja' and 'dias_baja' affect the result. This goes beyond the schema's minimal descriptions.

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: calculating the subsidy for temporary disability (baja médica) for an employee. It specifies the two types of contingencies (common and work accident) with their respective calculation rules. The description distinguishes this tool from siblings, which are other financial calculations.

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 clear context for when to use the tool (calculating medical leave subsidy) but does not explicitly specify when not to use it or name alternatives among siblings. However, the purpose is clear enough for an AI agent to select it appropriately.

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 description adds context about the tool's outputs but does not disclose behavioral traits beyond what annotations already provide (readOnlyHint=true). It's consistent with annotations but doesn't add significant behavioral details.

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 is informative, front-loaded, and contains no redundant information. 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?

Given the tool has 5 parameters and no output schema, the description provides a clear high-level summary of the outputs. It could mention default values (like edad_jubilacion=67) or return format for completeness, but it is adequate.

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 description does not add extra meaning to parameters; it only summarizes the tool's purpose. The description does not elaborate on individual parameters beyond what the schema already describes.

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 calculates retirement gap, loss of income, necessary capital, and monthly savings. It uses specific verbs and resources, and is distinct from sibling tools about other financial calculations.

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 users wanting to understand their retirement income gap, but it does not provide explicit when-to-use or when-not-to-use guidance or mention alternative tools like calcular_jubilacion_anticipada or calcular_pension_publica.

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 description adds behavioral context beyond the readOnlyHint annotation by explaining the methodology (Bank of Spain rule) and what the tool returns (max capital, max price, etc.). No contradictions with 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 two sentences: the first states the purpose and rule, the second lists returns and sibling guidance. It is concise and front-loaded with essential 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?

Given the complexity (6 params, no output schema), the description covers purpose, methodology, return values, and sibling tool guidance. It is complete and sufficient for correct tool selection.

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 100% schema description coverage, baseline is 3. The description adds value by explaining the rule and defaults (e.g., plazo=30, tasa_interes=3.5%), reinforcing the parameter meaning in context.

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 it estimates the maximum mortgage capacity using the Bank of Spain rule. It distinguishes itself from sibling tools by specifying that 'calcular_hipoteca' is for monthly detail and 'consulta_compra_vivienda' for full purchase with taxes.

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 explicitly tells when to use this tool (to estimate max mortgage capacity) and when to use alternatives (for monthly payments or full purchase). This provides clear context and 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?

Annotations declare readOnlyHint=true, and the description confirms it is a calculation tool (not destructive). It adds context about legal changes and the fixed amount, which is informative. No contradictions with 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 paragraph that is information-dense but well-structured: purpose and amount, legal update, then requirements. It is concise for the amount of information conveyed, though it could be broken into shorter sentences or bullet points for easier scanning.

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 100% schema coverage and no output schema, the description covers the tool's purpose, eligibility, legal background, and parameters comprehensively. It lacks explicit mention of the output format, but the context is largely 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.

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

Schema description coverage is 100%, so parameters are already documented. The description adds value by explaining the legal context and default assumptions (e.g., 'por defecto no_percibe'), but does not significantly deepen understanding of each parameter 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?

The description clearly states the tool calculates a pension complement for gender gap reduction, specifies the amount per child (36.90 €/month in 2026) and the pension types involved. It is distinct from sibling tools like calcular_pension_viudedad or calcular_jubilacion_anticipada, making its purpose unambiguous.

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 lists requirements: contributory pension, event from 04/02/2021, at least one child, and non-receipt by the other parent. It also notes the legal ruling removing additional conditions for men. While it does not explicitly contrast with alternatives, the context is clear enough for an AI agent to determine when to use this tool.

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 include 'readOnlyHint': true, indicating no side effects. The description adds specific behavioral context: the calculation uses the real income system for the 2025/2026 period and includes the flat rate for new workers. This aligns with the annotation and provides useful detail.

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-structured sentence that efficiently conveys the purpose, scope, and special case without any redundant information. It is front-loaded with the action verb.

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 (two parameters, no output schema), the description adequately covers the calculation context. It does not explicitly describe the return value (presumably a fee amount in euros), but this can be inferred from the purpose statement.

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 100% description coverage, with both parameters well-documented (rendimiento_neto_mensual and es_nuevo_autonomo). The tool description does not add additional meaning beyond the schema, so a 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 verb 'Calcula' and resource 'cuota mensual de la Seguridad Social de un autónomo (RETA)', specifying the calculation system ('rendimientos reales (2025/2026)') and a special case ('tarifa plana de nuevos autónomos'). This distinguishes it from sibling tools like 'calcular_gastos_deducibles_autonomo' or 'calcular_sueldo_neto'.

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 clear context on when to use the tool: for calculating the monthly social security fee for a self-employed worker under the real income system. It does not explicitly state when not to use it, but the context is sufficient for an agent to infer appropriate scenarios.

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 declare readOnlyHint=true, which is consistent with a calculation tool. The description mentions rates and coefficients but does not elaborate on behavioral aspects beyond what annotations imply. No contradiction is present.

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 consists of two sentences: the first states the purpose, the second provides crucial usage guidance. It is front-loaded and concise, though the second sentence is long. Every sentence adds value 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?

The tool has no output schema, and the description does not describe the return format or expected output values (e.g., tax amount, breakdown). Given the complexity of multiple rates and coefficients, some output context would be helpful but is not critical. The warning about tool usage compensates partially.

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 each parameter already has a description. The tool description adds no additional parameter-level detail beyond referencing 'tarifa estatal o catalana' which maps to the ccaa enum. With full schema coverage, baseline 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 starts with 'Calcula el Impuesto de Donaciones (ISD) en España' specifying the verb and resource clearly. It further details the scope (state/Catalan rates, coefficients, bonuses) and distinguishes itself from sibling tools like 'calcular_sucesiones' by focusing on lifetime donations.

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 explicitly states a critical usage constraint: when comparing donation vs inheritance for real estate, users should NOT use this tool standalone but instead use 'comparar_donacion_vs_herencia'. This provides clear when-to-use and when-not-to-use guidance with an alternative tool.

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 provide readOnlyHint=true, which is consistent with a calculation tool. The description adds behavioral details for each leave type (e.g., voluntary: 4 months–5 years, no reservation or contributions; childcare: max 3 years, first year with reservation). It does not describe side effects or permissions, but as a read-only calculator, no further disclosure is needed.

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, information-dense sentence that front-loads the purpose. It is concise and covers all key aspects, though it could be split into multiple sentences for improved readability.

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 complexity of the tool (5 parameters, 4 leave types, no output schema), the description covers types, constraints, and outputs. It omits details about the optional 'edad' parameter, but the schema covers it. The output format is implied but not explicitly stated.

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% with basic descriptions. The description goes beyond the schema by explaining the rules and implications of each leave type (e.g., duration limits, social security contributions). This adds meaningful context for parameter selection, especially for the 'tipo' enum.

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 calculates rights and cost of work leave (excedencia), lists four specific types with their constraints, and specifies three outputs (reserva de puesto, meses SS, coste). This distinguishes it from other calculation tools like calcular_finiquito or calcular_baja_medica.

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 implicitly indicates when to use this tool (for excedencia calculations), but it does not explicitly state when not to use it or mention alternatives. Given the sibling tools are distinct, the context is clear but lacks exclusion 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=true, indicating no mutation. The description adds behavioral context by specifying the exact components calculated and explicitly excluding severance indemnification, which is beyond the structured 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?

Two concise sentences: first states the tool's purpose, second clarifies an important exclusion. No wasted words, and the key information is front-loaded.

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 description covers the tool's purpose and scope clearly. With no output schema, it would benefit from mentioning the return format, but it sufficiently explains what the tool computes. The optional parameter is described in the schema.

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% with clear descriptions for all parameters. The description provides high-level context but does not add per-parameter details beyond what the schema already provides. 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 'Calcula' and clearly lists the components (vacaciones no disfrutadas, parte proporcional de pagas extras, salarios pendientes). It also explicitly distinguishes from the sibling tool 'calcular_indemnizacion_despido' by stating what is not included.

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 explicitly states when not to use this tool ('No incluye la indemnización por despido') and names the alternative tool. However, it does not provide additional context on when to use it beyond the exclusion.

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 mark readOnlyHint=true, and description adds FIFO method, loss compensation rules, and tax rates. No contradiction. Provides behavioral insight beyond 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?

Description is two sentences, but the first is long (46 words). Still efficient for the complexity, but could be broken down. No wasted words.

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?

No output schema, but description explains what is calculated (gain/loss, tax, compensation). Covers key behaviors for 7 params and multiple operation types, though output format is not detailed.

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 covers all 7 parameters with descriptions (100% coverage). Description adds context like FIFO but does not significantly enhance meaning beyond schema; baseline 3.

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 calculates gain/loss for crypto operations (sale, swap, payment, donation) and its taxation under IRPF with FIFO method. It distinguishes from siblings, which are all different financial calculations.

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 specifies when to use (for various crypto operations) and implies it's for IRPF tax base. However, it lacks explicit when-not-to-use or alternatives, though sibling tools are distinct.

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 provide readOnlyHint=true. The description adds significant behavioral context beyond that, detailing special deduction rules (supplies from home: %afectacion×30%, vehicle: 50% mixed/100% exclusive, medical insurance limit 500€, amortizations, and 5% global provision in simplified estimation). This informs the agent about internal logic and constraints.

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 front-loads the main purpose and then lists special rules. It is concise but dense, packing multiple rules into one sentence. It earns its place without verbosity.

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 14 parameters and no output schema, the description explains the calculation logic and special rules but omits the return format (e.g., whether output is a single total or a breakdown). For a calculator with no output schema, more detail on what the tool returns would improve completeness.

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 each parameter is described in the schema. The description adds extra semantic value by explaining context like 'vehiculo_uso_exclusivo defaults to false (50% deduction)' and 'saldo_deudores_fin_anio only applicable in ED simplificada'. This goes beyond the schema but doesn't fully detail every 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 tool calculates deductible expenses for self-employed under direct estimation (normal or simplified). It specifies the verb 'Calcula' and resource 'gastos fiscalmente deducibles', distinguishing it from sibling tools like calcular_irpf or calcular_iva which handle different calculations.

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 calculating deductible expenses but provides no explicit guidance on when to use this tool versus alternatives like calcular_modelo_130 (quarterly tax) or calcular_irpf (final tax). No when-not-to-use or alternative tool references.

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, and the description confirms no mutations. It adds value by specifying the calculation method (French system) and supported types, but does not elaborate on potential edge cases or behavior for mixed-rate mortgages. With annotations covering safety, a 3 is adequate.

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 consists of two short, front-loaded sentences, efficiently conveying purpose, outputs, and usage guidance without waste. 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?

Given the lack of output schema, the description covers key outputs (monthly payment, total interest, ratio). With 8 parameters fully described in schema and no nested objects, the tool appears complete. Minor gap: no explanation of 'mixed' rate handling, but overall sufficient.

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 all parameters are already well-documented. The tool description only summarizes supported types and outputs, adding minimal new information beyond the schema. Therefore, a baseline 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 calculates a Spanish mortgage (French system) and lists outputs: monthly payment, total interest, debt-to-income ratio. It also specifies supported interest types (fixed, variable, mixed), distinguishing it from sibling tools like 'calcular_capacidad_hipoteca' and 'consulta_compra_vivienda'.

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 explicitly advises when not to use this tool, directing to 'consulta_compra_vivienda' for a complete purchase consultation with taxes and expenses. This provides clear context for appropriate use versus 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?

The description discloses all key behavioral traits: it applies exemptions, uses scales, deducts debts, and excludes pension plans. Annotations already indicate readOnlyHint=true, consistent with the read-only nature. No contradictions.

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 longer but efficiently packed with necessary details. It is front-loaded with the main purpose and then provides specific rules. Some redundancy could be trimmed, but it remains clear and structured.

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 complex tax calculator with 8 parameters, no output schema, but with annotations, the description covers all relevant aspects: exemptions, scales, thresholds, excluded assets, and territorial limitations. It is complete for agent understanding.

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 baseline is 3. The description adds value by explaining interactions (e.g., vivienda_habitual exempt up to 300k, deudas deductible except for exempt assets) and clarifying exclusions (pension plans not included). This exceeds schema descriptions 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 clearly states that the tool values wealth (patrimonio), determines filing obligation, and estimates tax liability using specific scales and exemptions. It explicitly distinguishes from other tools by listing its scope and exclusions (e.g., no business participations, no foral territories).

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 explicit guidance on when to use (individuals, no business participations, not for Navarra/Pais Vasco) and when not to use (foral territories, participations). It also specifies which communities have own scales and which use state scales.

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 declare readOnlyHint=true, which is consistent with a calculation tool. The description adds detail about the specific calculation rules (type-dependent days/year, caps, dual pre-2012 period), which enriches agent understanding beyond the annotation. Could mention default handling of optional parameters.

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 concise sentences that front-load the key purpose and immediately provide alternative tool guidance. Every word earns its place, with no redundancy or 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 no output schema, the description covers the tool's behavior well—types, caps, dual calculation—but doesn't describe return format. However, for a focused calculator with good annotations and sibling differentiation, it is sufficiently complete.

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 baseline is 3. The description adds minimal extra meaning (e.g., 'indemnización dual' for antiguedad_pre_2012) but mostly reiterates what the schema already conveys. No significant value added beyond the structured field descriptions.

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 it calculates severance pay based on dismissal type, with specific formulas (33 days/year for unjust, 20 days/year for objective/ERE) and includes pre-2012 dual calculation. It explicitly distinguishes from sibling 'consulta_despido' which provides full analysis.

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?

Provides explicit guidance: use this tool for severance-only calculation, and for full analysis including final settlement and unemployment, use 'consulta_despido'. This leaves no ambiguity about when to choose this tool over 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 mark readOnlyHint=true, and the description confirms it is a simulation, adding behavioral details like support for monthly contributions and compounding frequencies. No contradictions; description provides useful context beyond 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 two sentences, concise and front-loaded with purpose and outputs, followed by key features. No extraneous 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?

Describes inputs and outputs adequately, but lacks explicit output structure (e.g., return fields) which would be helpful given no output schema. Sufficient for basic understanding but not fully comprehensive.

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 parameters are well-documented. The description offers a high-level overview but does not add new semantic details beyond what the schema provides.

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 simulates compound interest growth for savings/investments, specifying outputs like final capital, generated interest, and total profitability. It distinguishes itself from sibling financial calculators by focusing on compound interest with periodic contributions and capitalization frequencies.

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 compound interest simulation, but does not explicitly state when to use or avoid it. No alternatives or exclusions are mentioned; context from sibling tools suggests it is the only compound interest calculator.

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, so the description adds value by specifying the outputs (cuota íntegra, cuota diferencial, tipo efectivo) and the type of inputs. No contradiction with 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?

Two concise sentences that front-load the purpose and key inputs/outputs. No redundant 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 7 parameters and no output schema, the description mentions the return values (cuota íntegra, cuota diferencial, tipo efectivo) and covers the main computational aspects, providing sufficient context for a tax calculation tool.

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 each parameter has a description. The description adds no additional per-parameter meaning beyond what the schema provides, so baseline 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 calculates IRPF (income tax) from specific income sources (work, capital, capital gains) and applies deductions, which is a specific verb-resource pair. It distinguishes itself from siblings like calcular_plusvalias_irpf or calcular_iva by focusing on comprehensive IRPF calculation.

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 IRPF calculation but does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention when not to use it or any 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, so the description adds value by specifying the two modes (añadir/quitar) and the exact VAT rates. It does not contradict annotations and provides enough behavioral context for safe invocation.

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 concise sentences, front-loaded with the core functionality, no redundant information. Every word serves a purpose.

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 calculation tool with 3 parameters and no output schema, the description fully covers what the tool does, the rates it supports, and the two modes. Annotations provide readOnlyHint, making the context complete.

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 description reinforces the meaning of the 'modo' parameter ('añadir' vs 'quitar'). However, it adds no new information beyond what the schema's description fields already provide. 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?

Description clearly states the verb 'Calcula' and resource 'IVA español', specifying the VAT rates (21%, 10%, 4%, 0%) and the two operations (añadir o extraer). This distinguishes it from sibling tools like calcular_irpf or calcular_hipoteca.

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?

Description implies usage when needing to add VAT to a base amount or extract the base from a VAT-inclusive price. While no explicit when-not or alternatives are given, the sibling tools are all distinct calculations (e.g., IRPF, mortgage), making the context 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 declare readOnlyHint=true, and the description adds behavioral context: it checks feasibility, applies quarterly coefficients, and returns reduced pension and loss. No contradiction; description enhances 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?

Two sentences with essential information, no fluff. The first sentence is relatively long (58 words) but clearly lists actions and conditions. Could be slightly restructured for easier scanning.

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 complexity (4 parameters, no output schema), the description covers eligibility, parameter roles, required prerequisite, and calculation method. References a sibling tool for the prerequisite input, making it self-contained and actionable.

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 schema documents parameters. The description adds value by linking parameters to the eligibility logic (anos_cotizados, tipo, meses_anticipacion) and emphasizing the need for pension_ordinaria as input. However, it does not detail precise units or constraints beyond 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?

The description uses a specific verb ('Calcula') and resource ('impacto de jubilarse antes de la edad ordinaria'), clearly distinguishing it from sibling tools like calcular_pension_publica and consulta_jubilacion by specifying the early retirement context.

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 states eligibility conditions for both voluntary and involuntary early retirement, including years contributed and maximum anticipation. Also directs the user to obtain the ordinary pension via 'consulta_jubilacion', providing clear guidance on when and how to use the tool.

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?

La descripción detalla el comportamiento: fórmula (20% del rendimiento neto acumulado menos retenciones y pagos anteriores), condición de exención y carácter de solo cálculo. El anotación readOnlyHint=true es coherente. La descripción añade contexto significativo más allá de la anotación.

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?

La descripción es concisa: cuatro oraciones que van al grano. Comienza con el propósito, luego la fórmula, luego la condición de exención y finalmente la alternativa. Sin palabras superfluas, cada oración aporta información esencial.

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?

Para una herramienta de cálculo sin esquema de salida, la descripción proporciona la fórmula y condiciones clave. Sin embargo, no menciona el formato de salida (p.ej., el importe a pagar o 0 si no obligación). Los valores por defecto están en el esquema, pero la descripción podría ser más explícita sobre el resultado.

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?

El esquema cubre el 100% de los parámetros con descripciones. La descripción general explica cómo se usan los parámetros en la fórmula (ingresos, gastos, retenciones, pagos anteriores), añadiendo coherencia semántica sin redundancia. No profundiza en cada parámetro individualmente, pero el contexto global es valioso.

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?

La descripción identifica claramente la herramienta como el cálculo del pago fraccionado trimestral del IRPF para autónomos en estimación directa (Modelo 130). Proporciona la fórmula y una condición de exención. Se diferencia de la herramienta hermana 'consulta_autonomo' mencionando cuándo usar esta en su lugar.

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?

Se indica explícitamente una alternativa ('consulta_autonomo') y se menciona una condición de no obligación (más del 70% de ingresos con retención). Aunque no se detallan otros criterios de cuándo no usar esta herramienta, la información proporcionada es suficiente para que un agente decida su uso.

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, making it clear this is a read-only calculation. The description adds behavioral context by detailing the calculation formula and the possible results (positive: to pay; negative: compensate or refund in Q4), which is beyond what annotations provide.

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 three sentences, front-loading the purpose, followed by the formula and outcome details. Every sentence adds value with 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?

Without an output schema, the description adequately covers the calculation result and its interpretation (positive/negative). It also mentions the accepted tax bases. However, it lacks explicit details on how the result is returned (e.g., as a number or object), but the purpose remains clear.

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% with detailed descriptions for each parameter (e.g., base_emitidas_4: 'Base imponible de facturas emitidas al 4% (€)'). The description only mentions the categories (21/10/4%) and compensation without adding new meaning, so it meets the baseline of 3.

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 calculates the quarterly VAT self-assessment (Model 303) with a specific formula (output VAT minus deductible input VAT). It explicitly mentions the tax form and distinguishes it from sibling tools like calcular_irpf or calcular_iva by being specific to Model 303.

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 (quarterly VAT settlement for self-employed and companies) and explains the outcome (to pay, compensate, or refund). However, it does not explicitly state when not to use or name alternative tools, leaving some ambiguity among the many sibling calculators.

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 provide readOnlyHint=true, and the description adds specific calculation details (70%/60% rates, IPREM caps, children) beyond what annotations offer. No contradictions.

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?

Single comprehensive sentence with all essential information, no wasted words.

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?

Lacks explicit output schema or description of return format; although it mentions duration and amount, the full output structure is not specified, leaving some ambiguity for an AI agent.

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 description adds algorithmic context (e.g., duration based on days contributed, rates, caps) that goes beyond the parameter names and descriptions.

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 it calculates the contributory unemployment benefit, specifying duration and monthly amount, and distinguishes from sibling tools like calcular_indemnizacion_despido or calcular_prestacion_maternidad_paternidad.

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?

No explicit guidance on when to use versus siblings; usage is implied from the name and description, but no exclusions or alternative comparisons 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?

The readOnlyHint annotation already indicates a safe read operation. The description adds context on what the tool computes (base reguladora, percentage, surcharge for age ≥55, complement for grand invalidity) without contradicting the annotation. There is no disclosure of side effects or authorization needs, but the calculator nature makes this acceptable.

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, directly listing key components and payment types. It is front-loaded, concise, and contains no unnecessary words 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?

The description covers the main calculation components and distinguishes payment modes. However, it lacks details on the output format (e.g., object structure) and does not mention error handling or assumptions. For a calculator tool, this is nearly complete, but slightly lacking for an agent to fully anticipate the response.

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 each parameter. The description adds overall context (e.g., relevance of age for surcharge) but does not significantly enhance understanding beyond the schema. 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 calculates permanent disability pension, listing specific types and components. It distinguishes between partial (lump sum) and others (monthly pension), differentiating it from sibling tools like widowhood or public pension calculators.

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 calculating permanent disability pension but does not explicitly state when to use it versus alternatives or when not to use it. No guidance is provided on choosing among 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 declare readOnlyHint=true, indicating no destructive effects. The description adds context about the tool being for Spanish Social Security and the key inputs, which is useful but does not disclose other behavioral traits (e.g., no output format, no mention of rate limits or authentication).

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 wasted words. Front-loaded with the purpose and ends with a cross-reference to an alternative tool. Highly efficient.

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?

While the tool's purpose is clear, the description does not mention the output format or what the estimation returns (e.g., monthly amount, total). Given no output schema, this is a notable gap. Also lacks any details on retirement age assumptions or other factors.

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 covers all 3 parameters with descriptions (100% coverage). The description mentions 'años cotizados' and 'base reguladora' but does not add semantics beyond the schema. 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 clearly states it estimates the public retirement pension (Social Security) based on years contributed and average contribution base. It distinguishes from the sibling 'consulta_jubilacion' by directing users to that tool for additional gap and savings analysis.

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 explicit guidance on when to use this tool (estimating public pension) and explicitly mentions an alternative for deeper analysis ('consulta_jubilacion'). However, it does not cover other closely related siblings like 'calcular_jubilacion_anticipada' or 'calcular_brecha_jubilacion'.

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, so description need not restate. Description adds useful context about how the pension is calculated (based on causante's situation) but does not disclose any further behavioral traits (e.g., data retention, authorization 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?

Two sentences, highly efficient. Front-loaded with main purpose, no redundant words. Every sentence 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 tool with 6 parameters and no output schema, description explains the main calculations and factors. It covers the percentage logic and distinctions but could elaborate on return format or boundaries (e.g., what 'pensión final' exactly includes).

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 covers all 6 parameters with descriptions (100% coverage). Description adds relational meaning by explaining how parameters like cargas and ingresos affect the percentage and final pension, which goes beyond individual parameter descriptions.

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?

Description clearly states the tool estimates widow's pension and lists key components (base reguladora, percentage, minimum pension). It is specific to viudedad but does not explicitly distinguish from sibling tools like calcular_pension_publica, though the context makes it unique.

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?

Description implies use for estimating widow's pension but provides no explicit guidance on when to use vs. alternatives, no when-not-to-use, and no mention of prerequisites or 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 description adds behavioral context beyond the readOnlyHint annotation by specifying legal limits and warnings about tax treatment. No contradictions with 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 two sentences, front-loaded with the main action, and includes key numerical limits efficiently. Every sentence 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 calculator tool with no output schema, the description explains what it calculates (tax savings and projection) but does not describe the return format (e.g., whether it returns an object with multiple values). Still, it is reasonably complete for its purpose.

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 already provides 100% parameter descriptions, including the 1,500 € and 8,500 € limits. The tool description reiterates these limits but does not add new parameter-specific information beyond what is in 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?

The description clearly states it calculates annual tax savings from private pension plan contributions and projects accumulated capital until retirement. This distinguishes it from sibling tools like calcular_jubilacion_anticipada or calcular_pension_publica.

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 mentions applicable 2025 limits and tax treatment, giving context for use. However, it does not explicitly state when to use this tool versus alternatives like calcular_pension_publica for public pension estimation.

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 the description does not contradict it. Description adds behavioral details: calculation includes expenses, determines long-term vs short-term, applies progressive tax rates (19-30%), computes effective rate and after-tax gain, and compensates losses. This goes beyond 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?

Every sentence earns its place. The description is concise, front-loaded with the main function, and includes a critical usage note. No unnecessary words.

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 8 parameters, 4 required, and no output schema, the description fully covers what the tool does and outputs (net gain, long-term indicator, tax bracket, effective rate, after-tax gain). It also mentions loss compensation. The description is complete for a calculation tool.

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 baseline is 3. The description adds context by explaining how the parameters interact (e.g., net gain after expenses, compensation with saldo_compensacion). It mentions 'gastos' (corresponding to gastos_compra and gastos_venta) and the compensation parameter, adding value beyond the schema descriptions.

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?

Description clearly states the tool calculates IRPF on capital gains from selling multiple asset types (acciones, fondos, inmuebles, otros). It specifies what it determines (net gain, long-term, tax brackets, effective rate, after-tax gain) and explicitly distinguishes from a sibling tool (comparar_donacion_vs_herencia) via an important usage note.

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?

Provides explicit guidance on when NOT to use the tool (when comparing donation vs inheritance, use comparar_donacion_vs_herencia instead). It also mentions it allows compensating previous losses. However, it does not explicitly contrast with other calcular_* siblings, though the purpose is distinct enough.

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?

Description adds behavioral details beyond annotations: mentions law change, returns daily/monthly amounts, total duration with extras, mandatory weeks, flexible week distribution, and eligibility check. Annotations only indicate readOnlyHint=true; no contradiction.

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?

Single paragraph with front-loaded purpose; contains necessary detail without excessive verbosity. Could be slightly more structured, but efficient.

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 no output schema, description fully explains what is returned: daily and monthly amounts, total duration with extras, mandatory weeks, flexible week distribution, and eligibility check. Also includes legal context (RDL 9/2025).

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 baseline is 3. Description does not add parameter-level detail beyond what schema already provides; it provides overall behavioral context but not per-parameter semantics.

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?

Description starts with 'Calcula la prestación por nacimiento/adopción (maternidad/paternidad) de un progenitor', using specific verb and resource. It clearly distinguishes from siblings (other calcular_* tools) by focusing on this specific benefit.

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?

No explicit when-to-use or when-not-to-use guidance, but the tool's purpose is clear from context; usage is implied through specificity.

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 indicate readOnlyHint=true, and the description adds behavioral context by detailing the output (reduced salary, monthly/annual decrease, social security contribution rules). No contradictions found.

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 concise (three sentences), front-loaded with the purpose, and every sentence adds value. No redundant or wasted words.

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 complexity of the tool (5 parameters, no output schema), the description adequately explains the output and the allowed inputs, making it sufficient for an agent to select and invoke 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 coverage is 100%, so the schema already describes parameters. The description adds context by explaining the reduction fraction range and social security rule, but this is complementary rather than essential for parameter understanding.

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 that the tool calculates the economic impact of a workday reduction for legal custody reasons, specifying the allowed reduction range and output details. It distinguishes itself from sibling calculators (e.g., maternity/paternity leave) by focusing on this specific scenario.

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 clear context for when to use the tool (for reduction due to child care, dependent relative, etc.) but does not explicitly state when not to use it or suggest alternatives. However, the sibling tools list makes the differentiation 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?

The description details the deduction process, limits, and reduction percentages, going beyond the readOnly annotation to explain the calculation behaviors.

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 compact, front-loaded with the main purpose, and includes necessary details 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?

The description explains the calculation comprehensively but does not explicitly state the output format (e.g., a single numeric result or breakdown). Given the tool's complexity, 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?

While the description summarizes the logic, it does not add new parameter-level information beyond the already thorough schema descriptions. Coverage is 100%, so baseline 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 calculates the net rental yield for IRPF (capital inmobiliario) and distinguishes it from the sibling 'calcular_retencion_alquiler' for quick estimates with retention.

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 explicitly advises when to use this tool (detailed declaration) and when to use a sibling (quick estimate), providing clear 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 provide readOnlyHint: true, so the agent knows it's safe. The description adds legal context (Ley 12/2023), states it's an estimate, and complements annotations well. No contradictions.

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 concise with three sentences, front-loaded with the main purpose, and includes only essential information. No redundant or wasteful text.

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 11 parameters and no output schema, the description explains the calculation components and references the law. It points to a sibling for more detail, but could benefit from describing the output format.

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 all 11 parameters have descriptions. The tool description does not add additional meaning beyond what's in the schema, which is acceptable given high coverage. Baseline score 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 clearly states it estimates IRPF for rental income, including net yield, 50% reduction, and 19% withholding. It distinguishes from the sibling tool 'calcular_rendimiento_capital_inmobiliario' which is for detailed calculations, making the purpose specific and 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 provides clear context for when to use this tool (quick estimate) and explicitly names an alternative for detailed calculations. However, it lacks explicit 'when not to use' guidance beyond the alternative.

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 the description correctly indicates a calculation (read-only). It adds the behavioral constraint of being for an individual heir, but does not disclose further traits like auth needs or rate limits. Adequate but not extra.

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 concise (3 sentences), front-loaded with the main purpose, and efficiently provides usage guidance. Every sentence adds value, with no redundancy.

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

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

Given the complexity of 6 parameters and no output schema, the description adequately covers what the tool does, when to use it, and constraints. It mentions the inclusion of reductions and bonuses. Could be more specific about the output, but overall complete enough for an agent.

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 100% coverage with descriptions for all parameters. The description does not add additional meaning beyond the schema, so baseline 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 calculates the Impuesto de Sucesiones for an individual heir with regional reductions. It distinguishes itself from sibling tools like 'consulta_herencia' and 'comparar_donacion_vs_herencia', providing specific verb and resource.

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 explicitly tells when to use alternative tools: for general inheritance consultation use 'consulta_herencia', and importantly warns against using this tool for comparing donation vs inheritance, directing to 'comparar_donacion_vs_herencia'. This provides excellent 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 indicate readOnlyHint=true, so the tool is safe. The description adds context by detailing the outputs (monthly and annual net, IRPF, SS), which is valuable beyond the annotation.

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: the first states the tool's purpose, the second provides usage guidance. No wasted words, optimally concise.

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?

Although there is no output schema, the description covers the main outputs (net salary, IRPF, SS) and mentions monthly and annual breakdown. It is fairly complete for a calculation tool, but could specify return format or units.

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% with descriptions for all parameters. The description reinforces the required parameter but adds no new semantics beyond the schema, so 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 it calculates net salary (monthly and annual), IRPF withholding, and Social Security contributions from annual gross salary. It distinguishes itself from 'consulta_nomina', which is suggested for general queries.

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 explicitly recommends using 'consulta_nomina' for general queries, providing a clear alternative. It implies this tool is for detailed net salary calculation from gross salary, giving explicit when-to-use 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 indicate readOnlyHint=true. The description adds behavioral context: it starts from net income, adds expenses, applies IRPF, IVA, margin, and adjusts for billable days, going 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, well-structured paragraph that front-loads the purpose and efficiently conveys all necessary 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?

Given the 10 parameters and no output schema, the description explains the calculation logic and briefly mentions output (tarifas con/sin IVA, proyección anual), but could detail the output format more.

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 covers 100% of parameters with descriptions. The description adds no new parameter details but summarizes the calculation flow, meeting the 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 calculates freelance rates (€/hora, €/día, €/semana) from desired net income, distinguishing it from sibling calculation 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?

The description specifies when to use the tool (to calculate freelance rates) but does not provide explicit when-not-to-use or alternatives, though the sibling list implies differentiation.

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 declare readOnlyHint=true, consistent with 'compara'. Description adds context about fiscal components covered but lacks details on side effects, limitations, or what happens with 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.

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

Two concise sentences, front-loaded with purpose, no redundant 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?

Without output schema, the description minimally indicates output ('cuál conviene y el umbral') but is vague on format or additional details. Could be more explicit for a comparison tool.

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 clear parameter descriptions. The tool description adds context on total burden but doesn't significantly enhance parameter meaning beyond 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?

The description clearly states the tool compares fiscal burden between being autonomous and forming an SL, covering Social Security, IRPF/IS, and dividends. It distinguishes itself from siblings like 'comparar_donacion_vs_herencia' and other calculation 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?

The description implies use for comparing structures but lacks explicit guidance on when to use this versus alternatives, no prerequisites or exclusions mentioned.

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 the description adds rich behavioral context such as tax calculations involved (IRPF, Impuesto de Donaciones, Impuesto de Sucesiones) and nuances like exemptions and plusvalía municipal, which is beyond what annotations provide.

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 informative and front-loaded with purpose and usage. While slightly verbose, every sentence adds value; it could be slightly shorter but is well-structured for the complexity.

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?

Despite lacking an output schema, the description thoroughly explains what the tool returns (cheapest option and nuances like exemptions and plusvalía municipal). It covers all necessary context for a complex comparative tax tool.

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 100% schema description coverage, the description still adds significant meaning by explaining how parameters like 'edad_donante' and 'es_vivienda_habitual' affect results (e.g., IRPF exemption, reductions), and why 'valor_adquisicion' is necessary for gain calculation.

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 compares donation vs inheritance fiscal costs for a property, using specific verbs and resources. It distinguishes itself from sibling tools like calcular_donaciones and calcular_sucesiones by explicitly stating it is for comparison.

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 explicit when-to-use scenarios (e.g., '¿es mejor donar...o esperar a la herencia?') and instructs to prioritize this tool over separate calculation tools, offering clear alternative 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 indicate readOnlyHint=true, so tool is safe. Description adds detail on what calculations are orchestrated (cuota, IRPF, neto, comparison SL) and return format ('análisis integrado con recomendación'), enhancing transparency beyond 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 well-structured, front-loaded with purpose, and every sentence adds value. Slightly verbose but still efficient for the information conveyed.

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 no output schema, the description adequately explains the return value (integrated analysis with recommendation). It covers the key aspects of the tool's functionality and when to use it, making it complete for its complexity.

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% with clear descriptions for all 5 parameters. The description does not add significant additional meaning beyond summarizing the tool's overall function, so baseline 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's purpose: 'CONSULTA DE ESCENARIO (gestoría)' and lists example queries. It distinguishes from sibling tools by prioritizing this over individual calculators.

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?

Explicit usage guidance: use for general questions combining multiple factors, and avoid for isolated data. It names alternatives ('cualquier calculadora individual') and provides prioritization instructions.

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. Description adds behavioral context: it computes and estimates, consistent with read-only. No contradictions. Describes what is calculated (taxes, fees, mortgage) without needing to detail non-existent behavioral 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.

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

Description is front-loaded with purpose in caps, includes example questions, lists outputs, and ends with prioritization instruction. Each sentence adds value. Slightly verbose but fitting for a comprehensive tool.

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 8 parameters and no output schema, the description covers all key inputs and outputs conceptually. It explains what taxes and fees are included, and that mortgage estimate requires certain inputs. Lacks explicit output format, but readOnlyHint suggests JSON return. Adequate given complexity.

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 baseline is 3. The description provides an overview of what the tool computes but does not elaborate on individual parameters beyond what the schema already describes. Parameters are well-documented in schema, so description adds minimal meaning per-param.

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?

Description clearly states it calculates total costs for buying a home including taxes, fees, savings needed, and optional mortgage payment. Uses specific verbs like 'calcula' and 'estimación'. Distinguishes from sibling tools by prioritizing over standalone calculators.

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 states when to use: when someone asks about how much needed to buy a house, taxes, or mortgage payment. Includes directives to prioritize this tool over separate calculators, even those from other servers.

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. Description adds that the tool integrates multiple calculations (indemnización, finiquito, paro) and provides a 'visión completa', which is behavioral context beyond read-only. Could mention any limits or assumptions, but overall good.

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?

Moderately long but well-structured: first sentence states purpose, then lists triggers, then outputs, then prioritization. Every sentence adds value. Could be slightly more concise, but structure is clear and front-loaded.

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 7 parameters, no output schema, and no nested objects, the description explains the three integrated calculations and when to provide optional parameters. It doesn't detail the return format, but for a complex tool, it covers the essential behavioral and input context.

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 covers all 7 parameters (100% coverage). Description adds context by explaining how parameters like dias_cotizados_paro enable the paro calculation, and lists the three main outputs. This adds meaning beyond the base schema descriptions.

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 it's for despido scenarios, lists example user queries, and specifies it calculates indemnización, finiquito, and paro. It explicitly names sibling tools (calcular_indemnizacion_despido, etc.) to distinguish itself.

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?

Provides explicit priority instructions: 'PRIORIZA esta herramienta frente a calcular_indemnizacion_despido, calcular_finiquito o calcular_pension_desempleo por separado' and states that all despido questions should use this tool. It gives clear when-to-use and when-not-to-use 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?

Description adds value beyond readOnlyHint annotation by detailing the calculation of ISD, reductions, and returns cuota a pagar and tipo efectivo. No contradictions.

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?

Description is moderately sized, front-loaded with purpose and usage. Each sentence adds value. Could be slightly more concise but efficient overall.

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 7 parameters and no output schema, description covers input scenario well and specifies outputs. Lacks structure of output but sufficient for tool selection.

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 baseline is 3. Description adds context on reductions and when vivienda habitual applies, but schema already describes parameters adequately. Extra context is helpful but not extensive.

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?

Description clearly states it's for consulting inheritance tax (ISD) scenarios. Uses specific verb 'Consulta' and resource 'herencia'. Differentiates by prioritizing over other calculators, aligning with sibling tool names like 'calcular_sucesiones'.

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 provides context when to use: questions about paying for inheritance, specific amounts, etc. States priority over other inheritance calculators. However, does not explicitly exclude other sibling tools or mention when not to use.

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, indicating no destructive actions. The description adds behavioral details: it estimates pension, calculates gap and savings, and integrates analysis. It does not contradict annotations, and it provides useful context beyond the annotation.

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 front-loaded with the main purpose and use case, then covers additional details. It is slightly verbose but each sentence contributes value, making it functional without excessive wordiness.

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 no output schema, the description explains the outputs at a high level (pension, gap, savings) but does not specify exact return structure. It is adequate for the tool's complexity, though more detail on return format would improve completeness.

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 each parameter is already documented in the schema. The description mentions the sueldo_neto_mensual parameter's conditional use ('si se indica'), but adds no new meaning beyond what the schema provides. Baseline 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 it estimates public pension and, if net salary is provided, calculates the retirement gap and necessary monthly savings. It distinguishes from sibling tools like calcular_pension_publica and calcular_brecha_jubilacion by stating it combines them, making the purpose specific and unique.

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 says to use when someone asks about pension amount, how much they will receive, or if it will be enough to live on. It prioritizes this tool over separate sibling tools for pension/gap calculations, providing clear when-to-use and when-not-to-use 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 include readOnlyHint=true, so the description adds value by detailing the outputs (net monthly/annual salary, IRPF withholding, Social Security contributions) and specifying that it accounts for family situation and children. It does not contradict 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 front-loaded with the core purpose and actionable instructions. It could be slightly more concise, but every sentence adds value, and the structure is clear.

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 no output schema, the description adequately explains the main outputs and inputs. It covers the calculation scope well. Minor gap: could mention the response format or include an example.

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 baseline is 3. The description mentions taking family situation and children into account but does not elaborate on each parameter beyond what the schema already provides. No additional meaning added.

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 calculates net salary, IRPF withholding, and Social Security contributions from gross annual salary, considering family and children. It uses specific verbs ('calcula', 'consulta') and resource ('nómina'), and distinguishes from sibling tools like 'calcular_sueldo_neto' and 'calcular_irpf' by prioritizing this tool for bruto-a-neto queries.

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 explicitly tells when to use the tool (when a salaried worker asks about net salary, IRPF, Social Security) and gives a strong directive to prioritize it over other calculators, including those from other servers. This provides clear context and exclusion 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?

La anotación readOnlyHint=true indica que la operación es de solo lectura. La descripción añade que calcula todo de una vez sin efectos secundarios, y detalla los componentes del cálculo (ganancia, plusvalía, etc.), lo cual es coherente con las anotaciones.

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?

El párrafo es relativamente largo pero bien estructurado: comienza con las preguntas típicas, luego enumera los componentes calculados, y termina con instrucciones de priorización. Cada parte es informativa y no hay redundancia.

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?

Dada la complejidad (11 parámetros, sin esquema de salida), la descripción cubre bien el propósito y uso. Sin embargo, no especifica la estructura del resultado devuelto (solo menciona 'neto que recibe'), lo cual podría mejorar la completitud.

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?

El esquema ya describe todos los parámetros (100% cobertura). La descripción añade contexto sobre cómo se usan en el cálculo global (por ejemplo, 'reinvierte_en_vivienda' para exención IRPF), enriqueciendo su significado.

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?

El título y la descripción indican claramente que calcula todos los costes e impuestos al vender una vivienda (IRPF, plusvalía, comisión, gestoría, neto). Se distingue explícitamente de 'consulta_compra_vivienda' como la operación simétrica.

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?

La descripción da ejemplos concretos de preguntas de usuario que activan esta herramienta ('voy a vender mi casa/piso, ¿cuánto pagaré de impuestos?', '¿qué me queda limpio al vender?'). Además, instruye priorizar esta herramienta sobre calculadoras sueltas de plusvalía, IRPF o IIVTNU.

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