macalc

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

Discloses specific calculation method (Epley formula) and output scope (1RM-to-12RM range), but with no annotations provided, fails to mention safety profile, error conditions, or output format 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?

Single efficient sentence with zero waste. Core purpose, method, and output scope presented upfront with no redundant information.

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

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

Appropriate for simple 2-parameter calculation tool. Describes inputs (implied via 'known lift'), method, and output. Lacking output schema but description compensates by detailing table contents.

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% providing full param documentation. Description adds 'from a known lift' context implying real performance data, but does not substantially elaborate param syntax or formats beyond schema 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?

Description uses specific verb 'Generate' with clear resource '1RM-to-12RM repetition table' and distinguishes from sibling calculate_one_rep_max by emphasizing 'full...table' (range output) versus single value calculation.

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

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

Provides implied usage through output description (generates full table), but lacks explicit when-to-use guidance or explicit contrast with calculate_one_rep_max alternative.

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

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

No annotations provided, so description carries full burden. It discloses the return format ('hours and minutes') but omits critical behavioral details like whether minutes overflow into hours (e.g., 90 minutes → 1h30), return data structure, 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?

Single 11-word sentence with zero waste. Front-loaded with action verb, immediately clear what the tool does and returns.

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 4-parameter input with complete schema coverage, the description is nearly sufficient. However, without an output schema, it should specify the exact return structure (object fields, string format) and normalization behavior to fully compensate.

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

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

Schema description coverage is 100% with clear descriptions ('First duration — hours', etc.). Description implies parameter pairing (hours1+minutes1 as first duration) but adds no syntax, formatting, or constraint details beyond the schema. Baseline 3 appropriate for high schema coverage.

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

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

States specific verb 'Add' and resource 'time durations', plus output format 'hours and minutes'. The specificity distinguishes it from sibling tools like calculate_time_difference (subtraction) and convert_time (conversion).

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/when-not guidance or named alternatives provided. Usage must be inferred from the description and tool name. Given the extensive list of calculation siblings, explicit guidance on when to prefer this over calculate_time_difference or convert_time would help.

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

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

With no annotations provided, the description carries the full burden. It discloses the output structure (years, months, days) which compensates partially for the missing output schema, but omits details about date validation, timezone handling, or behavior with future dates.

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

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

The description is a single, efficient sentence of 11 words with zero waste. The core action and output format are front-loaded immediately.

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

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

For a simple single-parameter calculation tool, the description is reasonably complete. It specifies the output format to compensate for the missing output schema. However, it could be improved by mentioning edge case handling (e.g., future dates) or timezone 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 is 100% with the 'birth_date' parameter fully documented in the schema. The description references 'birth date' which aligns with the parameter, but adds no additional semantic information about format requirements or validation beyond what the schema already provides.

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

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

The description uses a specific verb ('Calculate') and clearly identifies the resource ('age') and expected output format ('years, months and days'). However, it does not explicitly distinguish from the sibling tool 'calculate_age_in_units', leaving ambiguity about which tool to select when.

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 like 'calculate_age_in_units' or other date-related tools. There are no stated prerequisites, exclusions, or conditions for use.

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

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

No annotations provided, so description carries full burden. Fails to disclose what 'multiple units' specifically means (e.g., years/months/days vs. other units) or describe the return format/structure. Does not mention idempotency or calculation precision limits.

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 sentence, front-loaded with verb and object. No redundant phrases or filler content. Appropriate length for a single-parameter calculation tool.

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

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

Adequate for a simple one-parameter tool without output schema, but lacks specificity about return values (what units are calculated). Given the tool's simplicity and 100% schema coverage, the description is minimally sufficient but could be improved with output format details.

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 ('Birth date YYYY-MM-DD'). Description mentions 'from birth date' which aligns with the parameter, but adds no semantic meaning, validation rules, or format guidance beyond what the schema already provides. Baseline 3 appropriate for complete 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?

States specific action (Calculate) and resource (age) with scope (in multiple units from birth date). Mentions 'multiple units' which implicitly distinguishes from sibling 'calculate_age', but does not explicitly clarify what units are returned (years, months, days, etc.) or when to choose this over the simpler age calculator.

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 no guidance on when to use this tool versus the sibling 'calculate_age' or other date-related tools. No mention of prerequisites or input format requirements beyond the schema.

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 the comparison behavior (against UK limit) beyond pure calculation, but omits the actual limit value (14 units), return format details, and 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?

Single efficient sentence (10 words) with zero waste. Purpose is front-loaded and immediately 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?

Adequate for a single-parameter calculation tool without output schema. Description sufficiently indicates domain (UK units) but could clarify what the comparison returns (boolean, percentage, or raw count vs limit).

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. Description mentions 'drinks' which maps to the parameter name, but fails to compensate by explaining the required drink object structure (volume_ml, abv_pct, type) or the enum values expected.

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?

Specific verb (Calculate), specific resource (alcohol units), and specific jurisdiction (UK weekly limit) clearly distinguishes from sibling tools like calculate_blood_alcohol which computes BAC for driving safety rather than UK public health units.

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 UK health context via 'UK weekly limit' but lacks explicit when-to-use guidance (e.g., health tracking vs driving safety) and does not explicitly reference sibling calculate_blood_alcohol as the alternative for impairment estimation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool generates recommendations/assessments but fails to disclose output format, whether results include medical disclaimers, or if calculations are based on standard physiological models. No contradictions with absent annotations.

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

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

The description is a single, efficient sentence of nine words with the core purpose front-loaded. There is no redundant information; every word serves to define the tool's dual function (risk assessment + recommendation generation).

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 single simple parameter with complete schema documentation and no output schema, the description adequately covers necessary context. However, for a health-related tool, it could benefit from mentioning the nature of the output (risk categories, timeline recommendations) or accuracy limitations.

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 ('Target altitude in meters'), the schema fully documents the single parameter. The description adds no additional parameter guidance (e.g., typical acclimatization altitudes, why 8850m is the max), warranting the baseline score of 3.

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

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

The description uses specific verbs ('Assess', 'recommend') and clearly identifies the resource (altitude sickness risk, acclimatization schedule). It implicitly distinguishes from sibling 'calculate_baking_altitude' by focusing on health/medical outcomes rather than cooking adjustments, though it doesn't explicitly name the 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 implicit usage guidance through domain-specific terminology ('altitude sickness', 'acclimatization'), making it clear this is for mountaineering/health contexts. However, it lacks explicit when-to-use criteria, prerequisites, or warnings about when medical professional consultation is needed instead.

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 disclosure burden but only states the conversion capability. It omits behavioral details such as precision constraints, handling of negative angles, zero values, or whether the operation is idempotent.

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

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

The description is a single, efficient sentence of nine words with the action verb front-loaded. Every word serves a purpose, specifying both the operation and the complete set of supported units without redundancy.

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

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

Given the tool's simplicity and complete input schema, the description is minimally adequate for invocation. However, with no output schema and no annotations, the absence of any description of the return value (converted angle) leaves a minor gap in contextual completeness.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description reinforces the schema by listing the specific enum values (degrees, radians, gradians, turns) but does not add semantic depth regarding parameter relationships or validation logic.

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

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

The description uses a specific verb ('Convert') with a clear resource ('angles') and enumerates the exact supported units (degrees, radians, gradians, turns). However, it does not differentiate from sibling tool 'convert_angle', leaving ambiguity about which tool to prefer for angle conversions.

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, particularly the sibling 'convert_angle' tool. There are no mentioned prerequisites, exclusions, or contextual triggers for selection.

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

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

No annotations are provided, yet the description discloses minimal behavioral information. It does not specify the calculation formula (PMT/annuity formula), rounding behavior, currency handling, or that it returns a monetary value versus a schedule. The description implies a single output value but does not confirm this.

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 single sentence is efficient and front-loaded with the action verb. However, given the lack of annotations and output schema, extreme brevity here constitutes under-specification rather than optimal conciseness—it could accommodate additional context without becoming verbose.

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 three-parameter calculation tool with complete schema coverage but no annotations or output schema, the description meets minimum viability by identifying the calculation type. However, it lacks behavioral specifics (rounding, currency assumptions) and sibling differentiation that would make it complete for an agent selecting among many 'calculate_' 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?

