macalc

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

With no annotations, the description carries full burden. It mentions the Epley formula and return fields but fails to disclose formula limitations (e.g., typical validity up to 12 reps) or assumptions about weight units. This gap reduces transparency.

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

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

The description is concise with two sentences, front-loading the purpose. Every sentence adds value without unnecessary details.

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

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

Given no annotations but existing output schema and sibling references, the description is fairly complete. However, it lacks explicit usage constraints (e.g., max reps for formula accuracy) and could better integrate with the schema.

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

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

Schema coverage is 100% for the two parameters, and the description adds little beyond the schema's descriptions. The schema already explains weight and reps, so the description adds marginal value, earning a baseline 3.

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

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

The description clearly states the tool's function: generating a 1RM-to-12RM repetition table using the Epley formula. It specifies the return fields and distinguishes itself from siblings like calculate_one_rep_max (single value) and list_bundles (related 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 provides a clear context for use and directs users to list_bundles for related 'sport' calculators, aiding in tool selection. However, it does not explicitly state when not to use this tool or provide specific exclusions.

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

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

No annotations provided, so description carries full burden. States core function but omits details like rounding, overflow handling, or error conditions.

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

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

Single concise sentence with action first, plus a reference for related tools. 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?

Output schema present, so return values are documented. Lacks usage guidelines and behavioral details, but tool is simple and purpose is clear.

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

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

Schema has 100% description coverage, baseline 3. Description adds context about return format but no additional parameter-specific meaning.

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

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

Clear verb ('Add'), resource ('time durations'), and return format ('total in hours and minutes'). References list_bundles for related tools, aiding differentiation.

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

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

No explicit when-to-use or alternatives guidance. Only mentions 'See list_bundles for related calculators', which is vague.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It states the output but omits details like read-only nature, error handling (e.g., invalid date), and any side effects. For a calculator tool, this is a gap.

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 effectively convey purpose and output. The cross-reference to list_bundles is slightly tangential but not excessive. The description is front-loaded and efficient.

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

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

Given the simple tool with one parameter and an output schema, the description covers basic functionality and return values. However, it lacks context on edge cases (e.g., future dates) and does not differentiate from the similar sibling calculate_age_in_units.

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

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

Schema coverage is 100% for the single parameter, and the schema already provides format details. The description adds only the phrase 'from a birth date', which is redundant. No meaningful enhancement 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 exact age in years, months, and days from a birth date, and lists return fields. However, it does not explicitly distinguish from similar sibling tools like calculate_age_in_units, relying on a cross-reference to list_bundles.

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

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

No explicit guidance on when to use this tool vs. alternatives. The mention of list_bundles for 'temps-rh' calculators hints at related tools but does not provide criteria for choosing this one.

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

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

No annotations provided, so description bears full burden. It states a read-only calculation returning an object, but lacks detail on edge cases, errors, or required permissions. Minimal but adequate for a simple calculation.

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

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

Two sentences: first covers purpose and output, second directs to related tools. No filler, front-loaded with 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?

Complete for a simple tool with one parameter and an output schema hinted in the description. Lacks mention of error conditions but sufficient for typical use.

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

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

With 100% schema description coverage, baseline is 3. The description adds the return format but no extra insight into the birth_date parameter beyond the schema.

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

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

Description clearly states 'Calculate exact age in multiple units from birth date' and specifies the output format. It distinguishes from siblings like 'calculate_age' by mentioning 'fun calculators' and referencing 'list_bundles'.

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. It points to 'list_bundles' for related calculators, but does not compare with direct sibling 'calculate_age' or other age tools.

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

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

With no annotations, the description carries the full burden. It states what the tool computes but does not explicitly disclose read-only behavior or other traits. Since it's a calculator, the description is adequate but lacks explicit transparency claims.

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 and efficiently conveys purpose, usage, and input/output summary. It is front-loaded but could be slightly improved by detailing the input structure.

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 calculator nature and presence of an output schema, the description provides adequate context. However, it fails to fully describe the input array format and the 'type' field, which are essential for correct use.

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 0%, so the description must compensate. It mentions 'volume mL, ABV %' but does not describe the array structure, the required 'type' field, or that multiple drinks can be input. This leaves significant ambiguity.

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

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

The description clearly states the tool computes UK alcohol units and grams of pure alcohol for health tracking. It is specific about the resource and action, but does not explicitly distinguish from sibling tools like 'calculate_blood_alcohol' or 'calculate_bac_points'.

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 says to use it for health tracking and limit awareness, giving a clear usage context. However, it does not mention when not to use it or provide 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?

No annotations provided, so description carries full burden. It discloses return fields but does not mention any side effects, permissions, or constraints beyond the schema. Adequate for a simple read-like calculation tool.

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

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

Two concise sentences: first sentence states purpose and return, second points to related tool. No fluff 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?

Given the simple structure (1 param, no annotations) and presence of an output schema (though not shown), the description is adequate. However, it lacks context on when altitude_sickness is relevant versus other altitude or health 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?

Only one parameter with 100% schema coverage. The description adds no extra meaning beyond the schema's 'Target altitude in meters'. 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?

Clearly states it assesses altitude sickness risk and recommends acclimatization schedule, with specific return fields. Verb 'assess' and resource 'altitude sickness' are explicit. Sibling tools are numerous but distinguished by subject matter.

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

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

No guidance on when to use or not use this tool, nor any mention of alternatives. The reference to list_bundles for related voyage calculators is minimal and not about usage conditions.

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

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

No annotations provided, so description carries full burden. Describes the conversion operation adequately, but the return format is ambiguous with '{original}' placeholder.

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, efficient. The '{original}' placeholder is unclear and could be improved, but overall 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 low complexity and existence of output schema, description is adequate but the placeholder for return value is incomplete and confusing.

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 all parameters (100% coverage). Description adds enumeration of units but that's already in the enum. No additional semantic value 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?

Clearly states it converts angles between four specified units. However, it does not differentiate itself from the sibling convert_angle 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?

Implied usage for angle conversion, but no explicit guidance on when to use this vs convert_angle. Reference to list_bundles suggests related conversion 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?

No annotations are provided, so the description carries the burden. It discloses return values but does not mention any behavioral traits such as compounding assumptions, precision, or rate limits. For a calculation tool, this is adequate but not exceptional.

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

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

