meskeIA MCP

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

The description adds value beyond the readOnlyHint annotation by specifying the formulas used and the output (1RM + training load table). It is consistent with annotations and provides behavioral context about the computation.

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?

Extremely concise: two sentences. First sentence states purpose and formulas, second states outputs. No unnecessary words.

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

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

The description covers inputs, formulas, and outputs (including the training load table). Without an output schema, it provides sufficient context for an AI agent to understand the tool's behavior.

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 meaning beyond the parameter descriptions in the schema, which already explain 'peso_kg' and 'repeticiones'.

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 1RM using Epley and Brzycki formulas, distinguishing it from sibling tools (which are unrelated calculators). It uses specific verb 'calcula' and resource '1RM'.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The context implies it's for strength training, but alternatives or prerequisites (e.g., needing to have performed a set to failure) are not mentioned.

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

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

Annotations already declare readOnlyHint=true. Description adds valuable behavioral context: it uses two formulas (NPF and 500/300) and evaluates whether a chosen time results in point stars, microtrails, or star trails.

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 main purpose, efficient and 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?

No output schema exists. Description partially explains output (evaluates chosen time), but does not specify what numeric values or format the output will take. Incomplete 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% with parameter descriptions. The description does not add extra meaning beyond the schema, only mentions formulas without linking to 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?

Clearly states the tool calculates maximum exposure time for astrophotography without star trails, using specific formulas (NPF and 500/300). Distinguished from sibling calculator tools by its specific astrophotography context.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The domain is implied, but missing boundaries for when other tools might be more appropriate.

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

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

Annotations already declare readOnlyHint=true, indicating a safe operation. The description adds useful context about including a comparison between codecs, enhancing understanding beyond the annotation. 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?

Two concise sentences: first states the main purpose, second adds the comparison detail. No redundant information, front-loaded with the core function.

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 could specify return units (e.g., bitrate in Mbps, file size in GB). It adequately describes inputs but lacks output details, making it moderately 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 baseline is 3. The description adds little beyond listing the parameters (resolution, fps, duration, codec) which are already in the schema. The mention of codec comparison provides marginal extra 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 the tool estimates bitrate and file size based on resolution, fps, duration, and codec. Among siblings like calcular_camara_lenta or calcular_fov_video, this tool's focus on bitrate and file size uniquely distinguishes it.

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

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

The description implies usage for bitrate estimation but does not explicitly state when to use it versus alternatives like other video calculators. No exclusion criteria or alternative tool names are provided.

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

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

Annotations already indicate readOnlyHint=true, so the description adds context by detailing outputs (break-even year, savings, etc.). No additional behavioral traits beyond annotations are disclosed.

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

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

The description is a single efficient paragraph of four sentences, front-loaded with purpose, listing inputs and outputs. No redundant information, though could be structured with bullet points for clarity.

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, 3 required, and no output schema, the description adequately explains return values (year, savings, cost per km) and optional parameters. It covers necessary context 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%, with each parameter described. The description summarizes inputs and mentions default values, but does not add significant meaning 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 the year when an electric car becomes cheaper than a gasoline equivalent, listing required and optional inputs and expected outputs. It distinguishes itself from sibling tools like calcular_combustible (fuel cost) and recomendar_vehiculo (vehicle recommendation).

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 inputs needed but does not explicitly state when to use this tool versus alternatives. Usage context is implied but lacks clear exclusions or alternative recommendations.

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

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

Annotations indicate readOnlyHint=true, and the description aligns by stating the tool calculates and returns values without mentioning any side effects. It adds behavioral context such as returning the multiplier, correct shutter via the 180° rule, and slowed duration, which goes beyond the annotations.

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

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

The description is a single, well-structured sentence that front-loads the main purpose and key outputs, with no wasted words. 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 the simple tool with only 2-3 parameters and no output schema, the description covers the main inputs and outputs (multiplier, shutter, duration). It is complete enough for an agent to understand the tool's functionality without needing additional documentation.

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 examples (e.g., 4×) and mentions the 180° rule, providing additional meaning beyond the schema. The optional parameter duracion_grabacion_s is clearly linked to calculating slowed duration.

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 slow-motion factor of a video from recording and playback fps, returning the multiplier, correct shutter according to the 180° rule, and the duration of the slowed clip. It uses a specific verb 'calcula' and resource 'factor de ralentización', distinguishing it from sibling tools like calcular_regla_180_video by focusing on the combined calculation.

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

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

The description implies usage for video slow motion calculations, and the context of sibling tools like calcular_regla_180_video suggests a differentiation. However, it does not explicitly state when to use this tool versus alternatives, or provide exclusions, but the purpose is clear enough for an agent to decide.

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

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

Annotations already declare readOnlyHint=true, indicating no side effects. The description adds no further behavioral context beyond the calculation details, but does not contradict annotations.

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

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

The description is a single, well-structured sentence that front-loads the tool's purpose and then lists modes. No extraneous words; 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?

The description specifies the outputs for each mode (consumption, cost per km, autonomy, etc.). Without an output schema, this is sufficient for an agent to understand return values. Could slightly improve by mentioning precision or format, but adequate.

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

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