With 100% schema description coverage (principal, rate, and periods all have descriptions), the schema carries the semantic load. The description adds no parameter-specific context beyond what the schema already provides (e.g., it doesn't clarify the rate period or compounding assumptions), warranting the baseline score.

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

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

The description uses a specific verb ('Calculate') and clearly identifies the resource (periodic payment amount for loans/annuities). However, it fails to distinguish from the sibling tool 'calculate_loan_payment', leaving ambiguity about which tool to use for standard loan calculations versus annuity-specific calculations.

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

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

The description provides no guidance on when to prefer this tool over siblings like 'calculate_loan_payment' or 'calculate_mortgage', nor does it mention prerequisites or expected contexts (e.g., amortizing loans). Users must infer applicability from the parameter names alone.

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

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

With no annotations, the description carries the full disclosure burden. It successfully adds two critical behavioral traits: 'AI-powered' (indicating probabilistic/natural language processing vs deterministic calculation) and 'Requires premium subscription' (auth/billing constraint). However, it omits other relevant behaviors like read-only nature, output format (text vs number), or rate limits.

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

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

Two sentences, zero waste. First sentence front-loads purpose and sibling differentiation; second sentence adds critical constraint (premium). Every word earns its place—'Universal' signals scope, 'AI-powered' signals mechanism, specialized tools reference signals fallback role.

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 (universal fallback to 200+ specialized tools), the description adequately establishes its role and constraints. With full schema coverage and no output schema, it appropriately leaves return value documentation implicit. Missing only minor details like output format (natural language explanation vs raw value).

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

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

Schema has 100% description coverage with explicit natural language and context documentation. Description adds minimal semantic value beyond the schema, though 'AI-powered' reinforces the natural language input expectation for the 'query' parameter. Baseline 3 appropriate given comprehensive 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?

Excellent specificity: 'Universal AI-powered calculator' defines the tool's function and mechanism, while 'handles any calculation not covered by specialized tools' explicitly distinguishes it from 200+ deterministic siblings. Clear verb (handles) + resource (calculation) + scope 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?

Provides clear selection criteria via 'not covered by specialized tools,' establishing it as the fallback option. However, lacks explicit 'when NOT to use' guidance (e.g., prefer deterministic siblings when available) and doesn't name specific alternatives, though this is impractical given the sibling volume.

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 disclosure burden. It usefully indicates the tool computes both 'gross' and 'net' volumes (implying substrate displacement) and 'stocking capacity' (fish population limits), but fails to explain how stocking capacity is calculated, what units are returned, or whether it assumes freshwater vs. saltwater.

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 single sentence is front-loaded and efficient, but with four undocumented parameters and no output schema, the six-word description is undersized for the tool's complexity. It needs additional sentences explaining parameters and return format.

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 zero schema descriptions, no annotations, and no output schema, the description provides the minimum viable context by identifying the three key outputs (gross volume, net volume, stocking capacity). However, it lacks critical details like measurement units, the relationship between 'substrate_cm' and net volume, and the methodology for calculating stocking capacity.

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%, requiring the description to compensate. While 'gross/net volume' implicitly explains the 'substrate_cm' parameter (used to calculate net volume), the description mentions no parameters by name or their physical meaning (e.g., that dimensions are in centimeters), leaving all four parameters effectively undocumented.

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 ('Calculate') and resource ('aquarium'), and distinguishes from generic siblings like 'calculate_volume' by specifying domain-specific outputs: 'gross/net volume' and 'stocking capacity'. However, it doesn't explicitly differentiate from 'calculate_fish_tank_heater' or 'calculate_pool_volume' which appear in the sibling list.

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

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

Provides no guidance on when to use this tool versus alternatives like 'calculate_volume' (generic) or 'calculate_pool_volume'. No prerequisites or contextual triggers 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?

No annotations provided, so description carries full disclosure burden. Fails to mention units (output is square units of input), precision handling, or the conditional parameter logic required by different shapes.

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 efficient sentence with no redundancy. However, given the tool's complexity (10 parameters with shape-dependent requirements), the brevity may underserve the user rather than demonstrate conciseness.

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

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

Inadequate for tool complexity. With 10 parameters and conditional logic based on the 'shape' enum, the description should explain the parameter mapping (which fields apply to which shapes). No output schema compounds the gap.

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

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

Schema has 100% description coverage, establishing baseline of 3. Description adds no additional semantics about conditional requirements (e.g., that 'circle' requires 'radius' while 'rectangle' requires 'width'/'height'), but schema adequately documents individual fields.

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?

States specific action (calculate) and resource (area of geometric shapes). Distinguishes broadly from siblings like 'calculate_volume' and 'calculate_perimeter', though it doesn't clarify relationship to specific-shape calculators like 'calculate_ellipse'.

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 no guidance on when to use this general-purpose tool versus specific alternatives (e.g., 'calculate_ellipse'), nor does it indicate which parameter combinations are required for each shape type.

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 calculation outputs (net income and social charges) but omits other behavioral traits like whether this is a simulation vs. official filing, rate limits, or authentication requirements. It meets minimum disclosure for a calculation tool but lacks richness.

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, efficient sentence with no waste. Front-loaded with the key action ('Calculate'), domain ('French auto-entrepreneur'), and outputs ('net income and social charges'). Every word earns its place.

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

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

For a simple 2-parameter tool without output schema, the description adequately covers scope by naming the expected outputs (net income and social charges). It could improve by clarifying this is an estimation/simulation tool, but sufficiently covers the tool's functionality given its low complexity.

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

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

With 100% schema description coverage (revenue and category both well-documented in the schema), the baseline is 3. The description provides domain context ('French auto-entrepreneur') that frames the parameters but does not add additional semantic details beyond the schema definitions.

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 ('Calculate') and explicitly identifies the resource ('French auto-entrepreneur/micro-enterprise net income and social charges'). It clearly distinguishes from siblings like 'calculate_french_income_tax' or 'calculate_portage_salarial' by specifying the unique 'auto-entrepreneur' regime.

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 by specifying the French auto-entrepreneur regime, signaling when to select it (for micro-enterprise calculations). However, it lacks explicit contrasts with alternatives like 'calculate_french_income_tax' or 'calculate_portage_salarial' that handle different employment statuses.

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 but discloses nothing about input validation (e.g., weights/values length matching), how the calculation mode is determined, or the return value format. The claim of supporting 'geometric mean' without explaining how to request it creates behavioral opacity.

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 brief (5 words) and front-loaded with the core action. While efficient, it may be underspecified given the behavioral ambiguity around geometric mean calculation—every word earns its place, but the place needs more 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 two-parameter statistical utility without output schema, the description minimally covers the basic function. However, given the 'geometric mean' ambiguity and lack of error-handling documentation, it falls short of fully equipping an agent to invoke the tool correctly in all claimed 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?

Schema description coverage is 100% ('Array of numbers' and 'Optional weights'), establishing baseline 3. The description adds the terminology 'simple, weighted, or geometric' but fails to explain parameter interactions (e.g., that weights array must match values length) or how geometric calculation is triggered.

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 states the tool calculates means (simple, weighted, geometric), providing specific verbs and resource types. However, it fails to clarify how the user selects between these three modes given the schema only contains 'values' and 'weights' parameters with no enum or 'type' selector, creating ambiguity about invocation.

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 generic tool versus sibling alternatives like 'calculate_statistics' or domain-specific calculators. There are no 'when-not' exclusions or prerequisites mentioned despite hundreds of specialized calculation siblings existing.

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. Only behavioral hint is 'estimation,' implying it's a projection, not an official result. Missing: return value format (weighted total? out of 100?), calculation methodology, and whether this is a pure computation or stores data. For a 7-parameter mutation/calculation tool with no annotations, this is insufficient disclosure.

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

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

Extremely brief at 5 words, front-loaded with the action verb. No wasted text. However, given the complexity (7 required parameters, domain-specific knowledge), it may be overly terse rather than appropriately 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?

Despite rich input schema, the tool lacks output schema and the description fails to explain what the calculation returns (final weighted score out of 100? pass/fail threshold? mentions?). For a domain-specific calculation with no output schema, the description should specify the return value format and calculation basis.

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 excellent inline documentation (scales like /20, coefficients like coeff 10, and percentages like 40%). Description adds no parameter semantics beyond the schema. Baseline 3 is appropriate when the schema fully documents all 7 required 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?

Clear verb (Calculate) + specific resource (French Baccalaureat score) + scope (estimation). Distinguishes from siblings like `calculate_brevet_points` (middle school) and `calculate_parcoursup_points` (university admission) by naming the specific diploma. Could be improved by clarifying this is for the French secondary school leaving certificate.

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 generic calculators like `calculate_grade_average` or `calculate_average`. Does not mention prerequisite requirements (needing all exam scores) or that it should be used after final exams.

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 of behavioral disclosure. It states the tool 'adjusts' recipes but fails to specify what the adjustment entails (e.g., return format like modified ingredient amounts vs. multipliers, text instructions vs. structured data) or whether the operation is idempotent.

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

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

The single sentence is terse with no wasted words, achieving brevity. However, given the lack of annotations and output schema, the description is arguably under-sized rather than optimally concise—it front-loads the core purpose but leaves critical behavioral gaps.

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 5 required parameters, no annotations, and no output schema, the description fails to specify what the tool returns (e.g., adjusted ingredient quantities, temperature modifications, or textual guidance), leaving a significant gap in the agent's ability to predict tool behavior.

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

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

Input schema has 100% description coverage ('Altitude in meters', 'Flour in cups', etc.), establishing a baseline score of 3. The tool description adds only general context ('baking recipe') which is already implicit in the parameter names, without elaborating on units, valid ranges, 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?

The description provides a clear verb ('Adjust'), resource ('baking recipe'), and specific context ('high altitude cooking') that distinguishes it from generic conversion tools. However, it does not explicitly differentiate from similar siblings like 'calculate_baking_conversion' or 'calculate_recipe_scaling'.

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 (e.g., when altitude thresholds are met), nor does it mention prerequisites or expected use cases beyond the high-altitude context implied in the name.

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 of behavioral disclosure. It fails to mention whether the operation is read-only, the return format (since no output schema exists), precision of conversions, or error handling for unsupported ingredients.

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 single sentence is appropriately sized with zero waste. It is front-loaded with the action verb and contains no redundant information.

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

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

Given the low complexity (2 simple parameters) and clear naming, the description is minimally viable. However, with no output schema and no annotations, it lacks information about the return value and behavioral guarantees that would make it 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?

With 0% schema description coverage, the description partially compensates by adding semantic context: 'cups to grams' implies the quantity_cups parameter's unit and purpose, and 'common baking ingredients' hints at the ingredient parameter's domain. However, it does not clarify the specific enum values or that quantity_cups must be positive.

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 states a specific action (Convert), specific units (cups to grams), and domain (baking ingredients). It effectively distinguishes this from general cooking conversion siblings like 'calculate_cooking_conversion' by specifying 'baking ingredients,' though it does not explicitly name 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 no guidance on when to use this tool versus alternatives like 'calculate_cooking_conversion' or 'convert_cooking', nor does it mention prerequisites or constraints beyond the implicit domain.

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 disclosure burden. It mentions the valid base range (2-36), which adds useful constraint context beyond the raw schema. However, it lacks details on error handling (e.g., invalid digits for a given base), output format/return type, or whether the result includes prefixes (like '0x').

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

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

The description is a single, efficient sentence that front-loads the action ('Convert') and uses a parenthetical to provide examples and constraints without waste. Every word earns its place.

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

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

For a focused mathematical utility with a simple 3-parameter schema and no output schema, the description covers the essential functional scope (base range 2-36) and typical use cases. While it could mention string format requirements for hex digits (A-Z), the schema already indicates the value is a string, making this acceptable.

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

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

While the schema has 100% coverage describing the parameters technically, the description adds semantic value by providing concrete examples of common bases (binary=2, octal=8, etc.), helping the agent understand what integer values to pass for typical use cases.

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 and lists specific examples (binary, octal, decimal, hexadecimal) plus the valid range (2-36). However, it does not differentiate from the sibling tool 'calculate_number_base_convert', which could cause selection 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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or constraints beyond the base range. The existence of 'calculate_number_base_convert' as a sibling makes this lack of differentiation problematic.

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 of disclosure. It successfully identifies what physical values are computed (bending moment and shear), but omits critical behavioral details such as output units (kNm?), return format structure, read-only safety confirmation, or error handling 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?

Extremely efficient at 11 words with zero redundancy. Front-loaded with the action verb 'Calculate' followed immediately by the specific outputs and subject. Every word earns its place; no restructuring needed.

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 flat schema (3 parameters, no nesting) and absence of output schema, the description adequately covers the calculation purpose but leaves gaps regarding the return value structure and units. Sufficient for tool selection but minimal for result 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%, establishing a baseline of 3. The description adds contextual meaning by referencing 'uniform distributed load' (aligning with load_kg_per_m) and 'beam' (aligning with span_m and beam_type), but does not extend beyond the schema's documentation with additional semantic constraints or format details.

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

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

The description clearly specifies the action (Calculate), the outputs (max bending moment and shear), and the context (beam under uniform distributed load). It effectively distinguishes this structural engineering tool from the many other calculate_* siblings by specifying the specific physics calculations performed.

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 (e.g., calculate_roof_truss), nor does it mention prerequisites such as required units or structural assumptions. It states only what the tool does, not when to invoke it.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Calculate' implies a read-only operation, the description omits critical details such as the output format (monthly vs annual amount), calculation methodology reference, potential error conditions, or whether results are stored. It fails to disclose what the agent receives upon invocation.

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

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

Single sentence with zero waste. Information is front-loaded with the action verb, followed by specific domain identifiers (Belgian, benefit-in-kind, company car), plus clarifying local terminology in parentheses. Every element earns its place.

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

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

While the input schema is fully documented, the tool lacks an output schema and the description fails to explain the calculation result (e.g., monetary amount, taxable base). Given the complexity of Belgian tax regulations, the description should ideally reference the calculation standard or return value interpretation, constituting a notable gap despite adequate parameter coverage.

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

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

Input schema has 100% description coverage (CO2 emissions, catalog value HTVA, fuel type), establishing baseline 3. The description itself adds no parameter-specific semantics, but the complete schema renders additional elaboration unnecessary. The French tax term 'HTVA' in the schema description is helpful context.

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

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

The description clearly specifies the action (Calculate), jurisdiction (Belgian), tax concept (benefit-in-kind), and asset type (company car). The French translation '(avantage de toute nature voiture)' reinforces local specificity, effectively distinguishing it from siblings like 'calculate_belgian_income_tax' or 'calculate_car_depreciation'.

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 explicit guidance on when to use this tool versus alternatives (e.g., 'calculate_belgian_salary' for general income), nor does it mention prerequisites such as requiring catalog value and CO2 data. Usage must be inferred solely from the tool name and parameter schema.

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 disclosure burden. It successfully communicates regional specificity (Wallonia rates) but omits whether the tool performs pure calculation (read-only) or has side effects, and fails to describe the output format or structure despite lacking an output 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?

Extremely efficient single-line description with zero redundancy. The French translation 'droits de donation' and Wallonia qualifier earn their place. However, extreme brevity comes at the cost of omitting critical context like output format, preventing a perfect score.

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 tax calculation tool with no output schema and no annotations, the description is incomplete. It fails to specify what the tool returns (tax amount due? rate tables? deductions?), omits regional applicability warnings, and provides no guidance on the legal context of Belgian donation taxes.

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

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

Input schema has 100% description coverage with clear definitions for 'amount' and 'relationship'. The description adds no semantic clarification beyond the schema, meeting the baseline for high-coverage schemas.

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 provides a specific verb (Calculate), resource (Belgian donation tax/droits de donation), and geographic scope (Wallonia rates), distinguishing it from sibling tools like calculate_belgian_income_tax. However, it assumes user knowledge of what 'donation tax' entails without clarifying it refers to gift/inheritance transfer taxes.

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

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

While 'Wallonia rates' implies geographic limitation, the description explicitly states neither when to prefer this over other regional calculators nor mentions that it specifically excludes Flanders and Brussels rates. No alternative tools are named for other Belgian regions.

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 full burden. It adds valuable calculation context by specifying '2026 progressive brackets' (revealing year-specific methodology), but lacks safety disclosure (read-only status, determinism), return format, or rate limit information despite being a 'calculate' operation.

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 efficient sentence with zero waste, front-loaded with action verb 'Calculate', includes localization (Belgian), specific tax nomenclature (IPP/PB), and temporal scope (2026) without redundancy.

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

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

For a single-parameter calculation tool with full schema coverage, the description is appropriately complete. Mentioning the 2026 tax year is crucial contextual information for tax calculations. Minor gap: no mention of return value format despite absent 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 has 100% coverage providing baseline 3. The description adds meaningful temporal context by specifying '2026', which constrains the applicability of the income parameter to the 2026 tax year—information not present in the schema but critical for correct 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?

Description uses specific verb 'Calculate' with clear resource 'Belgian personal income tax', distinguishes from siblings via country specificity ('Belgian'), tax type ('IPP/PB'), and year ('2026'), clearly differentiating from other country's income tax tools and other Belgian calculators like VAT or social contributions.

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 no guidance on when to use this specific tool versus related siblings like calculate_belgian_salary or calculate_belgian_social_contributions, nor does it indicate prerequisites or when to prefer this over other tax 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 provided, so description carries full burden. Only behavioral hint is 'Estimate,' implying approximation. Missing: specific pension regimes covered (employee vs. self-employed), calculation methodology, output format, and whether results are gross or net.

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

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

Extremely concise (7 words) with no filler. However, given zero annotations and no output schema, the brevity leaves significant gaps in contextual information. Front-loaded but perhaps insufficiently descriptive for the domain complexity.

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

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

Identifies the calculation domain adequately given good parameter schema coverage. However, lacks explanation of output values, relationship to other retirement tools, and specific Belgian pension rules (e.g., 45-year maximum career implication). Minimum viable for a specialized 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 clear descriptions for all three parameters including the enum values and their percentage rates (60%/75%). Description adds no parameter-specific context, but baseline 3 is appropriate given complete schema 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?

Clear verb ('Estimate') and specific resource ('Belgian statutory pension'). The parenthetical French term '(pension legale)' adds local context. Distinguishes from generic pension calculators via 'Belgian' domain specifier, though it doesn't explicitly differentiate from sibling 'calculate_retirement_pension'.

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 no guidance on when to use this tool versus other pension/retirement calculators, or prerequisites such as requiring Belgian employment history. No mention of complementary tools or alternatives.

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

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

No annotations provided, so description carries full burden. It discloses '(approximation)' which is valuable behavioral context, but lacks details on which deductions are modeled (social security, taxes, etc.), applicable tax year, or output format/structure.

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

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

Single, efficient sentence with zero waste. Information is front-loaded with the action ('Convert'), followed by domain specifics, and closes with the important caveat ('approximation').

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 single-parameter conversion tool. The description covers input (gross), output (net), domain (Belgian), and quality (approximation). Minor gap: absent output schema means return structure (number vs object) is unspecified, though 'net salary' implies the value.

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

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

Schema has 100% description coverage ('Gross monthly salary in euros'). Description mentions 'gross monthly salary' which aligns with the parameter name, but adds no additional semantic detail (e.g., acceptable ranges, examples, or validation rules) 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?

Excellent specificity: 'Convert' is a clear verb, 'Belgian gross monthly salary to net salary' identifies the exact resource and transformation, and 'Belgian' distinguishes it from calculate_french_salary/calculate_swiss_salary while 'gross to net' distinguishes it from calculate_belgian_income_tax (which is tax-specific).

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

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

No guidance provided on when to use this versus sibling tools like calculate_belgian_income_tax, calculate_belgian_social_contributions, or calculate_salary_hourly_to_annual. Given the crowded calculate_* namespace, explicit context would help 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, so the description carries the full burden of behavioral disclosure, yet it only states the calculation purpose without mentioning output format, calculation methodology, or whether results are estimates. The mention of 'INASTI' provides institutional context but fails to disclose behavioral traits like determinism or data freshness.

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

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

The description consists of a single efficient sentence with seven words that front-loads the core purpose. Every word earns its place with no redundant phrases or tautology, achieving maximum information density.

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 single-parameter calculation tool with full schema coverage and no output schema, the description adequately identifies the calculation domain and target population. However, it lacks mention of the output format or calculation year applicability, which would be helpful given the complexity of social contribution rules.

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 'Annual net professional income in euros' already explaining the single parameter thoroughly. The description does not add semantic details beyond the schema, such as how 'net professional income' is specifically defined for Belgian self-employment.

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 the specific verb 'Calculate' and precisely identifies the resource as 'Belgian self-employed social contributions (cotisations INASTI)'. The mention of INASTI specifically targets the Belgian social security institution for self-employed workers, effectively distinguishing it from siblings like calculate_belgian_salary and 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?

The description provides no explicit guidance on when to select this tool versus alternatives such as calculate_belgian_salary for employees. While 'self-employed' implies a specific user category, there is no explicit comparison to sibling tools or guidance on prerequisites.

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

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

No annotations provided, so description bears full burden. It explains the bidirectional conversion logic (HT↔TTC) but fails to disclose output format, whether calculation includes rounding rules specific to Belgian VAT, or safety properties (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?

Extremely concise two-clause description with zero redundancy. Purpose front-loaded with 'Calculate', mechanism specified with 'convert between HT and TTC', and no extraneous information.

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

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

Adequate for a simple 3-parameter calculation tool with complete schema coverage. However, lacks output specification (does it return VAT amount, gross/net values, or rate details?) given no output schema exists to cover this gap.

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

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

Schema coverage is 100% with complete enum descriptions ('ht=before tax', etc.). Description adds context that the tool 'convert[s] between HT and TTC', framing the mode parameter's purpose, but doesn't add syntax details beyond the schema's existing 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?

Clear specific verbs ('Calculate', 'convert') and resource ('Belgian VAT') with geographic specifier 'Belgian' distinguishing it from sibling VAT tools (french_vat, uk_vat, vat_generic). Lacks explicit comparison to alternatives.

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 specific Belgian calculator versus generic alternatives like calculate_vat_generic or calculate_vat_reverse. No mention of prerequisites 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to indicate whether this is a read-only operation, what format the results return in, whether calculations are stored, or any rate limiting concerns. The single sentence provides only the operation intent with no 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 exactly one sentence and seven words long. It is front-loaded with the action and subject, contains zero redundancy or filler, and every word serves to define the tool's specific purpose.

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

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

Given the tool has only two well-documented parameters and no output schema, the description is minimally adequate for an AI to select the tool for biorhythm calculations. However, gaps remain: it does not describe the output format, value ranges (e.g., -100% to +100%), or criticality of the date parameters, which would be expected given the lack of annotations or 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?

With 100% schema description coverage, the input parameters (birth_date, target_date) are already well-documented in the schema itself. The description adds no additional semantic context about the parameters (e.g., explaining that birth_date is the reference point for cycle calculation), so it meets the baseline score for high schema coverage.

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

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

The description provides a specific verb ('Calculate') and resource ('biorhythm cycles') and clarifies the scope by listing the three specific cycle types (physical, emotional, intellectual). This distinguishes it sufficiently from other date-based calculation siblings like calculate_age or calculate_moon_phase, though it does not explicitly name alternatives.

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 other date calculation tools, nor does it mention prerequisites (e.g., needing valid dates) or expected use cases. It merely states the function without context for selection.

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

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

No annotations provided, so description carries full burden. Mentions 'Widmark formula' providing method context and 'Estimate' indicating approximation nature, but lacks disclosure of output format (percentage units), safety disclaimers, or read-only nature that annotations would typically cover.

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

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

Extremely efficient 7-word sentence. Every element earns its place: action (Estimate), subject (BAC), and specific method (Widmark formula). Zero waste, 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 100% schema coverage and simple input structure, description adequately supports tool selection. However, for a health/legal-adjacent calculation (BAC), it lacks expected disclaimers about individual metabolic variations and legal limits that would make it complete.

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

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

Schema description coverage is 100% with clear parameter descriptions (e.g., '1 drink = 14g pure alcohol'), establishing baseline 3. Description adds implicit context via 'Widmark formula' (explains why sex/weight matter) but does not explicitly elaborate parameter semantics 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?

Specific verb 'Estimate' plus resource 'blood alcohol content (BAC)' and distinguishes from siblings via 'Widmark formula', which identifies the specific pharmacological method used versus generic calculation tools like calculate_alcohol_units 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?

Implies usage through specificity of the Widmark formula (medical/scientific BAC estimation) but provides no explicit when-to-use guidance comparing it to siblings like calculate_bac_points or calculate_alcohol_units.

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 mentions 'weight category' as an output hint (useful given no output schema exists), but fails to disclose the calculation method (kg/m²), return value format, or limitations (e.g., athletic builds, pregnancy).

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 front-loaded sentence with zero waste. Every word earns its place—immediately states the action (Calculate) and scope (BMI + weight category).

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 two-parameter calculation tool with well-documented inputs. However, lacking an output schema, the description could be improved by specifying what 'weight category' entails (underweight/normal/overweight/obese classifications) or that it returns a numeric BMI value.

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

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

Schema description coverage is 100% ('Height in centimeters', 'Weight in kilograms'), so the baseline per rubric is 3. The description adds no additional parameter context beyond what the schema provides.

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

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

The description uses a specific verb ('Calculate') and resource ('Body Mass Index'), clearly identifying the tool's function. While it doesn't explicitly differentiate from sibling health calculators (e.g., calculate_body_fat, calculate_bmr), BMI is sufficiently distinct in purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives like calculate_body_fat or calculate_ideal_weight, nor does it mention prerequisites (e.g., adult vs. pediatric BMI calculation limitations).

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

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

No annotations provided, so description carries full burden. It discloses the specific equation used (Mifflin-St Jeor) but omits output format, units (presumably kcal/day), or validation details beyond the schema constraints.

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

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

Single sentence, front-loaded with all essential information. No filler words or redundant phrases. Every token earns its place.

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

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

Adequate for a simple 4-parameter calculation tool, but lacks output documentation (no output schema exists). Should mention return value format/units given no output schema is present.

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% (all 4 parameters documented), establishing baseline 3. Description adds no parameter-specific guidance (e.g., why biological sex matters for BMR), but high schema coverage makes this acceptable.

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 uses specific verb 'Calculate' with specific resource 'Basal Metabolic Rate' and specifies the exact method 'Mifflin-St Jeor equation'. This clearly distinguishes it from siblings like calculate_bmi or calculate_tdee.

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 no guidance on when to use BMR vs. TDEE (calculate_tdee) or calories burned (calculate_calories_burned). No prerequisites or exclusions mentioned despite many related metabolic calculation 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 provided, the description carries the full burden. It appropriately qualifies the result as an 'estimate' and names the specific equation used, but omits output format details, value ranges, 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?

The single 12-word sentence is perfectly front-loaded with zero waste. Every word earns its place by conveying the operation, inputs, and specific methodology used.

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 three-parameter calculation tool with complete schema documentation, the description is largely adequate. It implies the output is a body fat percentage, though it could explicitly state the return format (number vs object) given the absence of an 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 description coverage is 100%, establishing a baseline of 3. The description merely lists the parameter categories (BMI, age, sex) without adding semantic context, constraints, or relationships beyond what the schema already provides.

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

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

The description provides a specific verb (Estimate), clear resource (body fat percentage), and uniquely identifies the methodology (Deurenberg equation), which effectively distinguishes this tool from the sibling `calculate_body_fat_navy`.

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?

While the description implies usage by naming the Deurenberg method, providing a hint for selection between this and the Navy method sibling, it offers no explicit when-to-use guidance or comparison of the two methodologies.

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 of behavioral disclosure. It specifies the calculation methodology but fails to disclose side effects (none expected), output format/return value structure, or what occurs with edge cases (e.g., measurements below minimums which the schema enforces but description doesn't discuss).

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 sentence with zero waste. The specific method name is front-loaded and every word earns its place by defining scope and algorithm.

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 implies the return value (body fat percentage) but does not specify units, precision, or format given the absence of an output schema. With 100% input schema coverage, the input side is well-documented, but the output side remains underspecified.

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%, establishing a baseline of 3. The description earns an additional point by providing the unifying methodological context (US Navy circumference) that explains why these specific anatomical measurements are required together, adding semantic coherence beyond individual parameter definitions.

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 identifies the specific verb (Calculate), resource (body fat percentage), and methodology (US Navy circumference method). However, it does not explicitly differentiate from the sibling tool `calculate_body_fat`, leaving ambiguity about which method to choose.

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 specific Navy method versus alternatives like `calculate_body_fat`, nor does it mention prerequisites (e.g., needing a tape measure) or measurement timing.

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 disclosure burden. It specifies output is milliseconds and implies a pure calculation, but omits safety profile (read-only vs destructive), precision/rounding behavior, or whether it validates the note_value against the BPM range.

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 efficient sentence with zero waste. Noun phrase structure ('Convert X to Y for Z') frontloads the operation, inputs, and outputs immediately.

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 2-parameter calculation tool, but gaps remain: no output schema exists, yet description doesn't explicitly state the return format (milliseconds as number vs object) or whether it returns values for all note values or just the requested one.

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 ('Tempo in beats per minute', 'Musical note value'). The description mentions 'different note values' which maps to the enum but adds minimal semantic value beyond what the schema already provides. Baseline 3 is appropriate.

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

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

Clear verb ('Convert') and specific domain (BPM tempo to millisecond delay times, note values). Effectively distinguishes from unrelated siblings (tax, BMI calculators), though could explicitly signal audio/music context to differentiate from calculate_reverb_predelay.

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 no guidance on when to use this versus alternatives like calculate_reverb_predelay or calculate_time_signature_beats, nor prerequisites for the calculation.

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 zero annotations, the description carries the full disclosure burden but fails to specify output format (total distance vs. breakdown?), units (meters?), underlying physics assumptions (reaction time duration, friction coefficients per condition), or calculation standard used. 'Reaction + braking' hints at components but lacks behavioral specifics needed for safe automotive application.

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

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

Extremely concise at 5 words with no redundancy. However, extreme brevity becomes a liability here—every sentence earns its place, but the single phrase leaves critical gaps that another sentence could fill (output units, reaction time assumption).

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?

Severely incomplete given no output schema and no annotations. A physics-based safety tool should disclose output structure, units (meters/feet?), and assumptions about driver reaction time (industry standard 1.5s-2s). Without this context, agents cannot reliably interpret results or explain limitations.

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 ('Speed km/h', 'Road'), establishing baseline 3. The description adds minimal semantic value beyond the schema—mentioning 'by road condition' confirms the parameter affects output but doesn't explain the physical mapping (dry/wet/icy friction coefficients) or that reaction distance depends on speed.

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 'Reaction + braking distance by road condition' clearly identifies the calculation domain (physics-based stopping distance) and key variable (road condition). In the context of 200+ sibling calculators, this sufficiently distinguishes the specific automotive safety calculation performed.

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 provided on when to select this tool versus siblings like calculate_speed_distance_time or calculate_distance_securite. No mention of prerequisites, input validation limits, or safety-critical usage context required for braking calculations.

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 disclosure burden. Mentions 'speed at various cadences' which hints at output behavior (multiple calculations per cadence step), but lacks details on default cadence values, units, or whether wheel size assumptions are used. No safety annotations but implies 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?

Single efficient sentence (9 words) with zero waste. Purpose front-loaded immediately. Parenthetical '(braquet)' efficiently clarifies terminology without verbosity.

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

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

Adequate for a 2-parameter calculation tool. Mentions 'speed at various cadences' which partially compensates for missing output schema by hinting at return structure. However, lacks specifics on what 'various' means (range/step) and omits unit information.

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

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

Input schema has 100% description coverage ('Number of teeth...'), establishing clear baseline. Description mentions 'gear ratio' which contextualizes the parameters but doesn't add syntax, validation rules, or domain constraints beyond schema.

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

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

States specific verb (Calculate) and resource (bicycle gear ratio, 'braquet'), including the French cycling term helps identify the domain. However, fails to distinguish from sibling tool 'calculate_gear_ratio' which likely performs similar calculations.

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

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

No guidance provided on when to use this versus 'calculate_gear_ratio', 'calculate_cycling_power', or other related cycling calculators. No prerequisites or exclusions mentioned despite many sibling 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, so description carries full burden. It does not disclose the output format, possible error conditions (e.g., invalid measurement ratios), whether the operation idempotent, or any side effects. With no output schema and no annotations, the lack of behavioral disclosure is a significant 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?

Single sentence, front-loaded with action verb, no redundancy. Every element serves a purpose: verb, resource, valid systems, and input requirements.

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 moderate complexity (3 parameters, specific domain), the description covers inputs and sizing systems adequately. However, with no output schema and no annotations, it omits expected details like result format. Sibling differentiation is implied but not explicit.

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

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

Schema description coverage is 0%, requiring the description to compensate. It mentions all three parameters conceptually ('underbust', 'bust', 'system') and adds the unit '(cm)' which confirms the measurement unit. However, it does not explain semantic distinctions (e.g., difference between underbust and bust) or valid value ranges beyond what's in the schema structure.

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?

States specific verb 'Calculate', resource 'bra size', and scope 'FR, US or UK system'. Mentions inputs 'underbust and bust measurements (cm)' which distinguishes it from the sibling tool 'calculate_bra_size_convert' by implying calculation from raw body measurements rather than conversion between size notations, though it does not explicitly name the 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?

Provides no explicit guidance on when to use this tool versus alternatives, particularly the sibling 'calculate_bra_size_convert'. Lacks prerequisites or conditions (e.g., that measurements should be in centimeters, implied only by parameter names and parenthetical).

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 disclosure burden. It specifies the four supported sizing systems (FR, US, UK, EU) defining the operational scope. However, it fails to clarify what the tool returns—particularly important since the input schema lacks a 'to_system' parameter, leaving ambiguity whether it converts to all systems or a specific target.

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 sentence of appropriate length with the action verb front-loaded. No redundant or wasteful language; every word conveys essential scope or function.

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

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

Adequate for a simple 3-parameter conversion tool with complete schema documentation. However, lacks description of return values (no output schema exists) and does not address the missing 'to_system' parameter behavior.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds minimal semantics beyond the schema, merely listing the sizing systems (FR, US, UK, EU) that are already defined in the from_system enum. It does not clarify parameter relationships (e.g., that band_size must correspond to the from_system).

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 states a specific action (Convert) and resource (bra size) with clear scope (FR, US, UK, EU systems). However, it does not explicitly differentiate from sibling tool 'calculate_bra_size' (which likely calculates from measurements rather than converting between systems).

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 no guidance on when to use this tool versus 'calculate_bra_size' or general 'calculate_clothing_size_convert'. No mention of prerequisites (e.g., knowing source size) or output expectations.

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 and description discloses no behavioral traits. Does not indicate this is a safe read-only calculation, what return format to expect (e.g., float representing percentage), or that it follows the standard baker's percentage formula (water weight / flour weight × 100).

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 sentence, front-loaded with action verb. Extremely efficient with no wasted words, though borders on under-specification. Appropriate length for a simple two-parameter calculation tool.

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

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

Adequate for a simple calculation with complete schema coverage, but lacks output description (critical since no output schema exists) and calculation methodology explanation that would help an agent predict results or validate inputs.

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

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

Input schema has 100% description coverage ('Flour weight grams', 'Water weight grams'), providing complete parameter documentation. Description adds no semantic meaning beyond what schema already provides, warranting baseline score.

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

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

Clear verb (Calculate) and resource (bread dough hydration percentage). Distinguishes from sibling 'calculate_hydration' by specifying 'bread dough', though could clarify that hydration here refers to baker's percentage (water/flour ratio).

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 provided on when to use this versus generic 'calculate_hydration' or 'calculate_baking_conversion', or when baker's percentage calculation is appropriate versus other hydration metrics.

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

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

Given no annotations, description carries full burden. It discloses outputs (units and revenue) but omits computational behavior (e.g., handling when price_per_unit equals variable_cost_per_unit), error conditions, or safety characteristics.

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

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

Extremely efficient at 6 words. Front-loaded with action verb. Parenthetical output specification is high-value density. Only deduction is extreme brevity given lack of annotations leaves behavioral gaps.

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 straightforward 3-parameter calculation tool with complete schema documentation. However, with no output schema and no annotations, description should ideally explain the break-even formula concept or business logic 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 description coverage is 100% ('Total fixed costs', 'Selling price per unit', 'Variable cost per unit'), establishing baseline of 3. Description adds no semantic detail beyond schema, but doesn't need to compensate for coverage gaps.

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 ('Calculate') and resource ('break-even point'), with specific output clarification ('units and revenue') that distinguishes it from generic calculation tools. Avoids tautology despite name similarity by specifying return values.

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 versus siblings like calculate_profit_margin, calculate_roi, or calculate_markup_margin. Given 200+ calculate_* siblings, explicit differentiation or business context is needed.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what gestation periods are used for each animal, whether calculations are estimates, error handling behavior, or side effects. The phrase 'Calculate' implies a read-only operation but this is not explicit.

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

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

The description is a single, efficient sentence of nine words that front-loads the action ('Calculate') and contains no redundant or wasted language. Every word serves to identify the function.

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

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

The description mentions the expected output (birth date) which partially compensates for the missing output schema. However, with no annotations, no output schema, and 0% input schema coverage, the description fails to fully document parameter formats, valid values, or behavioral constraints expected for a breeding calculation tool.

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

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

With 0% schema description coverage, the description must compensate by documenting the two parameters. It references 'mating date' and 'common pets' (animals) matching the schema parameters, but fails to specify the required YYYY-MM-DD date format or the complete list of supported animals (dog, cat, rabbit, hamster) beyond the vague 'common pets'.

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 an expected birth date from a mating date for common pets, providing a specific verb, resource, and scope. However, it fails to explicitly distinguish from siblings like 'calculate_dog_pregnancy', 'calculate_cat_pregnancy', or 'calculate_pregnancy_due_date' which appear to offer overlapping functionality.

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 the more specific pregnancy calculators (calculate_dog_pregnancy, calculate_cat_pregnancy) or the generic calculate_pregnancy_due_date. There is no mention of prerequisites or conditions for selection.

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

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

No annotations provided, so description carries full burden of behavioral disclosure. Description lacks information about output format (points vs grade), calculation methodology (weighting, coefficients), or error conditions beyond schema validation.

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 7-word sentence is maximally concise and front-loaded. However, extreme brevity leaves gaps in behavioral and contextual disclosure for a specialized domain tool.

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

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

For a 6-parameter specialized calculation tool with no annotations or output schema, the description is insufficient. It omits what the calculation returns (total points, final grade, pass/fail status) and lacks domain context about the French Brevet scoring system.

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 with clear parameter semantics (e.g., 'Math exam score (/100)'). Description adds no parameter-specific guidance, meeting the baseline expectation for high-coverage schemas.

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?

Specific verb 'Calculate' identifies the operation, 'French Brevet' specifies the educational domain, and '(middle school exam)' distinguishes it from the sibling calculate_bac_points (high school diploma).

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 guidance, prerequisites, or alternative suggestions provided. While 'middle school' implicitly distinguishes from 'bac' tools, it does not explicitly guide selection between 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 provided, the description carries the full burden of behavioral disclosure. It fails to indicate whether the calculation includes mortar joint allowances, waste factors, or returns additional data like weight or cost. It also doesn't disclose if this is a read-only operation (implied but 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?

The description is a tight, single phrase with zero redundancy. It front-loads the action and object immediately, appropriate for a simple utility function where verbosity would add noise.

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 (3 primitive parameters) and complete schema documentation, the description is minimally sufficient. However, it omits relevant construction context like mortar gaps or waste percentages that typically affect brick counts, leaving a small but notable gap for a specialized 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?

With 100% schema description coverage, the schema already documents that length_m and height_m are wall dimensions and type refers to brick type. The description adds minimal value beyond confirming the construction domain, meeting the baseline expectation for well-documented schemas.

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 clear verb ('Calculate') and specifies the resource ('bricks/blocks') and context ('for a wall'), distinguishing it from sibling calculation tools like calculate_paint_needed or calculate_concrete_mix. However, it slightly falters by conflating 'bricks' and 'blocks' without clarification and omitting the 'quantity' aspect.

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, prerequisites (e.g., needing wall dimensions), or when to choose 'standard' vs 'parpaing' brick types. It merely states the function without contextual usage advice.

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 of behavioral disclosure but fails to specify what the output represents (buoyant force in Newtons? floating/sinking boolean? object density?). It does not mention calculation methodology, precision, or edge cases (e.g., zero density).

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 brief at five words. While it avoids verbosity, the extreme brevity results in under-specification rather than efficient information delivery. It is front-loaded but fails to earn its place by conveying actionable meaning.

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

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

Given the lack of annotations and no output schema, the description should compensate by explaining the return value and physical interpretation (e.g., comparing object density to fluid density). It provides only a high-level topic label, leaving significant gaps in the tool's behavioral contract.

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% (volume_m3, object_mass, and fluid_density are fully documented with units). The description adds no additional parameter context, but the baseline score of 3 is appropriate when the schema carries the semantic load.

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 'Buoyancy force and floating analysis' is largely tautological, restating the tool name ('calculate_buoyancy') with slight variation. It lacks a specific verb (e.g., 'Calculate...') and fails to distinguish from sibling physics calculation tools like calculate_density or calculate_force.

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 usage guidance provided. The description does not indicate when to use this tool versus siblings like calculate_force, calculate_density, or convert_weight, nor does it mention prerequisite knowledge (e.g., Archimedes' principle) or required unit systems.

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 fails to disclose whether this is a pure calculation (read-only), what format the output takes (burn rate per month, runway in months), or any methodological assumptions (net burn vs gross burn).

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

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

Extremely concise at only four words. While no words are wasted, the description is potentially too terse to be informative, lacking any structure or front-loaded key information beyond the bare concept.

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 3-parameter schema with complete coverage and no nested objects, the description is minimally sufficient. However, it omits explanation of the runway calculation methodology and output format, which would be helpful given the lack of 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 description coverage is 100% with clear descriptions for all three parameters. The description adds no additional semantic context beyond what the schema already provides, warranting the baseline score.

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

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

The description uses noun phrases ('Startup burn rate and runway') without a clear action verb (e.g., 'Calculates', 'Computes'). While it hints at the domain, it lacks specificity about what the tool actually does and barely extends beyond the tool name.

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 provided on when to use this specific calculator versus other financial calculators (e.g., calculate_break_even). No prerequisites or contextual conditions 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 full burden for behavioral disclosure but provides minimal context. It does not disclose what standard/method it uses (e.g., voltage drop vs. ampacity), what units the result returns in (mm², AWG, etc.), or safety-critical limitations (e.g., does not account for temperature derating or installation methods).

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 single sentence is efficient with no wasted words and is appropriately front-loaded. However, given the domain complexity (electrical engineering), the extreme brevity borders on under-specification rather than optimal conciseness.

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

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

For an electrical safety calculation tool with no output schema and no annotations, the description is inadequate. It omits critical domain context: applicable standards, conductor material assumptions (copper/aluminum), installation type considerations, and output format/interpretation (minimum cross-section vs. recommended).

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%, establishing a baseline of 3. The description adds no contextual semantics about the parameters (e.g., that length_m is one-way cable run, that power_w represents the load consumption, or how the default 3% drop relates to specific electrical codes).

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 provides a clear verb ('Calculate') and specific resource ('electrical cable cross-section'). However, it fails to differentiate from the sibling tool 'calculate_cable_section_electrical', which creates ambiguity for the agent when selecting between nearly identically named tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, particularly the sibling 'calculate_cable_section_electrical'. No prerequisites, standards references (e.g., NEC, IEC), or material context are mentioned despite this being an electrical safety calculation.

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 of behavioral disclosure. It fails to specify the output format (mm², AWG, etc.), calculation standards referenced (IEC, NEC), conductor material assumptions (copper vs aluminum), or whether safety margins are applied—all critical for an electrical engineering calculation.

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

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

The description is a single efficient sentence that front-loads the action verb. While appropriately sized for a simple calculator, it sacrifices necessary technical context for the sake of brevity, preventing a score of 5.

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 technical engineering tool with 4 parameters and no output schema, the description lacks crucial contextual details: output units, applicable electrical standards, voltage system assumptions (single/three phase), and environmental installation factors that would allow an agent to validate inputs or interpret results correctly.

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

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

The input schema has 100% description coverage with clear definitions for each parameter (power_w, voltage, distance_m, max_drop_pct). The description lists these inputs but adds no semantic value beyond what the schema already provides, warranting the baseline score of 3.

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

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

The description clearly states the specific action (Calculate) and resource (cable section) along with the required inputs (power, voltage, distance, max voltage drop). However, it fails to distinguish itself from the sibling tool 'calculate_cable_section', leaving ambiguity about which electrical-specific factors differentiate this tool.

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

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

The description provides no guidance on when to use this tool versus alternatives (like 'calculate_cable_section'), nor does it mention prerequisites such as electrical system type (AC/DC), conductor material, or installation method that might be required for safe cable sizing.

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 of disclosure but reveals almost nothing about behavior. It doesn't state the calculation formula, whether the result is a decimal or percentage, what constitutes a healthy ratio threshold, or any validation behavior beyond the schema's minimum 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?

While brief at 5 words, this represents under-specification rather than efficient conciseness. The single phrase fails to serve as a complete tool description, lacking both action verbs and contextual framing needed for an agent to understand the tool's function.

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

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

For a 2-parameter calculation tool with full schema coverage, the description should at minimum explain the mathematical relationship between inputs and the interpretation of output. Without annotations or output schema, the description leaves critical gaps in explaining what value this calculation provides.

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

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

Schema description coverage is 100% with clear EUR unit specifications for both parameters. The tool description adds no parameter-specific guidance, but with complete schema documentation, this meets 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 identifies the two financial metrics involved (CAC and LTV) and implies a comparison via 'vs', but fails to specify what calculation is performed (ratio of CAC/LTV or LTV/CAC?) or what the output represents. It uses a noun phrase rather than an action verb, making the actual operation ambiguous.

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 provided on when to use this versus other financial calculation tools (like calculate_roi or calculate_profit_margin) or what business decisions this metric informs. No prerequisites or contextual requirements 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It fails to explain what the calculation returns (remaining caffeine level, clearance rate, or time to elimination), what units are used, or any pharmacological assumptions (e.g., standard 5-hour half-life).

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?

While the three-word description is technically concise, it constitutes under-specification rather than efficient communication. It fails to front-load critical behavioral information necessary for tool selection.

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?

As a calculation tool with no output schema and no annotations, the description should explain the return value and calculation methodology. It provides insufficient context for an AI agent to understand what numeric result to expect or how to interpret it.

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

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

Schema description coverage is 100% with clear descriptions for both 'mg' and 'hours' parameters. The description adds no additional semantic information beyond what the schema already provides, warranting the baseline score of 3.

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

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

The description identifies the domain (caffeine) and loosely suggests tracking half-life, but uses the vague noun 'tracker' rather than a specific verb. It fails to distinguish from siblings calculate_caffeine_half_life and calculate_caffeine_intake, leaving ambiguity about what 'clearance' actually calculates (remaining mg, elimination rate, or time to clear).

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 provided on when to use this tool versus the sibling caffeine calculators. No mention of input prerequisites or typical use cases.

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 fails to disclose the assumed half-life constant (typically ~5 hours for caffeine), whether individual metabolic variations are considered, or that results are mathematical estimates rather than medical measurements.

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 single sentence is efficiently structured and front-loaded with the core action. However, given the lack of annotations and presence of sibling tools, the extreme brevity leaves critical gaps rather than demonstrating purposeful minimalism.

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-parameter calculation tool with complete schema coverage, the description covers the basic functional contract. However, it omits important context regarding the pharmacokinetic model (half-life decay) and fails to differentiate from related caffeine calculation siblings.

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 ('Hours since consumption', 'Caffeine consumed mg'), the schema adequately documents inputs. The description adds no additional parameter semantics beyond the schema, warranting the baseline score of 3.

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

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

The description clearly states the verb (Calculate), resource (caffeine), and scope (remaining in body after time elapsed). However, it fails to distinguish from siblings like 'calculate_caffeine_clearance' or 'calculate_caffeine_intake' by not mentioning the half-life methodology.

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 provided on when to use this tool versus alternatives like 'calculate_caffeine_clearance'. No prerequisites or constraints mentioned beyond what's in the schema.

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 full disclosure burden. It adds value by specifying the safety comparison feature, but omits what the 'safe daily limit' threshold actually is (400mg standard? weight-adjusted?), whether results are advisory or medical grade, and output format 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?

Single sentence, no filler words, immediate verb-object clarity. Every word earns its place despite the information density.

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 nested input complexity (array of objects) and lack of output schema, the description covers the core value proposition but leaves operational gaps. It should specify input units, supported beverage types, or return value structure (total mg, percentage of limit, safety status?).

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 0% and the description minimally compensates. While 'from beverages' maps to the drinks array, it fails to explain the nested structure requires drink type (enum values) and quantity, nor what unit quantity expects (cups, ml, oz?). Critical ambiguity for a calculation tool.

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), resource (caffeine intake), source (beverages), and specific behavior (comparison to safe daily limit). However, it does not explicitly differentiate from siblings calculate_caffeine_clearance and calculate_caffeine_half_life, though the names imply distinct purposes.

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 provided on when to use this tool versus the pharmacokinetic siblings (clearance/half_life), or prerequisites like whether quantity should represent servings, milliliters, or caffeine milligrams. No mention of target user groups (general consumers vs. medical contexts).

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

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

With no annotations provided, the description carries the full disclosure burden. It adds valuable context by specifying 'MET values' as the calculation method and 'Estimate' indicating approximate output, but lacks details on output format, precision limits, or whether results are stored.

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

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

Extremely efficient single sentence (9 words) with zero waste. Front-loaded with the action verb 'Estimate', followed by output, scope, and methodology. Every word earns its place.

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

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

Adequate for a simple 3-parameter calculation tool with complete schema coverage. However, given the crowded namespace of 300+ sibling calculate_* tools (including health-related ones like calculate_bmr, calculate_tdee), it lacks differentiation guidance. No output schema is present, but the output is reasonably inferred from the description.

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%, establishing a baseline of 3. The description adds semantic context by implying the activity parameter maps to MET coefficients, but does not elaborate on parameter interactions, valid ranges beyond schema constraints, or formatting details.

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

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

The description uses the specific verb 'Estimate' with clear resource 'calories burned' and scopes it to 'physical activity'. Critically, it includes 'using MET values' which distinguishes this from sibling tools like calculate_bmr or calculate_tdee that use different formulas.

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 through specificity (MET values for physical activity), but provides no explicit guidance on when to choose this over similar siblings like calculate_tdee, calculate_bmr, or calculate_dog_walking_calories. No alternatives or exclusion criteria 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?

No annotations provided, so description carries full burden. Discloses key calculation detail (16.5% Quebec federal abatement) which affects results behaviorally, but omits return value structure, error handling, or 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?

Single sentence, front-loaded with action verb 'Calculate'. Zero filler words. Every element serves purpose: jurisdiction (Quebec), scope (combined federal), and specific rule (16.5% abatement).

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 single-parameter tax tool with no output schema, description captures the essential domain complexity (Quebec abatement). Would benefit from hinting at return value (e.g., 'returns total tax liability') but covers the critical jurisdictional specificity.

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

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

Schema description coverage is 100% with clear 'Annual income in CAD' description. Description does not mention parameters, but baseline is 3 when schema coverage is high (>80%) as it avoids redundancy.

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?

Specifies exact action (Calculate), resource (combined Quebec + federal income tax), and unique scope (Quebec federal abatement). Clearly distinguishes from siblings calculate_canada_federal_tax and calculate_quebec_income_tax by emphasizing the combined nature and specific abatement percentage.

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 usage through specificity ('combined' suggests use when needing both taxes), but lacks explicit guidance like 'use calculate_canada_federal_tax instead for federal-only calculations.' Siblings are not referenced.

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. Mentions the Quebec rate distinction (useful behavioral trait), but omits other critical details: output structure (employee/employer portions?), calculation methodology (current year rates?), and whether operation is read-only/pure function (implied by 'Calculate' but 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?

Single efficient sentence (11 words) with zero waste. Front-loaded with action verb, immediately communicates scope variation. Appropriate length for a two-parameter calculation tool.

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

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

Adequate for low-complexity tool with well-documented schema, but given no output schema exists, description should ideally disclose return value structure (e.g., 'returns employee premium, employer premium, and total'). Currently minimally viable.

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%, establishing baseline 3. Description reinforces the province parameter semantics by mentioning 'Quebec and non-Quebec residents' alignment, but adds no further syntax guidance or format details beyond what schema already provides.

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

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

Clear specific verb ('Calculate'), precise resource ('Canadian Employment Insurance (EI) premiums'), and explicit scope differentiation ('Quebec and non-Quebec residents') that distinguishes it from sibling Canada tax tools like calculate_canada_federal_tax or calculate_canada_rrq.

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 usage through specificity (EI vs other deductions) and mentions the Quebec/non-Quebec distinction which guides province parameter selection, but lacks explicit when-to-use guidance versus alternatives like calculate_canada_combined_tax or calculate_quebec_income_tax.

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

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

With no annotations provided, the description carries the full burden. It discloses that the calculation includes the basic personal amount deduction, but does not mention output format, tax year specificity, read-only nature, or estimation disclaimer.

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 efficient sentence with zero waste. Every word serves a purpose: the action (Calculate), the domain (Canadian federal/CRA), and the specific calculation method (basic personal amount deduction).

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 single-parameter calculation tool, the description adequately explains the core logic but lacks output specification (especially important given no output schema) and tax year 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 'income_cad' fully documented. The description adds context about the deduction logic but does not expand on parameter semantics beyond the schema definitions.

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 ('Calculate') and resource ('Canadian federal income tax'), plus specific feature ('basic personal amount deduction'). However, it does not explicitly distinguish from sibling 'calculate_canada_combined_tax' or note that provincial taxes are excluded.

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 no explicit guidance on when to use this tool versus 'calculate_canada_combined_tax' or provincial calculators, nor mentions prerequisites like tax year applicability.

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, yet provides no behavioral details. Does not disclose whether calculation includes employer+employee portions, what tax year rates apply, maximum contributory earnings limits, or output format.

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

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

Single sentence, 9 words, front-loaded with verb. Efficient with no redundancy. However, given zero annotations and missing output schema, the brevity leaves significant gaps that additional sentences could fill.

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 single-parameter calculation tool. Identifies the calculation domain clearly. Missing: contribution rates explanation, employer vs employee split details, and output value description. Acceptable but minimal for a regional pension calculation tool.

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

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

Schema has 100% coverage with clear description 'Gross annual earnings in CAD'. Tool description adds no parameter-specific context (e.g., examples, validation rules, whether to use pre-tax or post-tax gross), warranting baseline score 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?

Specific verb 'Calculate' + resource 'Quebec Pension Plan (RRQ) contributions' + scope 'for employee'. Explicitly includes 'Quebec' and 'RRQ' to distinguish from federal Canada tools (calculate_canada_ei, calculate_canada_federal_tax) and from Quebec income tax (calculate_quebec_income_tax) 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?

No explicit guidance on when to use this vs calculate_canada_ei or calculate_quebec_income_tax. Does not mention prerequisites like requiring Quebec employment status or how it relates to CPP (Canada Pension Plan) for non-Quebec residents.

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 zero annotations provided, the description carries the full burden of behavioral disclosure. It does not indicate whether this performs a pure calculation or accesses external tax databases, what format the return value takes (breakdown vs total), or if results include social charges (prélèvements sociaux) typically associated with French capital gains.

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

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

Extremely concise single sentence (7 words) with no redundancy. Front-loaded with the action verb 'Calculate'. However, the brevity becomes a liability given the tool's complexity and the presence of confusable sibling tools.

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 basic identification but incomplete given domain complexity. No output schema exists, yet the description doesn't hint at the return structure (tax amount, effective rate, taper relief details). The lack of differentiation from 'calculate_property_capital_gains_fr' is a significant contextual gap.

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

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

Schema coverage is 100% with clear descriptions for all three parameters (purchase_price, sale_price, years_held). The description itself adds no parameter-specific context, but baseline 3 is appropriate given the schema's completeness.

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 identifies the specific calculation (French property capital gains tax) using both English and the French legal term 'plus-value immobiliere'. However, it fails to distinguish from the nearly identical sibling tool 'calculate_property_capital_gains_fr' that appears in the same toolkit.

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 no guidance on when to select this tool versus the sibling 'calculate_property_capital_gains_fr' or other property tax calculators. No mention of prerequisites (e.g., owning property) or input requirements.

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 of behavioral disclosure. It fails to mention output format (CO2e units?), calculation methodology, data sources, or idempotency. Only 'Estimate' hints at non-deterministic/calculated 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?

Extremely brief (4 words) with no waste, but arguably undersized for the tool's complexity and lack of annotations. Front-loading is moot given brevity.

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

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

Lacks output schema disclosure (what units/format does it return?), lacks behavioral context, and provides no usage guidance. While input parameters are documented in schema, the description fails to compensate for missing output documentation.

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

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

Schema description coverage is 100% (all 4 parameters have clear descriptions), establishing baseline 3. The description adds no parameter semantics beyond the schema (no mention of valid ranges, unit constraints, or interdependencies between kwh/km_car).

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 provides a specific verb ('Estimate') and resource ('annual carbon footprint'), clearly indicating the tool's function. However, it does not differentiate from similarly named siblings like 'calculate_carbon_sequestration' or environmental 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?

Description contains no guidance on when to use this tool versus alternatives (e.g., calculate_electricity_cost for just energy, or calculate_carbon_sequestration), nor any prerequisites for the estimation.

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

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

With no annotations provided, the description carries the full burden. While 'Estimate' implies approximation and 'over their lifetime' defines scope, it fails to disclose output units (kg? tons?), return format, data source methodology, or whether the result is per-tree or total.

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 single-sentence description is tightly worded and front-loaded with the action verb. However, given the lack of annotations and output schema, the extreme brevity becomes a liability rather than a virtue.

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

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

With no output schema and no annotations, the description inadequately compensates. It omits critical output details like units (kg CO2 vs. tons), temporal breakdown (annual vs. cumulative), and accuracy caveats needed to interpret the calculation result.

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

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

Input schema has 100% description coverage with clear descriptions for 'tree_type', 'age_years', and 'count'. The description mentions 'trees' generally but adds no semantic clarifications beyond what the schema already provides, warranting the baseline score.

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

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

The description uses a specific verb ('Estimate') and resource ('CO2 sequestration by trees') and clarifies the temporal scope ('over their lifetime'). However, it does not explicitly differentiate from the sibling tool 'calculate_carbon_footprint' (emissions vs. capture).

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, no prerequisites (e.g., mature tree assumptions), and no warnings about the estimation methodology.

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 safety burden. It adds valuable context by specifying 'hypergeometric' distribution (sampling without replacement), which explains the mathematical model used. However, it lacks output format details (probability as decimal vs percentage) and validation behavior (e.g., handling impossible draws).

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 efficient sentence with zero waste. The key terms ('hypergeometric', 'deck') are front-loaded, and every word earns its place. Appropriate length for the complexity level.

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 4 parameters with full schema coverage and no output schema, the description is minimally complete but has a gap regarding return value format. For a mathematical tool, specifying whether the output is a probability (0-1) or percentage would be helpful 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?

Input schema has 100% description coverage with clear definitions for all 4 parameters (deck_size, draw_count, target_cards, cards_in_deck_matching). Since the schema fully documents the parameters, the description doesn't need to add param-specific details. 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 specific verb 'Calculate' with precise resource 'hypergeometric probability' and scope 'drawing specific cards from a deck'. It effectively distinguishes from siblings like calculate_dice_probability and calculate_lottery_odds by specifying the mathematical method (hypergeometric) and domain (deck/cards).

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 sibling probability calculators (calculate_dice_probability, calculate_lottery_odds, calculate_poker_hand_probability). No prerequisites or conditions mentioned despite the specific mathematical domain.

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 behavioral disclosure burden and succeeds by revealing the specific step-function depreciation rates applied to each year bracket. This allows the agent to predict exactly what computation will occur, though it lacks information about return format or geographic applicability of these rates.

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

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

Extremely efficient single-line description front-loaded with the action verb, followed immediately by the specific calculation parameters. No redundant words or filler content.

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-parameter calculation tool, the description adequately explains the computation logic but lacks output format specification (currency, numeric value, formatted string) given the absence of an 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?

Despite 100% schema description coverage, the description adds valuable semantic context by mapping the abstract 'age_years' parameter to concrete year brackets (Y1, Y2, Y3, Y4-5, Y6+) and indicating how purchase_price factors into the percentage calculations.

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 specific action (Calculate car residual value) and provides the exact depreciation algorithm (Y1:-25%, Y2:-15%, etc.), distinguishing it from sibling tools like calculate_car_lease_vs_buy through its specific focus on residual value calculation.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., calculate_car_lease_vs_buy) or prerequisites. It only presents the calculation formula without contextual usage 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 must carry the full burden of behavioral disclosure, yet it fails to mention that this is a safe read-only calculation, what the output format contains (e.g., cost breakdown, recommendation), or any limitations like currency assumptions (EUR implied by schema but not stated in description).

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 single sentence is front-loaded with zero waste words, efficiently communicating the core purpose. However, given the complexity of a 6-parameter financial comparison tool with no output schema, this extreme brevity approaches underspecification rather than optimal conciseness.

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

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

For a complex financial tool with six interacting parameters and no output schema or annotations, the description lacks crucial context about the comparison methodology (e.g., net present value, total cost of ownership), output structure, and whether tax implications or fees are included in the calculation.

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

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

With 100% schema description coverage, the schema already fully documents all 6 parameters (car_price, lease_monthly, etc.) and their relationships. The description adds no additional semantic context about how the lease parameters interact with loan parameters, earning only the baseline score for high schema coverage.

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

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

The description clearly identifies the action 'Compare' and the specific financial scenario 'car leasing versus buying with loan', distinguishing it from generic loan calculators or depreciation tools in the sibling list. However, it does not specify what metric is compared (total cost, monthly cash flow, etc.), slightly limiting its 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 no guidance on when to use this tool versus alternatives like calculate_loan_payment, calculate_car_depreciation, or calculate_mortgage. There are no prerequisites mentioned, such as requiring specific financial inputs or scenarios where this comparison is most valid.

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 carry full burden. While it mentions 'with waste', it does not explain how waste is applied (added to area vs. cost), what the output format is, or that this is a pure calculation with no side effects. Insufficient for a financial 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?

Extremely brief at 5 words. No redundant or wasted language. Front-loaded with action verb. Appropriate density given the schema completeness, though arguably too terse given lack of annotations.

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

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

No output schema exists and no annotations provided, yet description fails to explain what values are returned (total cost? cost per square meter? breakdown?). For a calculation tool with no supporting metadata, the description should disclose the calculation result format and methodology.

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

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

Schema description coverage is 100% (all 4 parameters documented). Description adds no parameter semantics beyond the schema, but baseline 3 is appropriate when schema coverage is high.

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

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

States specific action (Calculate) and resource (flooring cost) and includes key behavioral detail (with waste). However, it does not explicitly differentiate from siblings like calculate_floor_area or calculate_tile_quantity, though the 'carpet' in the name helps distinguish it.

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

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

Provides no guidance on when to use this tool versus the numerous sibling calculation tools (e.g., calculate_tile_quantity, calculate_fabric_needed, calculate_floor_area). No prerequisites or conditions 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?

No annotations are provided, yet the description discloses no behavioral traits (e.g., whether this uses a simple linear formula or distinct life-stage multipliers, precision of result, or that it is read-only). The description carries the full burden and provides minimal 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?

Extremely terse at five words; while there is no word waste, the fragment format borders on under-specification for a tool lacking an output schema. A complete sentence would improve 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?

For a single-parameter calculator, the description hints at the return value (human years), but without an output schema, the description should explicitly state the return format and calculation method. Adequate but minimal.

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

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

With 100% schema description coverage, the baseline is appropriately met. The description adds implicit context that the output is human years, but provides no additional semantic detail about the cat_years parameter beyond the schema's 'Cat age in years'.

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 phrase 'Cat age in human years' implies a conversion calculation but lacks a verb and is ambiguous about input/output direction. It does not distinguish from sibling tools like calculate_dog_age or calculate_pet_age, which likely have nearly identical descriptions.

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 provided on when to use this specific tool versus calculate_pet_age or calculate_dog_age, nor any mention of prerequisites or constraints.

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