Two sentences: first states purpose, second provides a pointer to related tools. No unnecessary words, efficiently communicates 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?

Given the complexity (3 parameters, output schema exists), the description minimally covers return values but lacks details on edge cases, calculation method, or parameter relationships. It is sufficient but not thorough.

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 applies. The description adds no extra meaning beyond schema field definitions, e.g., explaining how rate or periods are used in the calculation.

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

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

The description clearly states the tool calculates periodic payment for a loan or annuity, and lists return fields. However, it does not differentiate from similar sibling tools like calculate_loan_payment or calculate_mortgage.

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 only suggests seeing list_bundles for related calculators, providing no explicit guidance on when to use this tool versus alternatives.

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

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

No annotations provided; description only mentions AI-powered and premium requirement, lacking behavioral details like accuracy, speed, or error handling.

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

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

Two concise sentences 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?

Output schema covers return values; description is brief but could provide more context given the many sibling 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?

Adds value beyond schema by noting query language (English/French) and context purpose; schema coverage is 100%.

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 it's a universal calculator for any calculation not covered by specialized tools, distinguishing it from hundreds of 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?

Implies use when no specialized tool exists, but lacks explicit exclusion of alternatives; mentions premium subscription as a constraint.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It states returns liters and gallons, but it does not mention any permissions, data integrity, rate limits, or other behavioral aspects. The input description is inconsistent with the schema (shape/radius vs. dimensions), which undermines trust.

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

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

The description is four sentences, each serving a purpose: purpose, usage, inputs/returns, and reference to related calculators. It is relatively concise but could be more efficient by directly aligning with the schema.

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 4 parameters, no schema descriptions, and no annotations, the description should be thorough. Instead, it introduces non-existent inputs (shape, radius) and omits the substrate parameter entirely. This makes the tool unusable without guessing, so completeness is very poor.

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 has 0% description coverage, so the description must compensate. It mentions 'L×W×H or radius×height in cm' but the schema only has length, width, height—no radius or shape. This adds confusion. It does specify 'in cm' which is helpful, but overall it fails to clarify the parameters' meanings correctly.

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 computes aquarium water volume in L and US gallons, specifying the domain (fishkeeping, dosing, stocking). The verb 'compute' and resource 'aquarium water volume' are specific and distinguish it from generic volume calculators like calculate_volume or calculate_pool_volume.

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 says 'Use for fishkeeping, dosing, and stocking decisions,' providing context. However, it describes inputs as 'shape (rectangular/cylindrical/bow-front), L×W×H or radius×height in cm,' but the actual schema only includes length_cm, width_cm, height_cm, and substrate_cm—no shape or radius parameter. This discrepancy is misleading and fails to guide proper use. No alternatives or exclusions are 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?

With no annotations, the description bears full responsibility for behavioral disclosure. It states the tool returns area but does not discuss rate limits, mutation (though read-only is implied), potential errors if required dimensions are missing, or how multiple shapes are handled beyond the enum. The description is too brief to fully inform an AI agent of behavioral nuances.

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: one sentence for purpose, two short statements for inputs/outputs, and a pointer to related tools. Every sentence contributes value with no redundancy.

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

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

Given the tool's complexity (10 parameters, 7 shapes), the description covers the main purpose, input structure, and output units. The schema handles parameter-shape associations. It lacks details on error handling or dimension requirements, but an output schema exists to supplement return value clarity. Overall, it is mostly 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% with all parameters having descriptions. The description adds 'Inputs: shape + dimensions' but does not provide additional meaning beyond what the schema already offers. Baseline of 3 is appropriate.

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

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

The description clearly states the tool computes area for common 2D shapes, lists examples (rectangle, triangle, circle, trapezoid), and mentions use cases (geometry, real estate, paint estimates). It does not explicitly differentiate from sibling tools like calculate_perimeter or calculate_volume, but the purpose is specific and well-defined.

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 via examples and mentions 'See list_bundles for related math calculators,' but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it.

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

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

With no annotations provided, the description carries full burden. It describes the calculation and return format well but does not disclose side effects (e.g., external API calls, rate limits, or authentication requirements).

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

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

Two sentences: the first clearly states purpose and output, the second directs to related tools. No wasted words, front-loaded with essential information.

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

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

Given the output schema exists (though not shown), the description is largely complete. It references related tools via list_bundles, but could briefly explain the category enum values for clarity.

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. The description adds value by explaining the output structure beyond the schema, but does not elaborate on parameter semantics beyond what's in the schema.

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

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

The description clearly states it calculates French auto-entrepreneur net income and social charges, and lists the specific output fields. This distinguishes it from the many sibling calculation tools by specifying the exact French micro-enterprise 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?

The description implies usage for French auto-entrepreneur calculations and directs to list_bundles for related calculators, but does not explicitly state when to use vs. alternatives or provide exclusions.

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

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

With no annotations, the description carries the full burden. It minimally states it returns 'mean and detail' but does not disclose behavioral traits such as handling of empty arrays, missing values, default modes, or any side effects. The tool likely has more behavioral nuance (e.g., how weights are applied, mode defaults) that is not described.

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 short (two sentences plus a reference) and front-loads the core purpose. However, it includes unnecessary words ('Compute simple, weighted, geometric, or harmonic mean') and could be leaner. The structure is adequate but not exceptional.

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 large number of sibling tools and the presence of an output schema, the description should distinguish this tool more clearly (e.g., from calculate_statistics or calculate_percentage). It does not explain return value structure beyond 'mean and detail', and the missing 'mode' parameter indicates incompleteness.

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% for the two parameters (values, weights), but the description introduces a 'mode' parameter that does not exist in the schema, causing confusion. The description restates basic schema info (values list, optional weights) without adding significant meaning beyond what the schema provides. The misleading mode mention lowers the 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 it computes multiple types of means (simple, weighted, geometric, harmonic) and gives concrete use cases like grade averages, returns, or rates. It uses a specific verb ('compute') and resource ('mean'). However, the mention of a 'mode' parameter not present in the schema slightly impairs clarity.

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

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

The description provides use cases ('grade averages, returns, or rates') and suggests seeing list_bundles for related calculators, offering some context. But it lacks explicit guidance on when not to use this tool or how it differs from siblings like calculate_statistics or calculate_grade_average.

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

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