Schema description coverage is 100%, so the schema already explains each parameter. The description provides overall context but does not add new meaning beyond what the schema offers.

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 two distinct modes (consumo and viaje) with explicit inputs and outputs, making the tool's purpose unambiguous. It differentiates from sibling tools which cover other calculation domains.

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 each mode (real trip data for consumo, future trip estimate for viaje). It does not explicitly state when not to use or provide alternatives, but the context of sibling tools makes the 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?

Annotations already declare readOnlyHint=true, so the tool is safe for reads. The description adds behavioral context about returning relative labels (today, yesterday, etc.), which is valuable beyond the annotation. No contradictions.

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

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

The description is two clear sentences, front-loaded with the main purpose, and contains no extraneous information. Every word is necessary.

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 completely covers the functionality. It explains both the primary output (day of week) and additional relative information, which is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description explains the function of the parameter in general terms but does not add new details beyond what the schema's description provides (format YYYY-MM-DD or 'hoy').

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 determines the day of the week for a given date and also provides relative information (today, yesterday, etc.). It distinguishes itself from siblings like calcular_diferencia_fechas by focusing on day-of-week rather than date differences.

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 getting day-of-week and relative date info, but does not explicitly state when to use this tool versus alternatives or provide exclusions. The context of sibling tools makes it somewhat clear, 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?

Annotations provide readOnlyHint=true, description does not contradict. Describes computational output (days, weeks, months) adding behavioral context. No mention of side effects or permissions, but appropriate for a read-only 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 sentences: first covers output, second covers use cases. Front-loaded, no fluff, 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?

Tool is simple with no output schema; description adequately lists return values (days, weeks, months, exact breakdown). Minor omission: no mention of behavior for 'hoy' or time components, but sufficient for typical usage.

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 both parameters. Description does not add parameter-level details beyond schema, meeting the baseline of 3.

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

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

Description clearly states verb 'Calcula' and resource 'diferencia entre dos fechas', specifically listing outputs like días totales, semanas, meses, desglose exacto. Distinguishes from siblings such as calcular_dia_semana or calcular_edad by focusing on date difference.

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

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

Provides explicit use cases: 'plazos, antigüedad, tiempo transcurrido o tiempo restante hasta un evento'. Lacks explicit when-not-to-use or direct sibling comparison, but context is clear.

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

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

Annotations already declare readOnlyHint=true. The description adds behavioral details: it calculates age in years/months/days, total days lived, and next birthday. It does not contradict annotations, and the added context is valuable for a read-only 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, front-loaded sentences. First sentence states the main function, second adds extra outputs. No redundant or 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 low complexity (2 parameters, no output schema), the description reasonably covers what the tool returns: age breakdown, total days, next birthday. It may lack explicit format details but is sufficient for an agent to understand the output.

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% for both parameters. The description mentions the birth date and implicitly the reference date through context (próximo cumpleaños), but it does not add significant meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states it calculates exact age in years, months, and days from a birth date, and also provides total days lived and next birthday. It uses a specific verb and resource (calcular edad) and is distinct from sibling tools like calcular_diferencia_fechas or calcular_dia_semana.

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 from a birth date but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on when not to use it or comparisons with sibling tools.

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

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

Annotations already indicate readOnlyHint=true. Description adds transparency by listing the computed statistics (mean, median, etc.) and mentioning it does not modify data, consistent with 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?

Concise: first sentence states purpose, second gives use cases, third mentions chainability, fourth provides a ready-to-use prompt. No redundant phrases.

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 compensates by listing all output statistics. With 3 clear parameters and readOnlyHint, the description is complete for an agent to use 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% with detailed descriptions for all parameters. Description adds usage examples but no additional 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?

Description clearly states verb ('calcula') and resource ('principales descriptores estadísticos de un conjunto de datos numéricos'), listing specific statistics. It distinguishes from sibling tools that are domain-specific 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?

Provides examples like analyzing investment returns and prices, and notes it's chainable with other tools returning numerical series. Lacks explicit when-not-to-use or alternatives, but sufficient 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?

Annotations already declare readOnlyHint=true, so the tool is clearly a read operation. The description adds that it calculates equivalent exposures by varying one parameter, but does not disclose any additional behavioral traits such as precision limits, rounding, or response format. Without such details, the description provides only minimal added 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 consists of two concise sentences that are front-loaded with the main action. Every word is purposeful, and there is no redundant or extraneous information. It efficiently conveys the tool's purpose and 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 that there is no output schema, the description should ideally mention what the tool returns (e.g., the computed equivalent values for the adjusted parameters). It only implies the result by stating 'calcula exposiciones fotográficas equivalentes', but an explicit note about output format would improve completeness. The description is adequate but not fully comprehensive.

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

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

With 100% schema coverage, all parameters already have detailed descriptions in the input schema. The tool description adds context by linking each parameter to real-world uses (e.g., ISO for noise, aperture for bokeh, shutter for motion), but does not introduce new semantic details beyond what the schema provides. 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 the verb 'calcula' and the resource 'exposiciones fotográficas equivalentes', and explains that it varies one of three parameters (ISO, aperture, shutter speed) while maintaining the same EV. This distinguishes it from sibling tools like calcular_astrofoto_exposicion, which is for astrophotography, and calcular_filtro_nd_video, which is for ND filter video exposure.

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

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

