meskeIA MCP

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

Without annotations, the description bears full burden and states it is a calculation that returns results (no side effects). However, it does not mention any limitations or assumptions (e.g., formula accuracy for specific rep ranges), which would have improved 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?

The description is two very concise sentences, front-loaded with the core purpose, and contains no redundant or 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 mentions both return values (1RM and a percentage-based load table), which is sufficient given no output schema. However, it could be more detailed about the structure of the table or the formulas used, but overall it provides adequate context for a simple 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?

Input schema coverage is 100% and already describes both parameters (weight and reps). The description adds no additional meaning beyond what the schema provides, so a 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 explicitly states the tool calculates 'repetición máxima (1RM)' using specific formulas (Epley and Brzycki) and returns both an estimated 1RM and a training load table by percentage. This clearly distinguishes it from sibling calculators, none of which cover weightlifting.

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 the tool is for any strength exercise, but does not specify when to use it versus alternatives (e.g., when a different formula is needed, or for rep ranges outside 1-12 where accuracy drops). No explicit guidance on prerequisites or exclusions is provided.

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

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

No annotations provided. The description covers calculation subject and normative basis but does not mention rate source validity, precision, or error handling. It discloses behavior partially but not comprehensively.

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

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

Four-sentence paragraph, front-loaded with purpose, then lists covered cases. Every sentence provides value. No 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?

Covers main scenarios, reductions, and normative reference. Missing output format description (e.g., returns tax amount) and handling of edge cases. Lacks full completeness but adequate 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 about the tax but does not enhance parameter meaning beyond schema descriptions. No per-parameter clarification needed.

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

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

The description clearly states it calculates AJD tax per Autonomous Community, lists covered document types (compraventa, préstamo, otros), and mentions reductions. This distinguishes it from siblings like ITP or IVA 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 specifies scenarios (e.g., compraventa de vivienda nueva) and normative basis, implicitly guiding when to use. However, it lacks explicit 'when not to use' or reference to alternatives like calcular_itp_ccaa.

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?

With no annotations, the description carries full burden. It discloses the use of the French amortization system (standard in Spain) and that it shows interest savings and a recommendation. However, it does not clarify any side effects (e.g., no data modification, pure calculation) or prerequisites beyond the input 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?

The description is concise (4 sentences) and front-loaded with the main purpose. It could be slightly more structured but is efficient and informative.

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 complexity (7 parameters, no output schema), the description provides a good overview but lacks specifics on the return format or exact output. It mentions interest savings and recommendation but does not detail what the user will see.

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 documents parameters. The description does not add meaning beyond the schema, only contextualizes the overall calculation. 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 the tool calculates early mortgage amortization effects in Spain, compares two options (reduce monthly payment or reduce term), shows interest savings, and recommends the best option. It uses a specific verb+resource and is distinct from sibling tools that cover 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 on when to use the tool (for early mortgage amortization) and what it does, but does not explicitly exclude alternatives or mention when not to use it. It implies usage for mortgage holders, but lacks direct comparison to siblings.

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

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

No annotations provided, so description bears full responsibility. It explains the calculation, validation, and tax savings generation. For a calculation tool, this is transparent, though it could explicitly state it is read-only. 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 a single paragraph but well-structured: starts with purpose, lists methods, mentions validation, and links to other tools. Every sentence adds value, though could be slightly more compact.

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 mentions generating a table and tax savings. It does not detail output columns or format, but for a calculation tool this is acceptable. Missing explicit return structure.

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%, but description adds beyond schema: explains methods, default values (lineal, 25% tax), and links to validation with grupoRIS. Provides context that enhances 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 it generates depreciation tables for fixed assets, specifies methods (linear, constant percentage, sum-of-digits) and references regulations (RIS 2004, RIRPF). It also mentions validation against maximum coefficients, distinguishing it from sibling tools like 'calcular_amortizacion_anticipada'.

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 methods and validation, but does not explicitly guide when to use this tool vs alternatives like 'calcular_amortizacion_intangibles' or 'calcular_amortizacion_anticipada'. Usage is implied but not contrasted.

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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It transparently describes the calculation logic for each asset type (e.g., 5% yearly for goodwill) and the detection of positive extra-accounting adjustments when accounting amortization exceeds fiscal maximum. It does not mention prerequisites or side effects, but for a calculation tool this 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 is a single paragraph but packs substantial information without fluff. It front-loads the core purpose and then details the specific rates. While a bulleted list could improve scannability, the current structure efficiently conveys all necessary rules in a compact form.

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 complexity (5 parameters, varying rules per asset type) and the lack of an output schema, the description is quite complete. It explains all critical amortization rules and the adjustment detection. However, it does not specify the return format or whether the result is a single number or multiple values, which could be clarified.

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?

Although the input schema covers 100% of parameters, the description adds significant semantic value beyond the enum labels. It explains which rates apply to each 'tipoActivo' (e.g., intangible with indefinite life uses 10% yearly), clarifies that 'vidaUtilAnios' is required for certain types, and describes how 'amortizacionContableEjercicio' is used to check for excess. This greatly aids the agent in understanding parameter dependencies.

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 is highly specific: it states the tool calculates fiscal amortization of intangibles under the Spanish Corporate Income Tax, referencing legal article LIS art. 12. It names different asset types (goodwill, indefinite/useful life) with distinct rates, clearly distinguishing it from siblings like 'calcular_amortizacion_contable' (accounting) and 'calcular_amortizacion_anticipada' (accelerated).

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 indicates when to use the tool: for fiscal amortization of intangibles in Spanish corporate tax. It breaks down applicable rates for each asset type and mentions detection of extra-accounting adjustments. It does not explicitly state when not to use it or list alternatives, but the context is clear given sibling tools and the legal reference.

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?

With no annotations, the description carries the full burden. It discloses that the tool uses two formulas (NPF and 500/300) and evaluates whether the chosen exposure yields pinpoint stars, microtrails, or star trails. This provides insight into the output quality, though it could mention assumptions or limitations (e.g., sensor types handled).

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 with no wasted words. It front-loads the main purpose (maximum exposure time) and then adds detail about formulas and evaluation. Efficient and well-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?

The description explains the purpose and evaluation categories but is ambiguous about the return value format. It mentions calculating maximum exposure and evaluating a chosen time, but does not clarify whether the output includes both a maximum time and a verdict, or how the two formulas are presented. For a tool with no output schema, this is a gap.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it mentions 'pixel pitch' and 'declination' which are already covered by parameters like 'declinacion_grados'. No extra parameter-specific guidance is provided.

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 maximum exposure time without star trails for astrophotography, using specific formulas (NPF and rule 500/300) and evaluates the chosen time. It is specific about the verb (calcula) and resource (tiempo máximo de exposición sin estelas), and distinguishes itself from other calculator tools by focusing on astrophotography.

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 astrophotography exposure calculations but does not explicitly state when to use this tool versus alternatives or provide exclusions. It mentions the formulas used but gives no guidance on when to prefer one over the other or how this tool compares to sibling tools like 'calcular_exposicion_equivalente'.

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?

Since no annotations are provided, the description carries the full burden. It adequately describes the calculation outputs (daily, monthly, total subsidy, loss), but does not disclose any behavioral aspects like prerequisites, limitations, or side effects. It is adequate for a non-destructive calculation tool.

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

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