With no annotations, the description must cover behavioral traits. It states inputs and return (weighted average and mention) but does not disclose behavior for invalid inputs, edge cases, or any potential pitfalls. It adequately describes core behavior but misses transparency around error handling or assumptions.

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 purpose. Every sentence contributes: purpose, usage, input/output summary, and a pointer to related tools. 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?

The tool has an output schema, so the description's mention of return values (weighted average and mention) is helpful but not strictly required. It covers the core functionality adequately for 7 required parameters. Could mention the grading scale or if it handles different Bac series, but overall complete enough.

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 (subject, max score, coefficient). The description adds little beyond summarizing inputs as 'grades by subject with coefficients'. Given high schema coverage, the description adds marginal value, meeting the baseline.

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

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

The description clearly states the tool estimates the French Baccalauréat final score from grades and coefficients. It specifies the target exam (Bac) and that it's for tracking lycée results. However, it does not explicitly differentiate from sibling tools like calculate_brevet_points or calculate_parcoursup_points, though the context of Bac is distinct.

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 context ('track lycée results before official scores') and hints at related calculators via 'See list_bundles'. It lacks explicit guidance on when not to use this tool or clear alternatives, relying on implied usage.

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

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

With no annotations, description carries full burden. It discloses key behavioral traits (adjusting leavening, liquid, temperature) but does not elaborate on whether the adjustment is proportional or absolute, nor does it mention the structure of the returned recipe.

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?

Very concise, front-loading the main action and context. Every sentence adds value, 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?

Covers purpose, usage, and references. With 5 parameters and an output schema, the description is mostly complete, though it could briefly explain the adjustment method or mention that altitude is in meters (already in schema).

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

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

Schema coverage is 100%, so descriptions already provide meaning. The tool description adds only a generic 'ingredients' mention, which adds minimal value beyond the schema.

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

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

Clearly states verb 'adjust', resource 'baking recipe', and specific context 'high altitude'. Differentiates from sibling calculators by mentioning 'mountain cooking' and referencing 'cuisine' calculators via list_bundles.

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

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

Explicitly says 'Use for mountain cooking', providing clear context. Directs to list_bundles for related calculators, but does not explicitly state when not to use this tool or name specific 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?

No annotations are provided, and the description is misleading: it lists 'value, from-unit, to-unit' as inputs, but the actual schema only includes 'ingredient' and 'quantity_cups'. This mismatch undermines transparency and could cause incorrect usage. The description does not clarify behavior like exact conversion, rounding, or density assumptions.

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 short (two sentences) and front-loaded with the purpose. However, the inclusion of a reference to 'list_bundles' adds minor noise. It is concise but omits critical details, making it incomplete rather than efficiently informative.

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

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

Given the mismatch between description and schema, and the omission of crucial parameter information, the description is highly incomplete. It fails to explain how to use the actual parameters or interpret the output, despite having an output schema. Sibling differentiation is insufficient.

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 0%, and the description contradicts the schema by listing parameters ('value, from-unit, to-unit') that do not exist while failing to explain the actual parameters ('ingredient' and 'quantity_cups'). The enum for ingredient is not mentioned either. This provides no meaningful semantic help.

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 baking measurements between cups, tablespoons, grams, and milliliters for common ingredients, with a specific use case of translating recipes across regions. This distinguishes it from generic conversion tools like 'convert_cooking' and 'calculate_cooking_conversion' among siblings.

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

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

The description provides a usage guideline ('Use for translating recipes across regions'), which gives context for when to use the tool. However, it does not specify when not to use it or mention alternative tools like 'convert_cooking' for general cooking conversions, limiting its guidance.

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

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

With no annotations provided, the description should fully disclose behavioral traits. It only states the return structure (input, decimal_value, result) but omits information on input validation, error handling, supported formats (e.g., negative numbers, fractions), or performance considerations.

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

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

The description is brief at two sentences plus a returns note. It is front-loaded with the core purpose, but the added 'see list_bundles' note is tangential and could be omitted.

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

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

The tool is simple with three parameters and an output schema (not shown but mentioned). The description partially explains return fields, but lacks differentiation from the very similar sibling 'calculate_number_base_convert', and does not cover edge cases or expected input examples.

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 for all three parameters. The description does not add any extra meaning beyond the schema, such as expected string format for 'value' or base ranges, which are already in the schema constraints.

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 numbers between bases 2-36, listing common bases. However, it does not distinguish itself from the sibling tool 'calculate_number_base_convert', which likely serves a similar purpose.

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

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

No guidance on when to use this tool vs alternatives such as 'calculate_number_base_convert'. The only note is to 'see list_bundles', which is generic and not specific to this tool.

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

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

No annotations are present, so the description must convey behavioral traits. It describes the output fields (load_kN_per_m, max_moment_kNm, max_shear_kN, note) and the input parameters implicitly. For a calculation tool, this is sufficient as it has no side effects or destructive actions. The description does not contradict any annotations (none exist).

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: two sentences. The first sentence encapsulates the tool's purpose and output format. The second provides a pointer to related tools. No fluff or 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?

Given that an output schema exists and the input schema fully describes parameters, the description is largely complete. It mentions the output fields and references related tools. A slight gap is that it could clarify that the load input is in kg/m for clarity, but the schema already states that.

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

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

The input schema has 100% description coverage, with each parameter having a clear description (e.g., 'Beam span in meters'). The tool description does not add additional parameter semantics beyond what the schema provides. A score of 3 is appropriate as the schema already handles parameter documentation.

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

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

The description clearly states the tool's purpose: 'Calculate max bending moment and shear for a beam under uniform distributed load.' It specifies the resource (beam) and the specific calculations. The sibling guidance ('See list_bundles for related construction calculators') further distinguishes it from other calculate_* 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 mentions related calculators via 'See list_bundles for related construction calculators', which implies a grouping but does not explicitly state when to use this tool versus others. No conditions or alternatives are provided, leaving the agent to infer usage context.

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

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

No annotations exist, so description carries full burden. It discloses return structure and implies a read-only computation. Does not mention authentication or rate limits, but for a simple calculation tool, the disclosure 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: first states purpose and output, second references related tool. No fluff, information is front-loaded.

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

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