The description provides explicit use cases: adapting exposure for tripod, motion, noise, or bokeh without changing the recorded light. It implies when to use the tool, but does not mention when not to use it or alternatives among siblings, which would make it more comprehensive.

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

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

Annotations include readOnlyHint=true, which is consistent with the tool being a calculation. Description does not add extra behavioral traits beyond what annotations already indicate, so it's adequate but not enhanced.

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 clear, front-loaded sentences with no wasted words. Efficiently conveys purpose and use cases.

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 arithmetic tool with fully documented parameters, the description provides necessary context about use cases and output (obtaining another date). No output schema 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?

Input schema covers 100% of parameters with descriptions. The tool description does not add meaning beyond the schema; it only restates the overall operation.

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 adds or subtracts time units to/from a date, using specific verbs and resource. It distinguishes from sibling tools like calcular_diferencia_fechas (which calculates the difference between two dates) by focusing on date arithmetic.

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 usage context: 'Útil para calcular plazos, vencimientos, fechas futuras o pasadas.' It implies when to use but does not explicitly contrast with similar tools like calcular_edad or calcular_diferencia_fechas.

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

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

Annotations already indicate readOnlyHint=true, and description adds that it calculates stops and recommends a filter. No contradictions, but it does not disclose any assumptions or limitations (e.g., lighting conditions). For a calculator, basic transparency 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?

Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.

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

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

For a simple calculator with 2 parameters and no output schema, the description explains inputs and what is calculated (stops and recommended filter). It could be more explicit about the return format, but it is sufficiently complete given the tool's simplicity.

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

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

Schema coverage is 100% and description enhances both parameters with example values (25, 30, 60 for fps; 0.002 for 1/500, etc.) and clarifies units (segundos). This adds significant 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?

Description clearly states the tool calculates the ND filter needed for the 180-degree rule, specifying the context (exteriores) and filter range (ND2–ND1000). It distinguishes from sibling tools like calcular_regla_180_video by focusing on filter calculation.

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

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

Explicitly describes when to use (to comply with 180-degree rule in exteriors) and what inputs to provide. However, it does not mention when not to use or alternative tools, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, so the description's main behavioral addition is the inclusion of sensor format comparison and equivalent focal length. It does not contradict annotations and provides useful context beyond safe read operations.

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

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

The description consists of two concise, front-loaded sentences. The first sentence states the primary purpose, and the second adds an additional feature. There is no superfluous text.

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

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

Given no output schema, the description adequately outlines what the tool returns (angles and equivalent focal length). It could be slightly more specific about the return format (e.g., degrees), but it is sufficient for a simple 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 description coverage is 100%, so the baseline is 3. The description adds context about sensor comparison and equivalent focal length, but does not add per-parameter clarifications 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 horizontal, vertical, and diagonal FOV for given focal length and sensor, which is a specific verb-resource combination. It distinguishes itself from sibling calculation tools (e.g., 'calcular_profundidad_campo') by focusing on FOV.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It implicitly indicates usage for FOV calculations, but lacks guidance on sensor selection or comparison scenarios.

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

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

Annotations declare readOnlyHint: true, consistent with the tool's purpose. The description adds no additional behavioral context beyond that. It does not contradict annotations, but also does not elaborate on any other behavioral traits.

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 extremely concise with two sentences totaling 25 words. It front-loads the key purpose and parameter details without any wasted words or redundancy.

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

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

The description covers the main inputs and purpose, but does not explain the output format (e.g., whether it returns grams or ratios). Given no output schema and three simple parameters, the description is still fairly complete, lacking only minor elaboration on return values.

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 stating that the ratio adjusts automatically based on cocoa percentage, which is not covered in the parameter descriptions. This provides additional meaning beyond the schema 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 the tool calculates exact proportions of chocolate and cream for ganache based on chocolate type and desired texture. It explicitly mentions the specific parameters (tipo_chocolate, textura) and distinguishes itself from siblings by being a specific ganache calculator among many other calculators.

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

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

The description implies usage for calculating ganache proportions but does not provide explicit guidance on when to use or not use this tool. There are no exclusions or alternatives mentioned, which is a gap given the large number of sibling calculators.

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

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

The description discloses that the tool is read-only (consistent with readOnlyHint=true) and explains the calculation method: it computes kWh from appliance power and usage, then breaks down the bill into energy cost, power term, tax, and VAT. This adds value beyond the annotation by detailing the output 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?

Two sentences: first states the purpose, second explains the method and output. No extraneous information. Every word earns its place. Perfectly front-loaded.

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

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

The description covers the core functionality and output breakdown. Without an output schema, it adequately describes what the tool returns. It implicitly handles the three parameters (appliances array, preciokWh, potenciaContratadaKW). Minor omission: no mention of error handling or edge cases, but acceptable 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 input schema has 100% description coverage, already documenting each parameter. The description mentions using appliance power, usage hours, and days, but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool calculates monthly household electrical consumption and estimated bill. It specifies input parameters (appliance power, usage hours, days) and output breakdown (kWh, cost, taxes). The name and description together clearly distinguish it from sibling tools that calculate other things like running pace, macros, or dates.

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 usage: when a user needs to estimate electricity bill from appliance data. While it doesn't explicitly state when not to use or list alternatives, the context of sibling tools makes the domain clear. No explicit exclusions, but sufficient for typical use.

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

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