The description is concise with three sentences, front-loading the main purpose and providing key details and examples without any superfluous text. 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?

The description covers the return values and chaining, which is important given the lack of an output schema. However, it does not mention the effect of the 'empresaPagaDiasEspera' parameter, which is a notable omission for a complete understanding. Overall, fairly 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 some context by mentioning the percentage rates for each tipoBaja, which reinforces the parameter meaning but does not add significant new information 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 temporary disability benefits for employees, specifying the exact percentages for common and work accidents. It distinguishes itself from other calculation tools by focusing on this specific subsidy, and provides concrete examples of questions it answers.

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 gives ideal use cases with examples and mentions chainable tools, but does not explicitly state when not to use it or mention alternatives. The context is clear enough for an AI agent to decide when to invoke it.

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?

With no annotations, the description carries full behavioral disclosure. It explains the calculations performed (IS at 15%, deferral, etc.) and states it calculates total tax savings. However, it does not describe the output format or any side effects, leaving room for improvement. Since it's a calculator, no destructive actions are expected, but the return structure is unclear.

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 with 4-5 sentences, efficiently listing the key incentives. It is front-loaded with the main purpose. While dense, it avoids unnecessary fluff. Could benefit from bullet points for clarity, but it remains concise and to the point.

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 8 parameters and no output schema, the description lacks detail on return values. It only says 'Calcula el ahorro fiscal total' but does not specify whether the output is a single number, a breakdown, or a report. For a tool performing multiple calculations, this is a gap. More complete output documentation would be beneficial.

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 describes all 8 parameters with 100% coverage. The description adds meaningful context by referencing the law and specific percentages (e.g., 50% deduction up to 100,000 EUR), which helps understand the purpose of parameters like importeInversionPersonaFisica and pctParticipacionPrevia. This goes beyond the schema's 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 and summarizes tax incentives for startups under Law 28/2022, specifically for companies accredited by ENISA. It lists specific incentives (IS rate, deferral, deduction, stock options, Beckham regime), making its purpose precise and distinguishable from sibling tools, none of which target startup tax benefits.

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 identifies the target audience (accredited startups) and the context (tax incentives under Law 28/2022), which implicitly guides when to use it. However, it does not explicitly mention when not to use this tool or suggest alternatives among the many sibling tools, though the unique focus on startup tax benefits reduces ambiguity.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention assumptions (e.g., compression efficiency, audio inclusion), limitations, or the methodology behind estimates. This is a significant gap for a calculation tool.

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

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

Two concise sentences: first states the core function, second adds a key feature. No wasted words, front-loaded with 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?