Given no explicit output schema, the description covers return values. Lacks edge cases or default behavior details, but for a straightforward calculation tool with 3 parameters, it is largely 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. Description adds no additional semantics beyond the schema's field descriptions. Does not explain formulas or relationships between 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 it calculates Belgian benefit-in-kind for company car, specifying the calculator and listing return fields. The name and description align, and it is distinct among many sibling 'calculate' tools.

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

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

Provides minimal guidance: mentions related 'finance-belgique' calculators via list_bundles. No explicit when-to-use or when-not-to-use, but the tool's specialized nature makes usage somewhat obvious.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as whether the tool is read-only, destructive, or requires authentication. It only mentions returned values.

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

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

The description is two sentences with no wasted words. The key action and context are front-loaded. It efficiently communicates purpose and provides a cross-reference.

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?

Even though an output schema exists, the description omits critical information: the region parameter that is mentioned is not in the schema, causing incompleteness. Additionally, no guidance on prerequisites or edge cases is provided.

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 description mentions 'region' as an input, but the schema does not include a region parameter. This is misleading and contradicts the schema. The description does not add helpful semantic meaning beyond the schema; instead, it introduces confusion.

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 'Compute Belgian donation tax (droits de donation) by region', using a specific verb and resource. It distinguishes itself from numerous Belgian tax siblings by focusing specifically on donation tax.

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

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

The description advises 'Use for estate planning in Belgium', providing clear context. It also recommends 'See list_bundles for related calculators', guiding the agent to an alternative for related tools.

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

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

No annotations are provided. The description does not disclose behavioral traits such as idempotency, safety, or side effects. As a calculator, it likely is read-only, but this is not stated.

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 purpose, brackets year, and output fields; second directs to related tools. No fluff, 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?

The tool is simple with one parameter. The description covers purpose and output, but lacks usage guidelines and behavioral transparency. It is adequate for basic invocation.

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

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

Schema coverage is 100%, and the schema already describes the parameter as 'Annual taxable income in euros'. The description adds no extra meaning beyond that, so the baseline of 3 applies.

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

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

The description clearly states the tool calculates Belgian personal income tax using 2026 progressive brackets, and specifies the output fields. This distinguishes it from other tax tools, though it doesn't explicitly contrast with siblings like calculate_belgian_salary.

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

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

No explicit guidance on when to use this tool versus alternatives. The mention of list_bundles is a weak hint but does not provide exclusion criteria or conditions.

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

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

With no annotations, the description carries full burden. It states the tool returns a monthly pension estimate but does not disclose assumptions, accuracy limitations, or any side effects. It does not mention that the tool is a safe read operation or if any data is saved. Lacks behavioral detail expected for a financial estimation tool.

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

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

The description is concise at 4 sentences, front-loading the purpose and listing inputs. It is well-structured without extraneous information. The only minor issue is the parameter mismatch which could have been clarified.

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 an output schema exists (not shown but indicated), the description does not need to detail the return format. However, it omits explaining the impact of the household_type parameter (e.g., single rate vs household rate) which is important for users. The pointer to related calculators is helpful 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%, so the descriptions in the schema already document each parameter. The description adds 'status (employee/self-employed)' which does not match the schema's 'household_type' (single/household). This adds some value by implying a real-world concept but introduces confusion due to mismatch. Overall, marginal additional meaning.

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

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

The description clearly states the tool estimates Belgian retirement pension, lists inputs (career years, average salary, status), and mentions output. However, it inaccurately describes the third parameter as 'status' (employee/self-employed) whereas the schema uses 'household_type' with enum values single/household. This minor mismatch slightly reduces clarity.

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

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

The description says 'Use for retirement planning in Belgium' which implies its context. It does not provide explicit when-to-use or when-not-to-use guidance, nor distinguishes from the many sibling calculation tools. The mention of 'list_bundles' is a vague pointer to related calculators but no direct 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 no annotations, the description carries the burden. It discloses the approximation nature and partially lists outputs, but does not cover all behavioral aspects like performance, resource consumption, or full output structure. The '...' indicates incompleteness.

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 sentences front-load the main purpose and efficiently cover output hints and sibling reference. 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 complexity of salary calculations and lack of an output schema (only referenced), the description is incomplete. It lists some output fields but ends with '...' and does not explain each component. Adequate but leaves gaps 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% for the single parameter. The description adds no additional semantic value beyond restating the parameter's role. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: converting Belgian gross monthly salary to net salary. It specifies the input and lists output fields. It distinguishes from siblings by referencing a related bundle, but could better differentiate from very similar tools like calculate_belgian_income_tax.

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

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

No explicit guidance on when to use this tool versus alternatives. The mention of 'See list_bundles for related calculators' hints at grouping but does not provide clear decision rules 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?

With no annotations provided, the description compensates by detailing the return structure (fields and tiers). However, it does not disclose side effects, auth requirements, or rate limits, though the nature of the tool suggests read-only calculation.

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

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

The description is two sentences, front-loaded with the main action and return structure, and ends with a reference to related tools. 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?

Given the simple single-parameter input and explicit return fields listed, the description is largely complete. It references a bundle for related tools, but could briefly mention prerequisites or typical usage scenarios.

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

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

The schema already provides a clear description for the single parameter 'annual_income'. The description adds context by explaining the calculation's purpose and tiers but does not add significant semantics 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 action 'Calculate' and the specific resource 'Belgian self-employed social contributions (cotisations INASTI)'. It mentions the return fields and references a related bundle, distinguishing it from sibling tools.

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

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

The description implies usage for Belgian self-employed social contributions but does not explicitly state when to use it versus other calculators. It only hints at related tools via 'See list_bundles', lacking clear exclusion or alternative guidance.

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

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

With no annotations, the description carries the full burden. It mentions conversion between HT and TTC and the return object, but does not disclose any behavioral traits such as precision, edge cases, or that this is a standard deterministic calculation. The return format is redundant if an output schema 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?

The description is two sentences, front-loaded with purpose and return fields. No unnecessary words; every sentence adds value.

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

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

Given the tool's simplicity and complete schema coverage, the description is adequate but lacks usage guidelines and behavioral transparency. With an output schema present, the return object mention is redundant, but overall it covers the basics.

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 adds minimal extra meaning beyond the schema (e.g., hints at mode via 'convert between HT and TTC'), but no further detail on parameter constraints or usage.

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 Belgian VAT and converts between HT and TTC. It names the specific operation and return fields, distinguishing it from other VAT calculators through the explicit 'Belgian' qualifier.

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

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