Annotations already declare readOnlyHint=true, indicating a safe, non-destructive operation. The description adds that the tool also classifies hydration and provides typical bread examples, enriching the agent's understanding of behavior beyond the annotation.

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

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

The description is exceptionally concise: two sentences that immediately define the tool's purpose, directionality, and additional features. 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 absence of an output schema, the description compensates by mentioning that the tool classifies hydration and provides examples. While the exact output format is not specified, this is reasonable for a simple 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% with clear parameter descriptions. The tool description adds bidirectional context and explains the two calculation modes, 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 the tool calculates bread dough hydration or water needed for target hydration, with bidirectional capability (agua→% or %→agua). It also mentions classification and typical bread examples, making the purpose distinct from siblings like calcular_porcentaje_panadero.

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

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

The description implicitly indicates when to use each mode ('Bidireccional: agua→% o %→agua') and maps input parameters accordingly. However, it does not explicitly state when not to use this tool or mention alternatives among the 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?

The description discloses the return values (category, healthy range, kg off) and adds a disclaimer about its orientative nature. Annotations already mark it as read-only, so the description complements rather than repeats. 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?

Two sentences plus a disclaimer, all front-loaded. The first sentence clearly states the purpose. The disclaimer is valuable but could be integrated. 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 simple nature of the tool, the description covers the purpose, input, output, and a necessary caveat. No missing information. Output schema not needed as description explains returns sufficiently.

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 including units and examples. The description adds minimal extra meaning beyond restating 'peso y altura'. Meets baseline but does not enhance parameter understanding.

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

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

The description clearly states the tool calculates BMI from weight and height, and specifies the outputs (categoría, rango de peso saludable, kg faltan/sobran). It distinguishes itself from sibling calculator tools by naming the specific computation.

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 BMI calculation but does not explicitly state when to use it over alternatives like other calculators. The disclaimer about not replacing medical advice provides some context but no direct guidance on tool 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?

Annotations already declare readOnlyHint=true. The description adds valuable context: data source (INE, base 2021=100), year range, and output details. No contradiction.

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

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

The description is two sentences: first defines core function and year range, second lists outputs and use cases. Every sentence adds value; 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?

The description explains inputs, range, data source, and outputs (three metrics) despite no output schema. Complete for a tool with three simple parameters.

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 descriptions cover 100% of parameters. The description adds meaning beyond schema, e.g., cantidad can be in euros or historical pesetas, anoDestino can be anterior to anoOrigen.

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 equivalent purchasing power between years in Spain using historical CPI, specifying outputs (equivalent value, accumulated inflation, CAGR). It distinguishes from sibling tools, none of which perform inflation 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 mentions it's useful for comparing salaries, prices, or investments across eras, providing clear context. No explicit when-not-to-use or alternatives, but no sibling alternatives exist, so this is sufficient.

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?

Consistent with readOnlyHint annotation; describes calculation and tax rules. No side effects. Adds context about encadenable tools.

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

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

Three concise sentences in Spanish, front-loaded with main purpose. No wasted words; efficiently conveys key 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?

Adequately complete for a calculator tool, though lacks explicit mention of return value format. The description covers usage scenarios and parameter roles well.

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 provides 100% coverage with detailed descriptions. The description adds contextual nuance (e.g., defaults, exclusivity for self-employed), enhancing understanding beyond schema.

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

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

The description clearly states it calculates compensation or tax deduction for personal vehicle use in economic activities, with specific contexts for employees and self-employed. It distinguishes from sibling tools by focusing on mileage.

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 clear context on when to use for employees vs self-employed, and suggests chaining with other tools. However, it does not explicitly state when not to use or mention alternatives.

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

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

With readOnlyHint=true already indicating safety, the description adds context by detailing the calculation process (Mifflin-St Jeor, activity multiplier, goal adjustments) and includes a note that results are orientative. No contradiction with annotations.

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

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

The description is concise: four sentences front-load the purpose, then detail the formula and adjustments, and end with a disclaimer. Every sentence contributes useful information 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?

Given the tool's complexity (6 parameters, 3 enums, no output schema), the description adequately explains the calculation algorithm and hints at the output (calories and macros). It lacks explicit output format details but is sufficient for an AI agent to understand behavior.

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 the description adds value by explaining how parameters are used (e.g., 'sexo' determines constant in formula, 'objetivo' adjusts calories and macro ratios). This ties together the individual parameter descriptions into a coherent 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 it calculates daily caloric needs and optimal macronutrient distribution using specific verbs ('calcula') and resources. It mentions the Mifflin-St Jeor formula, activity factors, and goal adjustments, distinguishing it from sibling tools like calcular_imc or calcular_gasto_energetico.

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 daily caloric needs and macro distribution) and includes a disclaimer about consulting a dietitian. It does not explicitly state when not to use or name alternatives, but the context is clear and sufficient.

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 goes beyond the readOnlyHint annotation by detailing what the tool includes: step-by-step Euclid algorithm, prime factorization, GCD and LCM factors, and common divisors. This provides valuable behavioral context for an AI agent.

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 a front-loaded main sentence followed by a compact list of included features. Every phrase 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?