There is no output schema, and the description does not explain what the tool returns (units, format, whether it's a single value or a comparison table). For a calculation tool, this is a notable omission that reduces 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 parameters are documented. The description adds context by listing the inputs (resolución, fps, duración, códec) and mentioning the comparison, but this does not go beyond what the schema already 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?

Description clearly states it estimates bitrate and file size based on resolution, fps, duration, and codec, including a codec comparison. This is a specific verb+resource that distinguishes it from the many financial/HR sibling 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?

No explicit when-to-use or when-not-to-use instructions are given. The context implies it is for video encoding tasks, but no alternatives or exclusions are mentioned. It would benefit from guidance like 'Use this to estimate storage or bandwidth needs for video delivery.'

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?

No annotations are provided, so the description bears full burden. It explains what the tool calculates and the collectives, but does not disclose the return format (e.g., bonus amount), error conditions, or whether it performs read-only operations. For a calculator, additional output context would be helpful.

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: first states purpose and regulatory basis, second lists collectives and a key constraint. Efficient, front-loaded, 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?

Given the tool's complexity (multiple collectives, conditions) and absence of output schema, the description covers collectives and a key usage condition. However, it lacks information about the output (e.g., bonus amount, format) and error handling, leaving some gaps for a complete 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 descriptions exist for each parameter. The description adds context by explaining the collectives (mapping to the enum) and the condition 'only indefinite contracts' clarifies why duracionMeses is optional. This goes beyond bare 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 bonuses and reductions in employer Social Security contributions for hiring specific groups, referencing regulation RDL 1/2023. It lists all relevant collectives and notes it applies only to indefinite contracts after labor reform, distinguishing it from other 'calcular_' siblings.

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 limits usage to indefinite contracts post-labor reform, providing clear context. It does not directly compare to alternatives or state when not to use it, but the extensive sibling list implies this tool is for hiring bonuses only.

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?

No annotations provided, so description carries full burden. It explains what calculations are performed but does not disclose behavioral traits such as whether the tool is read-only, output format, or side effects. Adequate but could be more transparent.

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

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

Two sentences, front-loaded with purpose, every sentence adds value. No unnecessary words. Highly concise 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?

Given no output schema and no annotations, the description covers the tool's purpose and main calculations. It lacks details on output format, but for a calculation tool, it is fairly complete. Could mention return structure.

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 mentions key parameters (precioVenta, costosFijos, etc.) but adds minimal meaning beyond the already detailed schema descriptions. No new semantic insights.

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 break-even point in units and euros, and lists additional analyses (current situation, profit goal, what-if scenarios). It is specific and distinguishes from sibling 'calcular_*' 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?

No explicit guidance on when to use this tool vs alternatives. Among many financial siblings, there is no comparison or context for when break-even analysis is appropriate or when another tool might be better.

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?

No annotations provided, so the description fully describes behavior: it calculates and returns break-even year, annual savings, net extra investment, and cost per km. It does not mention assumptions or limitations, but is transparent about outputs.

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 with front-loaded purpose. 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?

For a 9-parameter tool with no output schema, the description explains the main outputs and inputs. It lacks discussion of edge cases (e.g., no break-even), but covers essential information.

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 documents parameters. The description adds context about required vs optional and specific subsidy values, but this largely overlaps with schema descriptions. Baseline 3 with marginal added value.

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 break-even year for an electric car vs gasoline, with specific verb+resource. It distinguishes from siblings like 'calcular_combustible' by focusing on break-even 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?

It implicitly suggests usage for comparing electric vs gasoline car costs by listing required inputs, but lacks explicit when-to-use or when-not-to-use guidance or alternatives among the many 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?

No annotations are provided, so the description carries full burden. It discloses that calculations use compound interest, which implies assumptions about growth. For a non-destructive calculation tool, this is adequate behavioral 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 concise sentences, front-loaded with the main purpose and then summarizing the calculations. 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 the complexity (6 parameters, no output schema), the description covers the main computation goals and references a sibling tool. However, it does not explicitly describe the output format or edge cases, which 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% with all parameters described including defaults and ranges. The description adds minimal extra meaning beyond the schema, mentioning compound interest which relates to 'rentabilidadAnual'. Baseline 3 per high coverage rule.

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 retirement gap, monthly loss, total capital needed, and monthly savings required. It uses specific verbs and distinguishes from siblings by focusing on the gap calculation, referencing 'calcular_pension_publica' as a complement.

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 tells when to use the tool (to compute retirement gap) and suggests using 'calcular_pension_publica' for pension estimation. It does not explicitly state when not to use it, but the context is clear for a financial calculation 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?

No annotations are provided, so the description alone must disclose behavior. It correctly describes a pure calculation tool with no destructive side effects, listing exact outputs (multiplier, shutter, duration). This transparently communicates what the tool does and returns, which is sufficient for a calculator.

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 explaining purpose, followed by a sentence enumerating outputs. It uses concrete examples (4×) and avoids unnecessary words. Every part adds value, making it concise and well-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 simple calculator with 3 inputs and 3 outputs, the description covers the return values and references the 180° rule for shutter. It does not explicitly handle the optional duration parameter's behavior when omitted, but the core functionality is clear. Given no output schema, the description sufficiently explains what the tool returns.

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, providing clear meanings for each parameter. The description adds minimal extra semantic value beyond restating outputs; it does not elaborate on parameter values or constraints beyond what the schema already offers. Hence, 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 calculates the slow-motion factor from recording and playback fps, listing specific outputs. The verb 'Calcula' and resource 'factor de ralentización' are specific, and the tool is well-distinguished from numerous sibling calcular tools by its video slow-motion focus.

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 slow-motion parameters from given fps values. It does not explicitly state when to avoid or specify alternatives, but the domain is clear and the tool's purpose is self-evident among many calculation tools. No prerequisite or context cues are provided, but it is adequate for a straightforward 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?

No annotations are provided, so the description must convey behavior. It explains the applied rule and output items, but does not disclose default values (beyond schema), side effects, or limitations. Adequate but not fully transparent.

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 paragraph with no fluff. It front-loads the core purpose, lists outputs, and adds usage context.

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 and lack of output schema, the description usefully lists the return values and notes chaining options. However, it could elaborate on assumptions (e.g., fixed rates) or calculation methodology.

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 already described. The description adds context about the effort rule but does not significantly enhance parameter understanding 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 estimates the maximum mortgage loan using the Bank of Spain's effort rule (cuota ≤ 30-35% ingresos netos). It lists specific outputs (capital máximo financiable, etc.) and provides example use cases, effectively distinguishing it from siblings.

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 it is ideal for specific questions and can be chained with calcular_hipoteca and calcular_sueldo_neto. However, it does not explicitly state when not to use it or provide alternatives among the many 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?

No annotations are provided, so the description carries the full burden. It mentions 'verifica requisitos' but does not disclose whether the tool is read-only, has side effects, or requires specific permissions. For a calculation tool, behavioral transparency is minimal.

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-load the purpose and include verification tasks. 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?

The tool has no output schema, so the description should hint at return values (e.g., 'Importe calculado'). It does not. Also, with no annotations, completeness is limited but adequate for a straightforward calculation.

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 already has a description. The tool description adds context about checking requirements and IRPF exemption, but does not significantly enhance understanding of individual parameters 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 calculates the lump sum payment of unemployment benefits for workers becoming self-employed or joining cooperatives. It includes a specific verb ('Calcula') and resource ('importe del pago único'), and the sibling tools are diverse calculation tools, so it distinguishes itself well.

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

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

The description implies use when capitalizing unemployment for self-employment, but does not explicitly tell when to use this tool versus alternatives like calcular_pension_desempleo or other calculation tools. No when-not scenarios or sibling comparisons are provided.

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

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

The description discloses reduction rates, asset categories, the cumulative limit, and the pre/post 2006 split, providing clear behavioral traits for a calculation tool, though it omits error handling or prerequisite checks.

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 paragraph that efficiently conveys all key information without redundancy, with the main purpose 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?

No output schema is provided, and the description does not specify the return value format (e.g., a single number, a breakdown), leaving critical information missing for an AI agent to use the tool effectively.

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 meaningful context (legal basis, rates, limit) that goes beyond the schema descriptions, enhancing understanding of the calculation logic.

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 reduction (abatimiento) for capital gains on assets acquired before 31/12/1994, specifying rates per asset type and the lifetime limit of 400,000 EUR, which distinguishes it from siblings like calcular_plusvalias_irpf.

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 the tool is for pre-1994 assets and includes legal references, but does not explicitly state when to use it versus alternatives (e.g., calcular_plusvalias_irpf) or when not to use it.

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?

With no annotations, the description carries full burden. It transparently states the tool's computations and non-destructive nature. It does not contradict any annotations (none provided) and provides sufficient behavioral insight for a calculator tool.

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 purpose and modes. Every sentence adds value without redundancy 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?

Despite no output schema, the description specifies what each mode returns (L/100km, cost per km, autonomy vs. liters, total cost). It is complete for a calculator tool, though it could be slightly more explicit about 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?

The input schema has 100% coverage with clear descriptions per parameter. The description adds value by explaining the two modes and how parameters relate to each mode, enhancing understanding beyond the schema 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 it's a fuel calculator with two distinct modes (consumo and viaje), specifying exactly what each mode calculates (L/100km, cost per km, autonomy vs. liters needed, total cost). It uniquely identifies the tool among many sibling calculator 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 explains the two modes and the required parameters for each, implicitly guiding when to use each mode (actual trip vs. future trip). However, it does not explicitly discuss when not to use the tool or compare it to alternative tools, though the context of many siblings makes this less critical.

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?

Without annotations, the description fully discloses the tool's behavior: it calculates BIN compensation applying FIFO, determines limit tiers (none, 50%, 25%) based on prior year revenue, ensures minimum 1M EUR compensation, and computes tax savings. For a calculator, this is highly transparent.

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 conveys essential information without redundancy. It could be slightly more structured (e.g., bullet points) but is efficient and front-loaded with the main 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?

Given no output schema, the description briefly mentions the output (tax savings) but does not detail the structure of the result. However, it fully explains the input logic and rules, making it adequate for the tool's 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% (all parameters have descriptions), but the description itself does not add additional meaning beyond the schema. Per guidelines, baseline is 3 when schema coverage is high.

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 compensable amount of negative tax bases (BINs) for Corporate Income Tax, specifying the legal article and the logic (FIFO, limits based on revenue). It distinguishes itself from sibling tools by being specifically about BIN compensation.

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 computing BIN compensation for a company, but does not explicitly state when not to use it or provide alternatives. The high specificity to tax calculations among siblings makes the context clear.

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

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

With no annotations, the description must fully disclose behavioral traits. It states the general applicability but fails to mention critical conditions for men, such as the need for cuantiaPensionMadre and madrePcibeComplemento parameters. It also does not specify that the calculation is read-only and idempotent.

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

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

The description is a single, front-loaded sentence that includes all key elements: purpose, legal reference, and applicability. It is efficient with no wasted words, though it could benefit from a brief separate sentence on usage conditions.

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 (7 parameters, conditional logic, no output schema), the description is incomplete. It omits details about conditional requirements (e.g., parameters specific to men), preconditions, and how the calculation works. Significant gaps remain for proper tool 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?

Since schema description coverage is 100%, the baseline is 3. The description adds historical context ('antiguo complemento de maternidad') but does not explain parameter meanings or relationships beyond what the schema provides. The added value is minimal.

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 the specific resource 'complemento de pensión para la reducción de la brecha de género' with legal reference. It also specifies the target users (hombres y mujeres con 2 o más hijos que cobran pensión de jubilación, IP o viudedad). While it distinguishes from sibling tools by its unique purpose, it does not explicitly contrast with similar pension 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 provides context on when to use the tool (for beneficiaries with 2+ children and specific pension types) but omits exclusions or alternatives. It does not mention that the tool is only applicable to certain scenarios based on the pension start date (as indicated by the pensionAntesDe2021 parameter) or that for men additional conditions apply.

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?

No annotations provided, so description carries full burden. It explains the tool details periods and total cost, but does not disclose how it handles different contingencies, rounding, or edge cases. Acceptable but minimal beyond schema.

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

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

Two sentences, front-loaded with purpose, efficient and informative. 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?

No output schema, and description only mentions 'detalla los períodos y el coste total', lacking explicit output structure. Adequate for a calculator tool but could specify return 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?

All 7 parameters are described in schema (100% coverage), so baseline is 3. Description adds context about calculation periods but does not explain parameter meanings beyond schema. Moderate value 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?

Description clearly states the tool calculates the company supplement during temporary disability (IT) as the gap between Social Security benefit and real salary, specifying periods and total cost. This distinguishes it from siblings like calcular_baja_medica which likely focus on the benefit alone.

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 this tool vs alternatives. The description implies it's for employer cost calculations, but does not mention exclusions or alternative tools for similar tasks.

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?

With no annotations, the description fully covers behavioral traits: it explains the legal presumption for women, additional requirements for men, and gives the 2025 amount. It does not describe the exact output format or side effects, but is fairly transparent.

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: first states purpose with legal reference, second details conditions and amount. No redundancy, front-loaded with key info.

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 provides the per-child amount but not the exact return type (e.g., monthly total, formatted string). However, it covers the main computation logic and conditional parameters adequately for a calculator 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 value by explaining when acreditaBrechaGenero defaults to true for women and clarifying pensionInferiorConyuge and hombresInterrumpioJornada conditions, reducing ambiguity 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 computes the gender pension supplement under LGSS art. 60 / RDL 3/2021, with specific conditions for women and men, distinguishing it from sibling tools like calcular_pension_complementaria or calcular_brecha_jubilacion.

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

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

It describes when to use (for the gender gap supplement) and provides conditional logic for women vs men, but does not explicitly state when not to use or name alternatives. However, the legal context and detail make usage 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?

No annotations are provided, so the description carries full burden. It discloses that estimates are orientative and notaría/registro depend on exact tariffs. It also explains optional seller calculations. This is good transparency, though it could mention any data sources or update frequency.

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 detailed but structured with bullet points for buyer and seller, and uses emojis effectively. It is front-loaded with the main purpose. Could be slightly more concise, but overall well-organized.

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 complexity (11 parameters, no output schema), the description covers the main calculations and optional inputs. However, it does not describe the structure of the return value, which would help the agent interpret results. Still adequate 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?

The schema description coverage is 100%, so each parameter has a descriptive schema. The description adds context like ITP rates by CCAA but does not provide new semantics beyond the schema. 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 calculates all purchase/sale expenses of a property in Spain with 2025 regulations, covering both buyer and seller. It distinguishes from calculators for individual taxes (e.g., plusvalía municipal, ITP) but lacks explicit differentiation from sibling tool 'calcular_venta_inmueble'.

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 comprehensive property transaction cost estimation but does not explicitly state when to use this tool versus alternatives like 'calcular_iivtnu_plusvalia_municipal' or when not to use it. No exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool analyzes specific items with given limits (e.g., 11 €/day for restaurant tickets) and states that tax savings are estimated using an orientative marginal rate of 30%. This gives insight into the tool's assumptions and behavior. However, it does not specify the output format or whether any side effects occur (though none expected).

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 brief (3-4 sentences) with no extraneous information. It front-loads the main purpose, lists the key analyzed items, and provides usage context (flexible compensation plans and chaining). Every sentence adds value, achieving high conciseness.

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 having 11 parameters and no output schema, the description covers the tool's functionality well. It explains what it computes, the main categories, and an example assumption. It also mentions chaining with other tools, aiding workflow. The lack of output description is minor given the high schema coverage and the tool's nature (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?

All 11 parameters have descriptions in the input schema, so the description does not add significant per-parameter information. It lists the categories (tickets, guardería, etc.) but does not explicitly map them to the parameters or provide additional meaning beyond what the schema already offers. A baseline of 3 is appropriate given high schema coverage.

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 determines which parts of in-kind benefits and salary supplements are exempt or taxable, listing specific categories (restaurant tickets, nursery voucher, etc.). It is specific about the resource and action. However, it does not explicitly differentiate itself from sibling tools like 'calcular_retribucion_especie', which may have overlapping functionality, slightly reducing clarity.

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 it is useful for flexible remuneration plans ('útil para planes de retribución flexible') and suggests chaining with other tools ('encadenable con...'), providing some context. However, it lacks explicit guidance on when not to use this tool versus alternatives, or any prerequisites or limitations.

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?

Without annotations, the description should disclose behavioral traits. It explains the outputs (extra cost, APR) but does not detail how the optional 'entradaInicial' parameter affects calculations or the underlying assumptions. This is adequate for a simple calculator but leaves some gaps.

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 at two sentences, front-loaded with the main action. Every sentence serves a purpose 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?

For a tool with no output schema and moderate parameter count, the description is fairly complete. It covers purpose, use cases, and the key output concepts. However, it does not describe the output format, which is a minor gap.

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

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

All four parameters are fully described in the input schema (100% coverage), so the description does not need to add much. It only mentions the default for 'entradaInicial', adding minimal value 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 the real cost of financing a purchase in installments, including the extra cost over cash price and implicit APR. It also provides concrete use cases, making it easy to distinguish from other financial 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 explains when to use the tool: to decide between installment payments and cash, and to compare financing offers. While it does not explicitly state when not to use it or mention alternatives, the guidance is clear and sufficient for the stated purpose.

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?

No annotations are provided, so the description carries full disclosure burden. It explains the calculation methodology (percentages for each contribution, inclusion of extra benefits). However, it fails to describe the output format, return value, or any error handling. Since the tool is a pure calculation with no destructive effects, the description is adequate but misses specifying what the result looks like.

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 reasonably concise, covering the purpose, key contributions, and usage in two sentences. It is front-loaded with the main purpose. Could be slightly tighter, but remains effective without 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?

Given the tool's complexity (4 parameters, no output schema, no nested objects), the description covers the calculation logic well with specific percentages and inclusion of extra benefits. However, it lacks any mention of the output (e.g., returns total cost as a number, currency, yearly/monthly). With no output schema, this omission reduces 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 already has a description. The description adds high-level context about the social security rates affecting sector and contract type, but this largely mirrors information in the schema. No additional parameter semantics beyond what is already 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 the tool calculates the real total cost of hiring an employee in Spain, including specific social security contributions and extra benefits. It uses a specific verb ('calcula') and resource ('coste real total de contratar un empleado'), and distinguishes from sibling tools by focusing on employee cost calculation rather than other financial or labor 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 context for when to use the tool (budgeting labor costs, break-even analysis) and gives concrete examples of included costs. However, it does not explicitly state when not to use it or mention alternative sibling tools for related calculations, leaving some guidance 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?

With no annotations, the description must disclose behavioral traits. It mentions regulatory details (frozen table for 2026, type 31.50%) and flat rate rule. However, it does not explain internal behavior like rounding, error handling, or validation logic. It is partially transparent but not fully.

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: first defines purpose, second details outputs (tramo, bases, cuota, tarifa plana), third adds key regulatory updates. No redundant words, well-structured 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?

No output schema exists, so description should explain return values. It does: lists outputs (tramo, base min/max, cuota, tarifa plana). It also includes critical context (regulatory freeze, rate changes). It is sufficiently complete for a calculation tool, though could specify 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 covers 100% parameters, so baseline is 3. The description adds value: clarifies that 'baseElegida' uses extremes ('minima'/'maxima') but any base in bracket is possible, explains 'rendimientoNetoMensual' as net income excluding SS fee, and explains 'esNuevoAutonomo' flat rate duration. This goes beyond 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 the tool calculates the monthly Social Security fee for self-employed based on income (Real Decreto-ley 13/2022). It specifies what it determines: bracket (1-15), base min/max, fee, and flat rate applicability. This is specific and distinguishes it from other financial tools in the sibling list.

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 self-employed social security calculations but does not explicitly state when to use this tool versus alternatives or provide any exclusions or prerequisites. Given the specific domain, it's adequate but lacks explicit 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?

With no annotations, the description discloses that it's an estimation using average tax rates and excludes specific deductions. This adds value beyond the schema, making behavior clear.

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 plus a warning, front-loaded with key information. No unnecessary words; every sentence is informative.

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?

Covers main inputs (salaries, children, withholdings, other income) and output (favorable option and savings/cost). Warns about estimation and exclusions. Missing mention of output format but sufficient for most users.

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 no significant new meaning to individual parameters beyond what the schema provides, though it gives general context about the computation.

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 compares total IRPF between individual and joint filing, calculates the more favorable option, and mentions the special reduction. This distinguishes it from siblings like calcular_irpf (individual) and other tax 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?

Provides context on when to use (comparing joint vs individual, especially when one spouse has low income) and limitations (estimation, excludes CCAA deductions). Lacks explicit 'when not to use' but sufficient for typical 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?

No annotations are provided, so the description carries full burden. It does not disclose any side effects, authentication needs, idempotency, or error behavior. Only states the calculation and return of net income, lacking deeper behavioral context.

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 only two sentences, front-loading the purpose and key features. Every word adds value with no redundancy. It is highly efficient for a quick understanding.

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 15 parameters and no output schema, the description is sparse. It does not explain the calculation logic, assumptions, or provide details on the output format or error handling. For a complex tool, more contextual information is needed.

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 in the schema. The description adds an overview of expense types and clearly mentions the return of 'rendimiento neto', which is not in the schema. However, it does not add significant detail beyond what the schema already 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 it calculates deductible expenses for self-employed IRPF under direct estimation methods and returns net income. It lists specific expense categories. However, it does not explicitly differentiate from the sibling tool 'calcular_gastos_deducibles_autonomo', which may cause confusion.

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 self-employed IRPF with direct estimation, but provides no guidance on when not to use it or mention alternatives like 'calcular_irpf' or 'calcular_estimacion_objetiva'. No exclusions or context 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?

With no annotations, the description fully discloses behavioral logic: it calculates based on conditions and applies different methods. It does not mention side effects or auth needs, but for a calculation tool this 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 is a single dense paragraph but well-organized with clear cause-and-effect structure. Every sentence adds value, though it could be slightly more structured 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 full parameter coverage and no output schema, the description sufficiently explains the tool's logic and conditions. An agent can determine when and how to invoke it correctly.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning beyond schema by explaining how parameters like porcentajeParticipacion and mesesTenencia determine exemption eligibility, and how valorAdquisicion serves as an alternative condition.

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 elimination of double taxation for Spanish Corporate Tax, referencing specific legal articles. It distinguishes from 200+ sibling tools by its specific tax domain and purpose.

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 explains when to use exemption (art. 21/22) versus deduction (art. 31/32) based on participation, holding period, and tax rate conditions. It provides decision logic but does not explicitly name alternative tools for 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?

With no annotations, the description mentions checking SS contribution limits and subtracting advance payments, but lacks details on input validation, error handling, or whether the operation is read-only. It adds some behavioral context but not fully.

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 front-loads the purpose, lists inclusions, and mentions the limit check. Every sentence adds value 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?

While the description covers the calculation logic well, it omits the return value format (e.g., single number or breakdown) and edge cases. For a moderately complex tool with no output schema, this is a noticeable gap.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds meaningful context by referencing legal amounts (1,200/2,400 EUR) and conditions that are not in the schema, helping an agent understand the calculation logic.

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 deductions for large families and disabilities, listing specific amounts and conditions, and distinguishes itself from numerous sibling 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?

No explicit guidance on when to use this tool versus alternatives (e.g., other deduction calculators). The description does not mention prerequisites, exclusions, or context for selection.

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?

No annotations provided; the description focuses on calculation formulas but omits any side effects, authentication needs, or output format, which is somewhat acceptable for a stateless calculator but still leaves gaps.

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 is front-loaded with the main purpose; it could be slightly restructured for readability but is effectively 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?

While the description covers deduction formulas and monetization option, it does not describe the return value structure or error handling, which is a gap given no output schema or annotations.

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 adds value by explaining how each parameter feeds into the deduction percentages (e.g., gastosPersonalInvestigador gets +17%), going 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 specifies the tool calculates the R&D&I tax deduction in Spanish Corporate Tax, listing exact percentages for I+D and innovation technology components, which distinguishes it from sibling tools that cover other tax 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 implicitly indicates use for Spanish companies with I+D+i expenses by detailing the deduction percentages and limits, but lacks explicit guidance on when to use versus similar deduction 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?

No annotations provided; description covers what the tool does but not behavioral traits like side effects, authorization needs, or return format. It mentions discounting advanced payments but lacks detail on execution behavior.

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

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

Four dense sentences with no redundancy. Key information (amounts, conditions, legal basis) is front-loaded. 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?

No output schema; description does not explain return format, errors, or edge cases. For a calculation tool, knowing the output structure (e.g., single amount, breakdown) is essential. Missing this context reduces 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% with clear parameter descriptions. The main description adds legal context and amounts but does not elaborate on parameter meaning beyond schema. Baseline 3 is appropriate as schema does the heavy lifting.

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 maternity deduction and additional childcare expenses, referencing specific law (LIRPF art. 81, Ley 31/2022) and amounts. It distinguishes from sibling tools by focusing on a specific deduction rather than generic tax 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?

Context implies use when calculating maternity deduction, but no explicit guidance on when not to use or alternatives. Sibling tools are distinct, so confusion is unlikely, but lacks explicit exclusions or conditions.

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?

With no annotations, the description carries full burden. It outlines the types of deductions and mentions required parameters implicitly, but does not disclose side effects, error behavior, or return format. It provides enough for basic understanding but lacks depth.

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

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

The description is concise with two sentences, front-loading the main purpose and regimes. It avoids redundancy and unnecessary details.

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 (5 parameters, no output schema, no annotations), the description lacks completeness. It does not explain the calculation method, return format, or how to interpret results. It omits mention of the 'alquiler_joven' deduction type present 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%, so the baseline is 3. The description mentions some parameters (e.g., inversionAnual, edadContribuyente, baseImponibleTotal) but adds no new semantic detail beyond what the schema already 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 calculates autonomous community housing deductions for IRPF, specifying two regimes (transitional pre-2013 and current deductions for young, rehabilitation, rural areas) and mentions inclusion of foral regions. It cites specific laws, making the purpose distinct among siblings like 'deduccion_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 does not provide guidance on when to use this tool versus alternatives such as the sibling 'deduccion_vivienda'. It implicitly targets autonomous community deductions but lacks explicit context 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the tool computes taxation categories and references legal articles, but it does not explicitly state that it is a non-destructive, read-only calculator. While the purpose implies a stateless computation, the lack of explicit statement about side effects or permissions leaves minor ambiguity.

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 two sentences. The first sentence states the core purpose and legal references, while the second enumerates the modalities. It is front-loaded and to the point, though a bullet list could improve readability. Slightly more structure would be beneficial but it remains 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 the absence of an output schema, the description provides a solid overview of the tool's scope and modalities. However, it does not specify the return format (e.g., tax liability, percentage) or how results are presented. The note that 'valorAdquisicionDerechos' applies only to transmision_plena is implied but not explicit. For a calculator with 5 parameters, some detail is missing.

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

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

All parameters have descriptions in the schema (100% coverage). The description adds value by explaining the four 'tipoRendimiento' options in a narrative form, providing context beyond the enum labels. It clarifies the differences between modalities, such as the 60% reduction for cesion vs. the 19% rate for derechos de imagen, aiding parameter selection.

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 IRPF taxation for copyright, intellectual property, and image rights income. It lists four specific modalities, distinguishing itself from sibling tools like 'calcular_irpf' which handle general income. This provides a specific verb-resource combination with clear differentiation.

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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparative scenarios. For example, it does not clarify that this is for specific types of income as opposed to general IRPF calculators, leaving the agent to infer context.

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

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

No annotations provided, so description carries full burden. It discloses the use of 360-day commercial year and tax deductibility, but does not mention limitations, error handling, or response format. Additional behavioral context (e.g., precision, edge cases) would be beneficial.

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 core purpose, and every sentence adds value. There is no redundant information, making it highly concise and well-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?

Given no output schema, the description covers what the tool calculates (net amount, TAE, costs, tax savings) but does not specify the return format (e.g., numeric values, percentages). It includes normative reference and operation types, making it fairly complete for the 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 description coverage is 100%, so parameters are well-documented in the schema. The description adds context about outputs (TAE, net amount, costs, tax savings) but does not enhance parameter meaning beyond the schema. 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 calculates the real cost (TAE) for discounting commercial paper (pagares, letras) and factoring (with/without recourse), specifying outputs like net amount, total costs, TAE, and tax savings. It distinguishes itself from sibling tools (many financial calculators) by focusing on this niche.

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 indicates what types of operations it supports (descuento_pagare, descuento_letra, factoring_con/sin_recurso), but does not explicitly state when not to use it or mention alternative tools. Usage is implied 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?

With no annotations, the description carries full burden. It discloses procedural requirements (mandatory letter, simultaneous payment, 15-day preaviso) and references legal articles. It does not explicitly state the tool is read-only, but the calculation nature implies no side effects.

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

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

The description is a single paragraph that efficiently conveys key information: purpose, legal basis, causes, and procedural warnings. It is not overly verbose, though it could be structured with bullet points for clarity. 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 7 parameters and no output schema, the description provides legal framework and procedural steps but does not describe what the tool returns (presumably indemnization and preaviso amounts). It also omits the role of 'fechaInicioContrato' in handling the 2012 labor reform, which is a notable gap given its inclusion 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 individual parameter descriptions. The description adds legal context (e.g., the 20/33 days logic, distinction between procedente/improcedente) that clarifies the role of parameters like 'declaradoImprocedente' and 'preAvisoDado', enhancing understanding 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 indemnization and preaviso for objective dismissal, citing specific legal articles. It distinguishes between procedente (20 days) and improcedente (33 days) outcomes. However, it does not explicitly differentiate from the sibling 'calcular_indemnizacion_despido', which might handle other dismissal types.

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 the causes (economic, technical, ineptitude, etc.), which imply the scenarios for using the tool. It does not explicitly state when not to use it or mention alternative tools. Usage guidance is implied rather than explicit.

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 discloses key behavioral traits: it's an orientative estimate using average tax brackets, includes various income types and personal/family minimums. No contradictions with annotations (none exist). Does not detail error handling or negative values but sufficiently warns users.

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 concise with 4 sentences plus emoji/warning, front-loaded with main purpose, use cases, and chainability. 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?

Completeness is good for a simulation tool given 17 well-described parameters and no output schema. It explains the scope and approximation. Minor gap: doesn't explicitly state the return format, but purpose implies a numerical result.

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 parameter descriptions. The description adds only a high-level summary of income categories and personal minimums, not meaningful new insights 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?

Description clearly states simulation of IRPF return result (to pay or refund) with specific verb 'Simula' and resource 'declaración de la Renta'. It lists included income types and distinguishes from sibling tools like calcular_irpf and calcular_declaracion_conjunta by noting chainability and unique use case.

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 provides explicit use cases (e.g., '¿Cuánto me devolverá Hacienda este año?') and notes it's an estimate, suggesting using Renta WEB for exact results. However, it does not state when not to use vs specific alternatives like calcular_irpf.

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 explains what the tool returns (day of week and relative info), but lacks details on read-only nature, error handling, or edge cases (e.g., invalid dates). Since no annotations are provided, the description carries the full burden, and it is insufficient for a complete understanding of behavior.

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

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

Two concise sentences with no redundancy or unnecessary information. Every sentence adds value, and the description is front-loaded with the core 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 tool with one parameter and no output schema, the description adequately covers the functionality (day of week and relative days). It is complete and leaves no ambiguity about what the tool does.

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 already has 100% coverage with a clear description of the 'fecha' parameter (includes format and special value 'hoy'). The tool description adds no additional parameter semantics 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 it tells the day of the week (lunes, martes...) for a given date, and also provides relative information (today, yesterday, tomorrow, days elapsed/remaining). It uses a specific verb and resource, distinguishing it from sibling tools that focus on financial or legal 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?

No guidance is provided on when to use this tool versus alternatives like calcular_diferencia_fechas or calcular_fecha_resultado. The description does not mention exclusions or preferred contexts.

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?

Given the absence of annotations, the description provides sufficient behavioral information: it discloses that the tool calculates exempt and taxable amounts, cites the legal basis, and lists the applicable daily and per-kilometer limits for 2025. It does not mention any side effects or state that it is a read-only calculation, but the nature of the tool (computation) is clear.

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 paragraph that front-loads the core purpose and then lists the limits. It is concise with no redundant sentences, but it could be better structured with bullet points for readability. Every sentence contributes meaningful 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?

The description covers the key aspects of the calculation (exempt amounts, taxable excess) and provides current rates. However, it does not specify the output format or what the returned object will contain, relying on the agent to infer that it returns some result. Given the complexity and the absence of an output schema, a brief note on the result structure would enhance 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?

The schema already includes descriptions for most parameters (100% coverage), but the description adds value by providing the specific monetary limits (e.g., 0.26€/km, 53.34€/day) that are not in the schema. However, it does not elaborate on the structure of the arrays or the expected number of items, relying on the schema for those details.

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 exempt and taxable parts of per diem allowances (dietas), referencing the specific article RIRPF art.9. However, it does not explicitly distinguish this tool from sibling tools like calcular_irpf or calcular_retribucion_especie, which could also deal with income tax. The specificity of 'dietas' provides implicit differentiation, but lacks explicit sibling contrast.

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 explains what the tool does and provides current year limits, but it does not specify when to use this tool versus alternative calculation tools for meal or travel expenses (e.g., calcular_combustible, calcular_kilometraje). There is no guidance on prerequisites or when not to use it, leaving the agent to infer usage context from the name alone.

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?

With no annotations provided, the description carries full burden. It discloses the types of results (days, weeks, months, breakdown) but does not specify behavior for edge cases like reverse dates or invalid inputs, leaving minor gaps.

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 what the tool does, second suggests when to use it. No unnecessary words; front-loaded with core action.

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

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

For a simple tool with no output schema, the description adequately lists return components. It covers input format (via schema) and usage contexts. Minor gaps: missing handling of invalid dates or direction of difference, 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?

Input schema has 100% coverage with clear descriptions of format (YYYY-MM-DD or 'hoy'). The tool description does not add parameter-specific meaning beyond the schema, so baseline of 3 applies.

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

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

The description clearly states the tool calculates time between two dates with multiple units (days, weeks, months, years/months/days). The verb 'Calcula' and resource 'diferencia_fechas' are specific. No sibling tool performs date difference, so it is well distinguished.

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 lists use cases: deadlines, seniority, elapsed time, and remaining time. However, it does not mention when not to use this tool or provide alternatives, though none exist among siblings.

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

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

No annotations provided, so description carries full burden. It discloses it is an estimation and returns breakdown details. It does not cover edge cases or input validation but is transparent about scope and limitations.

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 a single paragraph that front-loads purpose and is informative. Slightly verbose but acceptable; the emoji warning adds a small penalty for formality.

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 mentions return values (cuota, tipo efectivo, desglose). For a complex tax tool with many siblings, this is helpful but lacks full detail on output structure.

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 about accuracy and regional bonuses but does not elaborate on parameter relationships beyond 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 calculates Donations Tax (ISD) in Spain with precise regulatory details for 2025, listing specific components and return values. This distinguishes it from sibling tools 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?

The description implies usage for calculating donations tax but does not explicitly state when to use versus alternatives. It includes a disclaimer about professional advice but no 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?

No annotations are provided, so the description carries the burden. It discloses that the tool computes age and returns additional details (total days, next birthday), but does not mention potential side effects, data usage, or limitations. It is adequate for a read-only calculation.

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 efficiently communicates the tool's core functionality and outputs without redundancy. Every part adds value.

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

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

Given there is no output schema, the description fully explains what the tool returns (age in years/months/days, total days lived, next birthday). For a simple calculator with low complexity, the description is 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?

Input schema provides full descriptions for both parameters (fechaNacimiento and fechaReferencia) with format examples. The description adds no extra meaning beyond the schema, but the schema coverage is 100%, justifying a baseline score 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 exact age in years, months, and days from a birth date, and also provides total days lived and next birthday. The name matches exactly, and the tool is distinct from sibling 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 age calculation but does not explicitly state when or when not to use this tool versus alternative siblings. No guidance on prerequisites or exclusions is provided.

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

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

No annotations are provided, so the description must disclose behavior. It explains the calculation basis (legal scale and SMI) but does not mention whether the tool is read-only, if it modifies any state, or what happens with invalid inputs. The description is adequate for a pure calculation tool but lacks full transparency on side effects or error handling.

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 concise sentences, front-loaded with the main action. It includes the legal reference, target users, and explains the calculation output (non-seizable part and brackets). No unnecessary words are present.

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

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

The description covers the calculation logic and target users, but since there is no output schema, it would benefit from explicitly stating the return format (e.g., the maximum seizable amount, breakdown of brackets). The mention of 'parte inembargable' and 'tramos embargables' implies the output structure, but it is not fully explicit.

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 clear parameter descriptions (salarioNetoMensual, pagas, reduccionCargasFamiliares). The tool description summarizes the overall calculation but does not add extra semantic detail beyond what the schema already provides. Therefore, the description adds no significant value over 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 verb 'Calcula' and the resource 'importe máximo embargable del salario', specifies the legal scale (art. 607 LEC), and explains the calculation (non-seizable part and brackets). It also names target users (deudores, acreedores, abogados), making the purpose distinct from sibling 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 salary embargo calculations and lists potential users, but it does not explicitly state when to use this tool versus alternatives (e.g., other Spanish legal calculators) or provide when-not-to-use conditions. The context from sibling tools suggests a generic calculation family, but no direct guidance is given.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool verifies several requirements (exemption in IP, management functions, etc.), which adds transparency, but it does not describe behavioral traits like error handling, side effects, or whether it returns partial results.

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 two sentences. It front-loads the main purpose and then lists verified requirements. It is efficient and readable, though could be slightly more structured with bullet points.

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 9 parameters, no output schema, and no annotations, the description provides the core functionality and lists key checks, but lacks information on output format, error conditions, or edge cases. It is somewhat complete but leaves gaps.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline. No parameter details are missing.

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 a 95% reduction in ISD for family business transmissions, referencing specific legal articles and listing verification of requirements. This is specific and distinct from sibling tools like calcular_sucesiones or calcular_donaciones.

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 family business ISD calculations but does not explicitly state when to use this tool vs alternatives, nor does it provide exclusions or when-not-to-use scenarios. It lacks explicit guidance for the agent.

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?

With no annotations, the description carries the full burden. It discloses key behavioral traits: worker receives proportional salary plus SEPE benefit (70% first 180 days, 50% thereafter), employer may be exempt from SS contributions, and the ERTE does not consume unemployment counter. This is rich context beyond a simple 'calculate' statement.

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 purpose. Every sentence adds information (calculation details, legal reference). While not extremely concise, it is efficient with no waste. Could be slightly more structured but acceptable.

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 6 parameters and no output schema, the description explains the calculation logic and conditions (e.g., 70%/50% rule, SS exemption, unemployment consumption). However, it lacks any indication of what the return format or output will be, which is a gap for agent invocation.

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 some context (e.g., 70%/50% rule tying to diasConsumidos) but mostly repeats or complements what the schema already provides for each parameter. No significant additional meaning 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 it calculates the economic impact of an ERTE by reduction of working hours (10%-70%) for both worker and company, using specific verbs and resources. It distinguishes itself from siblings like calcular_pension_desempleo or calcular_baja_medica 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 implies use for ERTE reduction cases but does not explicitly state when to use versus alternatives. There is no mention of when not to use or which sibling tools might be more appropriate, leaving the agent without clear decision criteria.

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?

No annotations are provided, so the description bears full burden. It lists the computed statistics but does not disclose the output format, rounding behavior, or potential error handling (e.g., non-numeric inputs are prevented by schema). The description is fairly transparent about computation but lacks detail on return structure.

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 paragraph that efficiently states purpose, lists statistics, and gives usage guidance. It is well-structured and front-loaded, though a minor improvement would be to separate the examples into a bullet or explicit section.

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 complexity (multiple statistics) and lack of output schema, the description lists all computed statistics but does not specify the return format (e.g., JSON structure). It covers the 'what' but not the 'how' of output, leaving some ambiguity for the 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%, so baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions (nombre, valores with constraints, decimales). The example hints at usage but does not elaborate on 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?

The description explicitly states that the tool calculates principal statistical descriptors (mean, median, mode, variance, etc.) of a numerical dataset. It lists the exact statistics and provides usage context, clearly distinguishing itself from sibling tools focused on specific financial or legal 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 advises when to use the tool (e.g., analyzing returns, prices, expenses) and highlights its chainability with other tools that return numerical series. It includes an example query. However, it does not explicitly mention when not to use it or suggest alternatives for single-statistic needs.

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?

With no annotations, the description carries full burden. It discloses applied indices (municipality size, season), reductions (start-up, general 10% for 2025), and references legal articles. It does not detail every internal calculation but gives sufficient behavioral context.

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 of four sentences, efficiently conveying purpose, inputs, adjustments, and legal basis. No redundancy, though slightly dense; could be more scannable but not detrimental.

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 inputs and adjustments well, but lacks information about the output (e.g., net income amount, breakdown). Given no output schema, the description should hint at what is returned. Also, some parameters like 'tipoMarginalIRPF' are mentioned but their role in output is unclear.

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. The description adds value by explaining regime-specific context (e.g., annual yield from Ministerial Order, reduction percentages). This enhances understanding beyond the schema 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 the tool calculates net income for the 'Estimación Objetiva' regime, specifies inputs (modules, units, yield) and adjustments (corrections, reductions), and distinguishes it from siblings that handle other tax regimes.

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 explains what the tool does and the required inputs, but does not explicitly state when to use it versus alternatives (e.g., other estimation methods) or provide 'when-not-to-use' guidance. Usage context is implied but not explicit.

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?

With no annotations, the description carries the full burden. It explains the comparison logic and output, and the example input clarifies expected behavior. It does not mention edge cases or error handling, but for a calculation tool it is reasonably transparent.

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

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

The description is concise: two sentences plus an example and chaining hints. Every sentence adds value, with no filler or repetition. It is front-loaded with the core 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?

Despite no output schema, the description lists all output fields. Parameter descriptions in the schema are complete. The tool is a calculation with clear inputs and outputs, and the description, combined with the schema, fully covers what the agent needs to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context about the output and chaining, but does not provide additional meaning for parameters beyond what the schema already gives (e.g., deudas, pagoExtraMensual).

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 compares two debt repayment methods (Avalancha and Bola de Nieve), supports extra payments, and specifies the output (total interest, months, savings, recommended method). It also mentions chaining with other tools and gives an example query, making its purpose unmistakable.

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 includes an explicit ideal use case ('Tengo 3 préstamos, ¿cómo pago menos intereses?') and mentions chaining with calcular_prestamo and calcular_break_even, which helps in choosing this tool. However, it does not explicitly state when not to use it or provide 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?

No annotations are provided, so the description carries full burden. It details the behavioral traits of each excedencia type (duration, reservation, SS contributions) and states it calculates cost and impact on future benefits. This provides sufficient transparency for a calculation tool, though it does not explicitly confirm read-only behavior.

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

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

The description is concise, front-loaded with the main purpose, and uses a bullet-like list for types. 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?

While the description covers input behavior and types, it lacks information about the output format or return values, as there is no output schema. This omission reduces completeness 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?

Schema coverage is 100%, so baseline is 3. The description adds significant context beyond schema by explaining each tipo in detail and how antiguedad, salario, and duracion affect the calculation, thus providing additional meaning.

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 begins with a specific verb 'Calcula' and resource 'derechos y efectos de la excedencia laboral', clearly distinguishing this tool from numerous sibling 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 explains when to use the tool (for different types of excedencia) and mentions it can be chained with other tools. However, it does not explicitly state when not to use it or provide alternative 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?

With no annotations, the description must fully disclose behavior. It explains the calculation logic and legal basis, but omits details like how the base máxima anual is obtained (e.g., fixed or input), whether inputs must be annual or can be monthly, and the output format (e.g., exact amount, rounding). This leaves some ambiguity.

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-packed sentence that efficiently conveys purpose, context, and calculation rule. 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?

Given no output schema, the description should clarify the return value, but only mentions 'devuelve el 50% del exceso' without specifying the exact format (e.g., scalar amount) or handling of no excess. The legal reference adds credibility but completeness is moderate for a calculator 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?

The input schema has 100% coverage with parameter descriptions, so the description adds no new parameter-specific information. The baseline of 3 is appropriate; the schema already explains the three parameters.

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 refund for excess social security contributions in multi-activity situations, with specific details on the threshold (53.26% of max annual base) and refund rate (50% of excess). This verb+resource combination is unique among sibling tools, which are all general 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 intended use is clear: when a user has simultaneous RGSS and RETA contributions and wants to compute potential refund. However, it does not explicitly state when not to use it or suggest alternatives, which would improve 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?

With no annotations provided, the description carries the full burden. It discloses the core logic: exemption calculation based on reinvestment percentage, and the over-65 special case. It does not describe the exact output format, but the behavior is well explained.

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 concise sentences, front-loading the purpose and key conditions. Every sentence adds value, no redundant wording.

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, 100% schema coverage, and no output schema, the description covers the essential logic and special cases. It does not explain output structure, but for a calculator tool, the description is reasonably 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%, so the input schema already describes all parameters in detail. The description repeats the over-65 condition but adds little beyond the schema. 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 specifies the tool calculates a particular tax exemption (exención por reinversión en vivienda habitual) per LIRPF art. 38.1, and explains the main conditions (full/partial reinvestment, over-65 exemption), distinguishing it from sibling tools like calcular_venta_inmueble or calcular_plusvalias_irpf.

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 explains when to use the tool (when computing reinvestment exemption) and the conditions (100% reinvestment, partial, over 65). It does not explicitly mention when not to use it or name alternatives, but the specificity makes the intended use clear.

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

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

With no annotations provided, the description carries the full burden. It accurately explains that the tool calculates equivalent exposures by adjusting two parameters while keeping EV constant. It does not contradict annotations (none exist) and discloses the core behavior, though it could mention constraints or edge cases (e.g., out-of-range values).

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 (two sentences), front-loaded with the core functionality, and instantly useful. Every sentence earns its place: the first explains the calculation, the second provides practical usage scenarios. 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?

Given the 5 parameters, 100% schema coverage, and no output schema, the description covers the concept and use cases but fails to specify the output format (e.g., what values are returned). An agent might need to know if the tool returns both adjusted parameters or just one. This gap reduces 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?

The input schema covers 100% of parameters with detailed descriptions. The description adds context by naming the three parameters and the 'triangle of exposure' concept, but does not significantly extend the meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema does the heavy lifting.

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 equivalent photographic exposures by varying one of three exposure parameters (ISO, aperture, shutter speed) while maintaining the same EV. It differentiates from siblings (all financial/legal tools) by focusing on photography, and includes specific use cases like adapting to tripod, movement, noise, or bokeh.

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 (e.g., adapting exposure without changing EV), and implicitly distinguishes from other tools by domain. However, it does not explicitly state when not to use it or mention alternatives, which would be helpful given the large sibling list.

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