No guidance is provided on when to use this tool versus sibling VAT calculators (e.g., calculate_french_vat, calculate_vat_generic). The only hint is a reference to list_bundles for related tools, but no explicit when-to-use or when-not-to-use information.

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

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

No annotations are provided, so the description carries the full burden. It discloses that it returns 3 cycle values (-100 to +100) and zone, but does not mention side effects, authorization needs, or determinism. For a calculation tool, this is adequate but could be more explicit about its 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 three sentences, each serving a clear purpose: stating the computation, providing audience context, and listing inputs/outputs. It is front-loaded and contains no filler, making it highly concise and well-structured.

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

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

Given the tool has an output schema (context signal), the description adequately covers purpose, inputs, and output summary. It references list_bundles for related tools, which adds completeness. Slight deduction for not mentioning additional context like typical use cases or limitations beyond pseudoscience.

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% as both parameters have descriptions in the schema. The description merely restates 'Inputs: birth date, target date.' without adding further meaning, validation, or format details. Baseline 3 is appropriate since schema already provides sufficient semantics.

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

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

The description clearly states the tool computes physical, emotional, and intellectual biorhythm cycles. It uses a specific verb 'Compute' and resource 'biorhythm cycles', and distinguishes it from sibling tools by labeling it as pseudoscience for self-tracking enthusiasts, hinting at list_bundles for related fun 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 explicitly says 'Use for self-tracking enthusiasts (pseudoscience)', which provides clear context for when to use this tool. It suggests seeing list_bundles for related calculators, offering an alternative. However, it does not explicitly state when not to use it or exclude other scenarios.

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

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

No annotations provided. Description only mentions formula and output format, but does not disclose behavioral traits like safety, privacy, or destructiveness.

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 covering purpose and output, no unnecessary information. Could be slightly more structured but very 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?

Adequate for a simple calculator with full schema coverage and output schema presence, but lacks mention of prerequisites or 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?

Schema coverage 100% with descriptions for all parameters. Description adds no additional parameter semantics 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?

Specifically states estimation of blood alcohol content using Widmark formula, clearly identifying the verb, resource, and method.

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?

Implied usage for estimating BAC but lacks explicit when-to-use vs alternatives. Mentions related calculators but does not guide selection.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, safety, or statelessness. The agent cannot infer whether this is a pure calculation or has side effects.

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

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

The description is concise (one sentence plus a useful reference) and front-loaded with the action. It earns its place without 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?

For a simple 2-param tool with output schema, the description covers the basic purpose and output (BMI and weight category). It is adequate but minimal, lacking any behavioral context due to missing annotations.

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

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

Schema descriptions already cover the parameters (height_cm, weight_kg) with min values. The tool description adds no extra parameter context but leverages the output schema implicitly. Baseline 3 given 100% 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 BMI and weight category, providing specific verb and resource. However, it does not explicitly differentiate from similar siblings like calculate_body_fat or calculate_bmr, relying only on a reference to list_bundles.

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

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

No guidance on when to use this tool vs alternatives. The reference to list_bundles hints at related calculators but does not give explicit exclusions or usage context.

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

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

No annotations provided, so description must disclose behavioral traits. It reveals the calculation method (Mifflin-St Jeor) and return format ({bmr_kcal}), which is transparent for a deterministic computation. However, it omits details like error handling or assumptions beyond input schema.

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

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

Two sentences with zero waste: first states purpose and equation, second provides return format and a pointer to related tools. 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?

Given the tool's simplicity (compute BMR) and the presence of an output schema, the description is complete. It covers purpose, method, and output, and references related calculators for further context.

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

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

Schema coverage is 100% with all parameters documented. Description adds no new meaning to parameters beyond what the schema already provides, meeting the baseline for high 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?

Description clearly states 'Calculate Basal Metabolic Rate using Mifflin-St Jeor equation', specifying the verb, resource, and formula. It distinguishes from sibling calculators by naming the exact equation and referencing related 'sante' calculators.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., calculate_tdee). The mention of list_bundles implied context but lacks direct differentiation or 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?

No annotations provided, so the description carries the burden. It mentions the equation and return value but doesn't disclose that the tool is read-only or any side effects. For a simple calculation, this is adequate but not exceptional.

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 states the purpose, second mentions the return format and related tools. No wasted words; properly 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?

Given the low complexity and existence of an output schema, the description is sufficient. It names the equation and return key. However, it does not explain the output schema structure (but that's the schema's job).

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 each parameter already has a clear description. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Estimate') and resource ('body fat percentage'), and distinguishes from the sibling 'calculate_body_fat_navy' by naming the Deurenberg equation. The result format is also mentioned.

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 clearly states the inputs (BMI, age, sex) and points to related tools via 'list_bundles'. It implicitly differentiates from the Navy method, but could be more explicit about when not to use this tool.

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

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

No annotations are provided, so the description must fully address behavioral traits. It lacks details on assumptions (e.g., accurate measurement needed), output format, or that the tool is read-only. The description only states the method, omitting any 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 very concise with two sentences, no fluff. However, the structure could be improved by front-loading the method more clearly and possibly adding a sentence about tool usage context. Still, it is efficient for its length.

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 (health-related calculation with multiple inputs), the description is adequate but lacks mention of output details, accuracy, or prerequisites. The presence of an output schema helps, but the description does not leverage it. There is no annotation to fill gaps, so completeness is moderate.

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% parameter descriptions, so the schema already documents each parameter. The tool description adds no additional parameter guidance 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 the tool calculates body fat percentage using the US Navy circumference method. The verb 'calculate' and resource 'body fat percentage' are explicit. While it names the specific method, it does not explicitly differentiate from sibling tools like 'calculate_body_fat' or 'calculate_bmi'.

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

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

No guidance on when to use this tool versus alternatives. The suggestion to 'see list_bundles for related calculators' is vague and does not provide clear context for selection. No conditions or exclusions are 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?

With no annotations provided, the description carries the full burden. It states the conversion function but does not mention safety (read-only), authentication needs, or error cases. For a simple calculation, this is acceptable but not fully transparent.

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

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