Given no output schema, the description adequately covers the key aspects of the tool's behavior and output content. However, it does not specify the exact format or structure of the response.

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

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

Schema description coverage is 100%, with the parameter 'numeros' fully described in the schema. The description echoes the schema but adds no further meaning beyond the basic purpose.

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 GCD and LCM of two or more positive integers. The verb 'Calcula' and specific resource 'MCD y MCM' make the purpose unambiguous, and it is distinct from sibling tools which focus on other 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?

There is no explicit guidance on when to use this tool versus alternatives. While the purpose is clear and siblings are distinct, the description lacks contextual cues such as prerequisites or 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?

Annotations already declare readOnlyHint=true, so the description's additional mention of multiple computed outputs (pace, splits, projections) adds useful behavioral context. No contradictions or missing safety information.

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

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

The description is a single, well-structured sentence that front-loads the core functionality and lists all outputs without redundancy. Every word earns its place.

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

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

Despite lacking an output schema, the description enumerates all computed values (pace, speed, splits, projections), providing sufficient contextual completeness for a calculation tool. Minor omission: does not specify units (e.g., min/km for pace).

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 parameter descriptions for both 'distancia_km' and 'tiempo_s'. The description does not add further semantic meaning beyond what the schema provides, so baseline score of 3 applies.

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

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

The description clearly states the tool calculates pace, average speed, splits, and projections for standard distances (5K, 10K, half marathon, marathon). It uses a specific verb ('calcula') and resource, distinguishing it from siblings like 'calcular_prediccion_running' which likely provides race time predictions based on input distance rather than pace.

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 running pace calculations but does not explicitly state when to use this tool versus alternatives like 'calcular_prediccion_running'. No exclusions or when-not-to-use guidance 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?

The annotations already declare 'readOnlyHint: true', indicating no side effects. The description adds behavioral context by detailing the five calculation modes and their inputs, which is valuable beyond the annotation's indication of read-only nature.

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 one sentence with a clear structure: it states the primary function and then lists the five modes in a parenthetical list. Every part is necessary 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?

For a simple calculation tool with no output schema, the description covers all modes and parameter roles. However, it could be more complete by mentioning the expected return format (e.g., a number or percentage).

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 the description adds meaning by explaining how each parameter's role changes across the five modes, using parenthetical examples. This goes beyond the schema's brief 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 performs percentage calculations and lists five specific modes (percentOf, whatPercent, increase, decrease, variation), providing a concrete action and resource. This distinguishes it from sibling calculation tools.

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

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

The description explains the context for each mode with examples, but does not explicitly say when to avoid this tool or compare it to alternatives like 'calcular_regla_tres' or 'calcular_propina'. The guidance is clear for usage within the tool but lacks exclusion 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?

The description adds behavioral context beyond the readOnlyHint annotation by explaining that the tool automatically detects water to calculate hydration. This is valuable for agent understanding, though it could be more specific about how water is identified (e.g., case-insensitive matching of ingredient name).

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 that efficiently convey the tool's purpose, the core concept, and a key behavior (auto-detection of water). No unnecessary words or repetition.

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

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

Given the tool has no output schema, the description adequately explains inputs and the calculation logic. However, it does not describe the output format (e.g., an object with percentages per ingredient and overall hydration), which would improve 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 description coverage is 100%, so baseline is 3. The description enhances parameter understanding by reinforcing the concept that flour is always 100% in the baker's system and by explaining the auto-detection of water, adding meaning 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 the tool calculates baker's percentage for a recipe, a specific and distinct purpose. It explains that flour is always 100% and each ingredient is expressed as a percentage of its weight, distinguishing it from sibling tools like 'calcular_hidratacion_pan' which likely only computes hydration.

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 recipe calculations involving baker's percentages but does not explicitly state when not to use it or mention alternative tools. While it mentions auto-detection of water, it lacks guidance on scenarios where other tools (e.g., 'calcular_hidratacion_pan') might be more appropriate.

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

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

Annotations already indicate readOnlyHint=true, and the description aligns with that by stating 'analiza' (analyzes). It adds behavioral context beyond annotations by specifying the computed outputs: W/kg ratio, training zones, and VAM.

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

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

The description is a single sentence that front-loads the main purpose and lists key outputs. It is efficient with no wasted words, though slightly long.

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

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

The description covers the main outputs (W/kg, level, zones, VAM) and explains the optional VAM parameters. Although it lacks detail on the 'level' classification or output format, it is sufficiently complete 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% with detailed descriptions for each parameter. The description adds only the connection between optional parameters and VAM calculation, providing marginal 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 analyzes cycling performance, computing W/kg ratio, level, 6 training zones based on FTP, and optionally VAM for timed climbs. It distinguishes from sibling calculators like 'calcular_pace_running' or 'calcular_zonas_cardiacas' by being cycling-specific.

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 cycling performance analysis and notes when optional VAM parameters apply (timed climbs), but lacks explicit guidance on when to use this tool over alternatives or conditions where it should not be used.

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

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