The description is two sentences with no wasted words: first sentence states purpose, second sentence points to related tools. Perfectly concise 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?

Given the complexity of a simple conversion tool with an output schema, the description is mostly complete. It lacks behavioral context due to missing annotations but covers the core functionality and relationship to other 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 description coverage is 100% and both parameters have clear descriptions in the schema. The tool description adds no new meaning beyond 'for different note values', which is already implied. Baseline 3 is appropriate.

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

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

The description clearly specifies the verb 'Convert' and the resource 'BPM tempo to millisecond delay times for different note values'. It differentiates from siblings by referencing related 'musique' calculators via list_bundles.

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 directs users to list_bundles for related calculators, implying when to find alternatives. However, it does not explicitly state when to use this tool over others or when not to use it.

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

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

Without annotations, the description carries the full burden. It clearly indicates the tool computes reaction and braking distance and returns total stopping distance. However, it does not disclose assumptions, limitations, or potential errors, but for a calculator, the behavioral disclosure is adequate.

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

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

The description is concise with three sentences and front-loads the purpose. However, the inaccuracy regarding inputs detracts from its effectiveness. The structure is adequate but compromised by the error.

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 claims inputs that are not in the schema, making it incomplete for correct usage. While it mentions the output and refers to list_bundles, the critical error in parameter description leaves gaps in understanding what the tool actually requires.

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 description mentions 'reaction time s' as an input, but the input schema does not include a reaction_time parameter. This misrepresents the parameter set and could mislead the agent. Despite 100% schema coverage, the description adds incorrect information, severely undermining parameter semantics.

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

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

The description clearly states the tool computes reaction and braking distance based on road condition, with specific inputs (speed, road condition) and output (total stopping distance). The mention of driver safety education provides context, and the reference to list_bundles for related calculators helps differentiate from the many 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 suggests use for driver safety education but does not explicitly state when to use this tool over alternatives. The reference to list_bundles hints at related calculators but lacks clear guidance on when not to use this tool or what alternatives exist.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions inputs and outputs but contradicts the schema by including 'wheel diameter mm' as an input, which is not an actual parameter. This inconsistency reduces transparency.

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

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

The description is concise and front-loaded with the core purpose. The reference to list_bundles is slightly extraneous but does not detract significantly. However, the misleading input mention is a flaw.

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 completeness due to the erroneous input reference and does not cover all necessary context, such as the exact output format beyond 'ratio and meters per pedal turn'. With an output schema presumably present, the description should align accurately.

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

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

Although schema coverage is 100% with descriptions for both parameters, the description adds 'wheel diameter mm' as an input that is not in the schema, which is misleading. The description does not enhance meaning beyond the schema and introduces confusion.

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

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

The description clearly states the tool computes cycling gear ratio and development per pedal turn, with a specific use case for road cycling. However, it does not distinguish from similar sibling tools like calculate_gear_ratio or calculate_velo_development, which could cause confusion.

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

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

The description specifies 'Use for road cycling gear analysis', providing clear context. It does not include when not to use or explicit alternatives, though it references list_bundles for related calculators, which is minimal guidance.

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

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

No annotations are provided, so the description carries the full burden. It states the tool calculates bra size from measurements, which is a simple computation with no side effects. It does not disclose any additional behavioral traits such as edge case handling or precision, but for a calculator tool this is adequate.

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

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

The description is two sentences long, front-loading the purpose and input/output format. The second sentence provides a pointer to related tools. Every sentence adds value with no redundancy.

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

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

Given the low complexity (three parameters, simple calculation), the description is fully complete. It explains what the tool does, the required inputs, the system options, and the return format. The output schema is effectively described inline, and a reference to related tools is provided.

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

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

The schema has 0% description coverage, so the description must compensate. It specifies that measurements are in cm and lists the system options (FR/US/UK), adding meaning beyond the schema's raw field names and constraints. However, it does not provide details on decimal handling or acceptable ranges beyond the schema's 'exclusiveMinimum'.

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 bra size in FR, US, or UK systems from underbust and bust measurements in cm, and specifies the return format. It references 'list_bundles' for related calculators, but does not explicitly differentiate from 'calculate_bra_size_convert', which is a sibling.

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 minimal guidance on when to use this tool. It mentions 'See list_bundles for related textile-mode calculators' but does not explicitly state when to choose this tool over alternatives like 'calculate_bra_size_convert' or other specific 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?

With no annotations, the description must disclose behavioral traits. It specifies the return format ({FR, US, UK, EU}) implying a read-only conversion, but lacks details on error handling, edge cases, or any computational assumptions.

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 core purpose and output, then directing to related resources. Every sentence is useful and there is no redundancy.

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

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

For a simple conversion tool with complete schema and output schema, the description adequately covers inputs, outputs, and related tools. Minor omission: return type structure is implied but not formally specified.

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 adds no additional meaning beyond the schema; it merely repeats the system names already present in the enum.

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

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

Description clearly states the verb 'Convert' and resource 'bra size' between systems, and mentions the return format. However, it does not directly differentiate from sibling 'calculate_bra_size' which may be a related but distinct 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?

Description suggests seeing list_bundles for related calculators but provides no explicit guidance on when to use this tool versus alternatives like calculate_clothing_size_convert or calculate_shoe_size_convert.

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

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

No annotations are present, so the description carries the full burden. It discloses return values (hydration % and dough type) and implies no side effects via 'compute', but does not explicitly state read-only nature or 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?

Two concise sentences: first defines purpose and formula, second lists inputs and outputs with a pointer to related tools. No extraneous words; every sentence is valuable.

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 and an existing output schema (not shown but implied), the description covers the essential computation and return types. A minor gap is no explanation of dough type categories, but likely covered by output schema.

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

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

Schema coverage is 100% with descriptions already explaining the parameters (flour and water grams). The description ('Inputs: flour g, water g') adds minimal new meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool computes baker's hydration percentage using the formula water/flour×100, specifies its use for bread recipe analysis, and distinguishes from siblings by referencing related cuisine calculators via list_bundles.

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 provides a clear use case ('bread recipe analysis') and indirectly guides to alternatives by mentioning list_bundles for related calculators, but lacks explicit when-not-to-use or exclusionary guidance.

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

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