The readOnlyHint annotation already signals no side effects. The description adds value by disclosing the exact formula and the list of returned predictions, which is sufficient for a read-only 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, well-structured sentence that efficiently conveys the purpose, formula, and outputs with no unnecessary words.

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

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

The description lists all key outputs (time, pace, speed, standard distances) without an output schema. It is complete for a calculator tool, though it omits limitations like terrain assumptions.

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 three parameters are fully documented in the schema with units and examples (100% coverage). The description does not add new parameter-specific details, so it meets the baseline but does not exceed it.

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 predicts race time using the Riegel formula, and lists specific outputs (time, pace, speed, standard predictions). This distinguishes it from sibling calculators like calcular_pace_running.

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

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

The description implies usage: when you have a base time and distance and want to predict another distance. However, it does not explicitly state when not to use it or mention alternative tools like calcular_pace_running.

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 is consistent with the readOnlyHint annotation, indicating no side effects. It explicitly states the tool returns calculations, not modifies data. No behavioral contradictions.

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

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

The description uses two concise sentences: the first states what the tool does and returns, the second provides practical use cases. 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?

For a calculation tool with 4 required parameters and no output schema, the description adequately specifies both inputs and outputs (hyperfocal distance, near/far limits, bokeh classification). Missing explicit output units, but context is 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?

The input schema already includes detailed descriptions for all four parameters (focal_mm, apertura, distancia_m, sensor). The description does not add additional parameter semantics beyond the schema, meeting the baseline for 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 the tool calculates depth of field given focal length, aperture, distance, and sensor type. It also lists specific outputs (hyperfocal distance, near/far limits, bokeh classification). The tool is distinct from all sibling calculators, which cover different domains.

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 usage scenarios: 'Útil para saber cuánto fondo quedará desenfocado o qué apertura usar en paisaje para máxima nitidez.' However, it does not mention when not to use the tool or any alternatives, leaving some 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?

Beyond the readOnlyHint annotation (which is consistent with a calculation tool), the description adds value by disclosing knowledge of country-specific tip percentages. However, it could be more explicit about default behavior (e.g., default 1 person) and return format.

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 and key context. No redundant words. The description earns its place.

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

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

For a simple tool with 100% schema coverage and no output schema, the description is sufficient. It covers the primary actions and country knowledge. Minor gaps: does not explicitly mention default values (e.g., personas=1) or what the output represents (tip amount per person or total).

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal additional meaning (e.g., 'divide entre varias personas' hints at the 'personas' parameter), but it does not significantly enhance 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 it calculates a restaurant tip and splits it among people. It distinguishes it from sibling calculator tools by specifying the domain (tip calculation) and mentioning country-specific percentages.

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 (tip calculation with country defaults) but does not explicitly state when not to use this tool or mention alternatives. It implies usage based on country knowledge.

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

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

Annotations indicate readOnlyHint=true, and the description adds context about typical uses and the cold water test. No behavioral traits beyond what annotations provide are disclosed, but no contradiction exists.

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 only two sentences, front-loaded with the core purpose, and efficiently conveys all necessary information 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 simple single-parameter tool with annotations and no output schema, the description covers the essential details: phase identification, typical uses, and supplementary test method. Slightly more context on limitations could be added, but it's 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?

The single parameter 'temperatura_c' is fully described in the input schema (100% coverage). The tool description does not add additional meaning beyond the schema, warranting baseline score.

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 identifies sugar cooking phases based on temperature, listing specific stages. It distinguishes itself from sibling tools like calcular_1rm_gimnasio or calcular_imc, which are for unrelated domains.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. However, the sibling tools cover distinct domains, so usage is implied. Lacks explicit exclusions or alternatives.

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

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

Annotations declare readOnlyHint=true, and the description adds detail that the tool returns a recommended shutter value and a table of common fps. This goes beyond annotations by specifying the output format, though no destructive behavior is present.

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

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

The description is two sentences, front-loaded with purpose, followed by the rule explanation and return value. Every sentence adds value with no wasted words. Perfectly 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?

Given the tool has one required parameter, no output schema, and read-only behavior, the description adequately explains what it does, the rule, and what it returns (shutter and table). No gaps remain for a simple computational 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 for the only parameter (fps). The description adds the rule explanation ('el obturador debe ser el doble del frame rate'), which provides context beyond the schema's example list. This moderately enhances parameter understanding.

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

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

The description clearly states the tool calculates the correct shutter speed for video using the 180-degree rule. It specifies the verb 'Calcula' and the resource 'velocidad de obturación correcta para vídeo', and distinguishes from sibling tools like calcular_filtro_nd_video or calcular_camara_lenta by focusing on shutter speed and motion blur.

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 setting shutter speed for video with 180-degree rule, but does not explicitly state when to use or not use this tool versus alternatives. No mention of prerequisites or comparisons to sibling tools.

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

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

Annotations indicate readOnlyHint=true, which is consistent. The description adds that the tool shows the formula and resolution steps, providing behavioral context. No contradictions.

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

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

The description is front-loaded with the main purpose and formulas, but it is somewhat lengthy with detailed formulae. Could be slightly more 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?