No annotations are provided, so the description carries full burden. It states the outputs (break-even units and revenue) but does not disclose potential limitations, edge case behavior, or any side effects. For a computation tool, it is minimally informative.

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 and output, and ends with a related bundle reference. No wasted words or unnecessary details.

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

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

Given the tool's simplicity and the existence of an output schema, the description covers the essential purpose, inputs, and outputs. However, it lacks details on edge cases (e.g., zero or negative profit scenarios) which could affect interpretation.

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 reiterates the inputs in text, adding little meaning beyond what the schema already provides. It does not explain how parameters relate to the calculation.

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

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

The description clearly states it computes break-even point in units and revenue, with a specific business context (business plans and pricing decisions). It references a related bundle for similar calculators, which slightly differentiates siblings, though not explicitly.

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 provides a use case ('Use for business plans and pricing decisions') but lacks explicit when-not-to-use guidance or alternative tools. The mention of list_bundles is a weak alternative reference.

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

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

No annotations are provided, so the description carries full burden. It states the tool returns due date and gestation milestones. However, it does not disclose date constraints (e.g., mating date must be in past), whether any side effects occur (likely none), or how unsupported species are handled. The species list inconsistency could confuse agents about valid inputs.

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

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

The description is concise at 24 words and front-loads the purpose. It has a clear structure: purpose, target user, inputs, outputs, and reference to related tools. Almost no wasted words. Could be slightly improved 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 the tool's simplicity and presence of an output schema, the description adequately covers the core functionality. However, it does not mention date validation, optional behavior, or handle the species discrepancy. It references list_bundles for related tools, which is good. Overall adequate but with gaps.

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

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

Schema description coverage is 0%, so the description must add meaning. It lists the two inputs: species and mating date, and mentions acceptable species values (though with error). It explains their roles but omits format for mating date (schema provides pattern) and constraints. Provides basic semantics but incomplete.

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

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

The description clearly states the tool's purpose: compute due date for animal breeding given mating date and species. It uses specific verbs and resources. However, there is a discrepancy: the description lists species including horse and cow, but the schema enum only includes dog, cat, rabbit, hamster. This inconsistency slightly undermines clarity.

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

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

The description only says 'Use for breeders,' which is minimal. No guidance on when to use this tool versus the numerous species-specific siblings like calculate_dog_pregnancy or calculate_cat_pregnancy. No when-not-to-use or alternatives are provided. The reference to list_bundles is vague.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns total points and mention, but lacks details on side effects, authentication, rate limits, or error handling. For a stateless calculation tool, this is adequate but not exemplary.

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 primary purpose. Every sentence adds value: purpose, usage suggestion, and pointer to related tools. 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?

For a calculation tool with 6 parameters and an output schema (mentioned but not shown), the description covers the basics: inputs, purpose, and return type. It could expand on calculation logic or edge cases, but it is sufficient for typical use.

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

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

Schema coverage is 100%, so the input schema already documents all parameters with descriptions. The description adds a general statement about inputs but does not provide additional semantics beyond what the schema offers. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool estimates French Brevet (DNB) scores from grades and continuous-control marks, specifying the educational context (collège students). It distinguishes itself from siblings like calculate_bac_points by mentioning 'education' calculators and referencing list_bundles.

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 guidance ('Use for collège students forecasting their result') and directs users to list_bundles for related calculators. However, it does not explicitly exclude alternative tools like calculate_bac_points or specify when not to use this tool.

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

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

With no annotations, the description carries full burden; it clearly states the tool computes and returns results, implying read-only behavior with no side effects, meeting transparency needs.

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

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

The description is short and front-loaded with purpose, but the listing of inputs that don't match the schema reduces clarity; overall 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?

Output schema exists and description mentions return values, but it omits details like default waste margin and how brick type affects sizing, leaving gaps for a complete understanding.

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

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

Schema coverage is 100% with clear descriptions, so baseline is 3, but the description mentions 'brick size' and 'waste %' as inputs, which are not in the schema, causing confusion and detracting from value added.

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

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

The description clearly states it computes bricks or blocks for a wall including waste margin, and directs to list_bundles for related calculators, distinguishing it from numerous sibling tools.

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

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

The description specifies 'Use for masonry projects' and suggests seeing list_bundles for other construction calculators, providing context but not explicit exclusions or alternative tool names.

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?

Describes inputs and output (buoyant force and float/sink verdict) but does not disclose additional behavioral traits like side effects or limits. Since annotations are absent, the description carries the burden and is adequate but not exhaustive.

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

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

Three concise sentences with no superfluous words. Front-loaded with purpose and 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?

Given the tool's simplicity and the presence of an output schema, the description sufficiently explains inputs, output, and usage context. Also references a related bundle for completeness.

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

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

Schema coverage is 100% with descriptions for all parameters. The description summarizes inputs but adds no significant meaning beyond the schema. Meets baseline.

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

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

Clearly states it computes buoyancy force, displaced volume, or floating analysis using Archimedes principle, specifying domains physics or shipping. Distinguishes from other calculate_ 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?

Suggests usage for physics or shipping and references list_bundles for related science calculators. Lacks explicit when-not-to-use or alternatives but provides 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?

No annotations are provided, so the description carries full burden. It states the tool computes and returns values (burn, runway, profitability date), implying read-only behavior. However, it does not explicitly declare it as non-destructive or safe, which is important for a tool with no 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, with two sentences and a line listing inputs/outputs. It is front-loaded with the main action. Slightly more structure (e.g., separating inputs/outputs) could improve readability.

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

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

For a simple calculator with an output schema, the description covers purpose, inputs, and outputs adequately. It does not explain edge cases (e.g., negative cash balance) but is sufficient for typical use.

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

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

Schema covers all three parameters (cash_balance, monthly_revenue, monthly_expenses) with descriptions, achieving 100% coverage. The description restates inputs but adds minimal new information. The mention of return values (burn, runway, profitability date) is helpful 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's function: 'Compute startup monthly burn rate and runway.' It specifies the verb 'compute,' the resource 'burn rate and runway,' and provides usage context ('Use for fundraising or expense control'). It distinguishes from siblings by referencing related calculators via list_bundles.

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 use cases ('fundraising or expense control') and lists inputs. However, it lacks explicit when-not-to-use guidance or alternative tools. The mention of list_bundles for related calculators offers some context.

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

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