Given the tool has no output schema, the description mentions it shows formula and steps, which is helpful. The 7 parameters are fully described in the schema, but the description compensates adequately.

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 the description goes beyond by explaining relationships (e.g., X = B×C/A) and the role of each parameter in the formulas, adding value over 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 resolves 'reglas de tres' (rule of three) for direct, inverse, and compound types. It uses a specific verb 'Resuelve' and resource, distinguishing it from other calculator 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?

It explains the formulas and when to use each type (direct, inverse, compound). However, it lacks explicit guidance on when not to use this tool or mention of alternatives among sibling tools.

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

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

The description adds behavioral context beyond the readOnlyHint annotation: it states that the tool returns a complete equivalence table ('Devuelve la tabla completa de equivalencias en gramos y hojas'), which is not in the annotations nor schema. It does not contradict any annotations.

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

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

Two sentences efficiently cover purpose, inputs, and output. No extraneous information. Front-loaded with the action and key 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?

For a conversion tool with no output schema, the description adequately specifies the return format (full equivalence table) and all input types. It could mention that results include all possible conversions for a single input, but it's sufficient.

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

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

Schema coverage is 100%, but the description adds value by clarifying that 'hojas' unit only applies to leaf types and that 'hoja_oro' is most common. This provides practical guidance not present in the schema descriptions.

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

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

The description clearly states the verb 'Convierte entre tipos de gelatina' and specifies the resource (gelatin types by bloom strength). It lists all supported types, making the purpose unambiguous. It is distinct from sibling tools like 'calcular_1rm_gimnasio' which deal with different domains.

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 gelatin substitution but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned; however, the context of sibling tools suggests this is the only gelatin conversion tool, so the absence of exclusions is acceptable.

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

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

Annotations declare readOnlyHint=true, and the description does not contradict this. The description adds the behavioral trait of adjusting flour/water, but beyond that, no further traits are disclosed. It is consistent with annotations but does not enrich beyond them.

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, 169 characters, front-loaded with the core purpose. Every word is necessary. 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?

The description lacks information about the output format or that it returns multiple values (sourdough amount and adjustments). Given no output schema, the description should compensate. However, the tool is straightforward, and parameters are well-covered.

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 summarizes the overall purpose but does not add meaning specific to parameters beyond what the schema already provides. No additional parameter details are given.

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 amount of active sourdough starter to substitute for fresh, dry, or instant yeast, including adjustments for flour and water. It uses a specific verb ('calcula') and resource ('sustitución de masa madre'), distinguishing it from sibling tools like 'calcular_hidratacion_pan'.

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 yeast-to-sourdough substitution but does not explicitly state when to use versus alternatives. No exclusion criteria or when-not-to-use guidance is provided, leaving some 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?

Annotations mark readOnlyHint as true, and the description confirms it only calculates and advises, with no side effects. It does not contradict annotations.

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

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

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

Covers purpose, formula, output classification and advice, and pool length options. Could elaborate on level classification criteria but is adequate for a calculator.

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 descriptions. The description adds context (formula and default pool length) but does not significantly enhance beyond schema.

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

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

The description clearly states the tool calculates SWOLF (seconds + strokes per length), classifies swimmer level, and provides improvement advice. It specifically mentions compatibility with 25m and 50m pools, making it 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 when to use: when you have time and strokes per length. It does not explicitly state when not to use, but given no sibling tools for swimming, differentiation is not needed.

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

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

Annotations indicate readOnlyHint=true, and description does not contradict. Description adds formula details and variant, providing useful behavioral context beyond annotations. No side effects or destructive behavior disclosed beyond read-only nature.

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

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

Two sentences with no redundancy: first states purpose, second gives formula and variant. Every word earns its place.

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

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

Tool is simple with full schema coverage. Description explains formula and variant adequately. Could mention output format (return value in °C) but not essential given common 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%, but description adds value by explaining the formula and how parameters like t_preferment_c trigger the 4-factor variant, enhancing understanding beyond individual parameter descriptions.

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

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

Description clearly states the tool calculates exact water temperature for dough to reach desired dough temperature, includes the formula and variant. Distinguishes from siblings like calcular_hidratacion_pan by focusing on water temperature specifically.

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 implied usage when needing water temperature for dough, but lacks explicit guidance on when to use this tool versus alternatives (e.g., other baking calculators). No mention of prerequisites or exclusions.

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

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

Annotations already provide readOnlyHint: true, so the description adds context about the formula (Karvonen) and output (ranges and benefits). No behavioral contradictions; the tool is a calculation and the description appropriately adds value beyond annotations.

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

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

The description is three sentences, front-loaded with the main purpose and formula. Each sentence earns its place: purpose, advantage, output. No redundant or missing 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 (simple calculator, no output schema), the description is complete: it explains the formula, advantage, and output. It is sufficient for an agent to select and invoke the tool correctly given the context of sibling calculator tools.

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

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

Schema coverage is 100%, so baseline 3. The description does not add meaning beyond the schema; it only summarizes the parameters indirectly. The schema already describes each parameter adequately.

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 it calculates 5 personalized heart rate zones using the Karvonen formula, which is a specific verb+resource. It distinguishes itself from simple % max HR methods and from sibling tools by mentioning its formula and personalized nature.

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

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

The description implies when to use this tool by stating it is more accurate than simple % max HR because it includes resting HR. It does not explicitly name alternatives or exclusions, but the context makes it clear that it is the choice for personalized zones when resting HR is available.

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

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

Annotations already provide readOnlyHint, and the description adds context about the tool being a calculator and informer, and mentions chainability. No contradictory behavior is indicated, and the description supplements the annotations with useful 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 two sentences, front-loading the primary purpose and adding secondary functionality and chainability in the second. No unnecessary words, and the structure is efficient.

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

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

Given no output schema, the description explains the return values (DGT label and ZBE info) and mentions chainability. All inputs are documented in schema, and the description covers the tool's overall behavior sufficiently.

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 each parameter described. The tool description does not add new semantics beyond what the schema already provides; it merely references fuel and registration year. Baseline 3 is appropriate.

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

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

The description clearly states the tool calculates the DGT environmental label (CERO, ECO, C, B or no label) based on fuel and registration year, and also informs about ZBE access. It includes specific verb (calcula) and resource (etiqueta DGT), and distinguishes from sibling tools by mentioning chainability with recomendar_vehiculo.

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 chainability with recomendar_vehiculo, providing some usage context. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives, and does not exclude other tools explicitly.

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

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

Annotations already provide readOnlyHint=true, so the description's burden is lower. It adds value by disclosing that the tool also determines life stage and provides care recommendations, which is beyond simple conversion. No contradictions.

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

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

The description is two concise sentences: first states the core function, second provides key conversion details. No redundant information; 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 simple read-only calculator with 3 parameters and no output schema, the description is fairly complete. It covers purpose, conversion logic, and output (life stage and recommendations). Minor gaps: no mention of the return format or age bounds (though schema has min/max).

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

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

Schema description coverage is 100%, so parameters are well-documented. The description adds context about conversion factors (dog sizes, cat age formula) 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 converts pet age to human years and determines life stage with care recommendations. The verb 'Convierte' and resource 'edad de un perro o gato' are specific. It easily distinguishes from sibling calculators like 'calcular_edad' which likely handles human ages.

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

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

The description implies when to use (pet age conversion) but does not explicitly state when not to use or mention alternatives. Given the sibling list includes many calculators, some guidance on when this tool is preferred would improve clarity.

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

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

Annotations already provide readOnlyHint=true, so the behavioral burden is low. The description simply restates that it converts units, with no additional behavioral details (e.g., precision, rounding, error handling). No contradiction with annotations.

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

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

The description is a single dense paragraph listing categories and units, which is reasonably concise. It front-loads the purpose ('Convierte entre unidades...') but could be structured with bullet points for readability. 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?

With no output schema, the description does not explain the return format (likely a number or object). Missing details on error handling (e.g., invalid unit strings) and whether results include labels. Adequate for a simple converter but not fully 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% (all parameters documented). The description adds meaning by listing all category enums and providing unit examples (e.g., 'km', 'lb', 'C') for unidadOrigen and unidadDestino, which helps the agent choose correct unit strings.

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 converts between units of measure across 12 categories, listing all categories and examples of units. This distinguishes it from sibling tools which are specific calculators (e.g., calcular_imc) or a pet age converter (convertir_edad_mascota).

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

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

The description does not explicitly state when to use this tool vs alternatives, but it is the only unit conversion tool among siblings. The context implies this is the correct tool for any unit conversion, but no exclusion or when-not-to-use 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?

The description adds value beyond annotations by disclosing non-linear scaling for yeast, baking powder, spices, practical rounding, unchanged oven temperature, and time adjustment indication. Annotations only state readOnlyHint=true, which is consistent with 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?

Three concise Spanish sentences, front-loaded with purpose, followed by specific behaviors. No redundant or vague statements.

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 scaling behavior, rounding, temperature, and time adjustment. It does not explicitly describe the output format, but for a calculator tool with no output schema, the implied output is scaled ingredients. Minor gap in specifying return value.

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 meaning about how categories affect scaling (non-linear for certain types), which is not in the schema. This helps the agent understand the purpose of the optional 'categoria' field.

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

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

The description starts with 'Escala una receta a más o menos raciones', clearly stating the verb (escalar) and resource (receta) with direction (up/down). It distinguishes from sibling calculators by being the only recipe scaling tool.

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

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

The description provides clear context for when to use the tool (to scale a recipe), but does not explicitly list when not to use it or mention alternatives. Since siblings are all different domains, usage is implicitly clear.

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

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

Annotations already indicate readOnlyHint=true, so the tool is read-only. The description adds output format details (segment, motorization, estimated cost, alerts) but doesn't disclose further behavioral traits like performance or limitations.

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

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

Two concise sentences. The first states purpose and outputs; the second lists required/optional and return values. Front-loaded with the most important information, with 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?

The description covers purpose, required/optional parameters, and output structure. No output schema exists, so the description adequately explains returns. It could mention limitations or when to avoid, but overall complete for a recommendation 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 descriptions for each parameter are already present. The description adds value by clarifying required vs optional parameters and summarizing the overall input, offering context 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 recommends vehicle segment and motorization based on user profile. It distinguishes from sibling tools which are calculations or consultations in different domains.

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 required parameter (km anuales) and optional ones, providing clear context for when to use the tool. However, it does not explicitly state alternatives or when not to use it, though siblings are dissimilar.

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