No annotations are provided, so the description bears the burden. It mentions the NF C 15-100 standard, adding regulatory context, but does not disclose assumptions (e.g., copper vs aluminum, temperature) or the exact calculation method. The return value is simply 'required section' without further detail.

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

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

The description is brief with two main sentences plus a reference. It front-loads the core purpose. However, the unit mismatch and minor repetition reduce clarity slightly.

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 an output schema exists, the description need not detail return values but only says 'Returns required section.' It references list_bundles for related tools but lacks deeper context on calculation prerequisites or edge cases. Completeness is adequate for a straightforward 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 description coverage is 100% with parameter descriptions. The tool description lists inputs but misstates power_w as 'power kW' when the schema expects watts (W). This inconsistency could confuse the agent. The description adds little meaning beyond the schema entries.

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

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

The description clearly states the tool computes electrical cable cross-section in mm² per the NF C 15-100 standard, for residential wiring. This specific verb and resource with a recognized standard distinguishes it from sibling tools like 'calculate_cable_section_electrical' that may not specify the standard.

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

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

The description advises using for residential wiring and references list_bundles for related calculators, but does not explicitly state when not to use it or mention alternatives. The context (French standard) implies scope 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?

No annotations are provided, so the description carries the full burden. It discloses the return structure but fails to mention important behavioral details such as assumptions (single-phase vs three-phase, AC/DC, cable material, temperature), side effects, or required permissions. This leaves significant gaps in understanding the tool's behavior.

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

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

The description is extremely concise with only two sentences. It front-loads the primary action and includes the return structure. However, the pointer to list_bundles adds a minor detour. Overall, it earns its keep with minimal waste.

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

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

Given the complexity of electrical calculations, the description lacks critical context about assumptions (e.g., cable type, system configuration) and limitations. It does not mention output schema details beyond a brief tuple. For a tool with many siblings, more context is needed to ensure correct 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%, so the schema already describes all parameters with types, defaults, and descriptions. The description adds no additional semantic information about the parameters beyond what is in the schema, so baseline score 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 cable section from power, voltage, distance, and voltage drop. It distinguishes from siblings by mentioning it's a 'science' calculator and referencing list_bundles, but could be more explicit on what makes it unique among many 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 provides no guidance on when to use this tool versus alternatives. The mention of list_bundles for related calculators is vague and doesn't help an agent decide when to use this specific tool.

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

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

With no annotations provided, the description carries full burden. It states it computes ratio and returns ratio and health verdict, which is transparent. No hidden side effects are implied. The behavioral traits are adequately disclosed for a simple calculation tool.

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

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

The description is extremely concise with three sentences covering purpose, usage context, and related tools. Every sentence carries value with no redundancy or fluff.

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

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

Given the presence of an output schema (implied by 'Has output schema: true'), the description need not detail return values but still mentions 'ratio and health verdict'. It provides useful context like SaaS unit economics and target ratio. Minor missing details (e.g., parameter constraints) are already covered by the schema.

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

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

Schema description coverage is 100% with both parameters (cac, ltv) already described in the schema. The description simply reiterates 'Inputs: total CAC, LTV' without adding new semantic details beyond the schema, meeting the baseline expectation.

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 'Compute Customer Acquisition Cost vs Lifetime Value ratio', a specific verb+resource. It adds context for SaaS unit economics and provides a target benchmark (≥3.0), distinguishing it from the many sibling calculator tools.

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

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

The description explicitly says 'Use for SaaS unit economics analysis' and even provides a target ratio. It directs to list_bundles for related finance calculators, offering a pathway to alternative tools. However, it does not explicitly state when not to use, but the context 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?

With no annotations, the description carries full burden. It discloses the 5-hour half-life, inputs (mg, hours), and outputs (remaining mg, clearance forecast). This is sufficient for a non-destructive calculator, though lacks details on accuracy 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?

Three sentences: function, use case, inputs/outputs, related tools. No fluff, every sentence adds value. Well 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?

Given the existence of an output schema and 100% schema coverage, the description is fairly complete. It identifies inputs and outputs and points to related calculators. It could elaborate on 'clearance forecast' but likely covered in output schema.

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

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

Schema coverage is 100%, so baseline 3. The description restates parameters ('caffeine mg, time since intake') but adds no new meaning beyond the schema's descriptions. It does contextualize the purpose but not the parameters themselves.

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

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

The description clearly states the tool computes remaining caffeine over time using a 5-hour half-life, which is a specific verb+resource. It distinguishes itself from siblings like calculate_caffeine_half_life by focusing on clearance computation for sleep planning.

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

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

The description explicitly says 'Use for sleep planning,' providing a clear use case. It also directs users to related 'sante' calculators via list_bundles, though it does not explicitly exclude other scenarios or compare with direct siblings.

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

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

With no annotations, the description should disclose behavioral traits. It states the calculation and return fields but does not mention that it is a safe, read-only operation or any assumptions (e.g., standard half-life). Basic transparency but missing details.

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

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

Two sentences, no fluff. Front-loaded with action and returns, then a pointer to related tools. Every sentence adds value.

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

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

The description covers purpose and output format. Given no annotations and no output schema provided (though context says it exists), it is adequate for a simple calculator. Could mention the underlying model (e.g., standard half-life of 5 hours) but not critical.

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 (mg_consumed, hours_since). The description adds return field context but does not enhance parameter meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states 'Calculate remaining caffeine in body after time elapsed' and specifies return fields (hours_to_below_25mg, safe_to_sleep). It distinguishes from a large set of sibling calculators by its specific topic and hints at categorization ('sante' calculators via list_bundles).

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 a health context by referencing 'sante' calculators but does not explicitly state when to use this tool versus alternatives or any prerequisites. No guidance on when not to use it.

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

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

No annotations are provided, so the description must carry the burden. It describes the output (total mg, % of limit, time-of-day distribution) but lacks details about prerequisites, side effects, or data storage. It implies a non-destructive calculation but is not thorough.

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 with no fluff. It front-loads the purpose, then gives usage, inputs/outputs, and a referral. Every sentence adds value.

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

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

Given the presence of an output schema (not shown), the description need not detail return values, but it introduces 'time-of-day distribution' which is not supported by the input schema (no time field). It also lacks clarity on units. These gaps reduce completeness.

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