CalcBright Calculators

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

Annotations already declare a safe, idempotent, closed-world read, so the bar is low, and the description still adds real behavior: it enforces the 2026 $24,500 contribution limit, models catch-up contributions, and supports a stop age. Those are modeling assumptions not derivable from any structured field. It stops short of saying what the calculation returns (a single balance versus a year-by-year schedule).

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

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

Three sentences plus a URL is an appropriate length, but the description is front-loaded with a worked example result rather than a statement of purpose, so an agent must read to the second sentence to learn what the tool does. The calcbright.com link adds little for an agent that cannot browse.

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 11 optional parameters and no output schema, the description should say what comes back and how the stop age and inflation inputs affect the result. It covers the contribution-limit logic but leaves the return shape and the interaction between stopAge, retireAge, and inflation unexplained.

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

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

Schema description coverage is 100%, so the 11 parameters are already documented with ranges and defaults, which sets the baseline at 3. The opening example usefully illustrates how contribution, match, and matchLimit combine, but the description adds no unit, format, or interaction guidance beyond what the schema already carries.

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 tool as a 401(k) growth projector and names specific modeling behaviors (the 2026 $24,500 limit, catch-ups, and a stop age). It is clear what the tool computes, but it never distinguishes itself from close siblings such as retirement_calculator, roth_ira_calculator, or future_value_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?

There is no when-to-use guidance and no routing to or away from alternatives, despite a crowded field of adjacent retirement and savings calculators. The Gulf-employer scenario that would justify stopAge lives in the schema, not in the description, so the agent gets no help choosing this tool over a generic retirement calculator.

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

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

Annotations already declare a read-only, idempotent, closed-world operation, so the safety profile is covered. The description goes beyond them usefully by listing the computed outputs, which is meaningful here since there is no output schema. It stops short of edge-case behavior (e.g. future dates, default birth date of 1990-01-01).

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?

A single front-loaded sentence carrying the full output list, with no filler. The trailing marketing URL is extraneous for tool selection but does not impede comprehension.

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, read-only calculator with no output schema and no nested objects, the description adequately conveys what the tool computes and returns. Only minor gaps remain: no alternative-tool routing and no mention of the asOf parameter or default birth date 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%, so both parameters (birth, asOf) are documented in structured form and the baseline is 3. The description implies the birth input but never mentions the optional asOf date, adding essentially no meaning beyond the schema.

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

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

States a specific verb+resource (computes exact age from date of birth) and enumerates the derived outputs (years/months/days, total weeks and days, birth weekday, next-birthday countdown), so its scope is unmistakable. It does not, however, draw any boundary against close siblings like date_difference_calculator or day_of_week_calculator, which share part of this surface.

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

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

The description gives no when-to-use guidance and never names an alternative, despite several near-neighbors (date_calculator, date_difference_calculator, day_of_week_calculator, countdown_calculator). An agent must infer from the tool name alone which of these date tools to select.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the description only needs to add computational context. It does disclose what the calculation produces (payment splits, interest total, settlement figure) and gives a concrete numerical example, but says nothing about output structure, per-payment granularity, or how flat vs reducing basis alters results.

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

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

Three short sentences with no wasted words. It leads with a numeric example rather than a purpose statement, which is slightly less front-loaded for tool selection, but the second sentence immediately names 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?

For a nine-parameter financial calculator with no output schema, the description should say more about what comes back — a schedule, a summary, one row per payment. It conveys the headline outputs and offers a documentation URL, but an agent still cannot anticipate the response shape or column set.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in structured data, establishing a baseline of 3. The description adds nothing parameter-specific beyond mirroring the schema defaults in its example (300,000 / 6.5% / 30 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 description states a specific resource and what it produces: it 'splits each payment and shows extra-payment and settlement savings', which is more precise than a generic 'calculates loan payments'. It does not, however, distinguish itself from the numerous amortization-capable siblings like mortgage_calculator or loan_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?

There is no explicit guidance on when to choose this over alternatives, even though the sibling list contains at least five tools that compute loan amortization. The mention of extra-payment and settlement scenarios implies use cases but never states when-not or which sibling to prefer.

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

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

Annotations already declare this a read-only, idempotent, closed-world computation, so the safety profile needs no restating. The description adds genuine context by disclosing the three calculation modes and by showing a sample result, which hints at output shape. It says nothing about rounding, currency handling, or how growth and timing interact with the result, which is the remaining behavioral gap.

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

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

Two sentences, front-loaded with a concrete worked example, followed by a one-line enumeration of the other two modes. No filler, and the trailing web page URL is short and clearly separable from the substance.

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, but the sample result partly compensates by implying the returned figure. The real gap is mode-to-parameter routing: with 9 parameters and no required fields, the description never says that quote matters only in rate mode or that amount is irrelevant in payout mode. For a multi-mode calculator that is a meaningful omission.

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

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

Schema description coverage is 100%, so every parameter including the mode enum already carries its own documentation. The description's contribution is limited to naming the three mode scenarios and pairing example values with amount/rate/years, which reinforces but does not extend the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names the resource (annuity) and enumerates its three outputs: periodic payout, the lump sum needed for a given income, and the implied rate in a quote. The worked example ('$100,000 at 5% pays $659.96 a month for 20 years') makes the primary payout calculation concrete. It stops short of explicitly distinguishing itself from near neighbors like compound_interest_calculator or retirement_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?

Usage is only implied through the three scenario phrases ('finds the lump sum for an income', 'the rate hidden in an insurer's quote'), which do map onto the mode enum values payout/needed/rate. There is no statement of when to prefer this over sibling calculators, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds genuine methodology context (fees are capitalized into the APR, flat rates are converted, a SAMA-style effective rate is produced), which annotations cannot express. However, it says nothing about what the response actually contains — no output schema exists, so the return shape is left unexplained.

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 lead example is front-loaded and immediately conveys the value, followed by a tight sentence on capabilities. The trailing web-page URL is filler for an agent caller and slightly dilutes an otherwise efficient three-sentence structure.

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

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

Six optional parameters all defaulted and no output schema means the description should explain what comes back (APR only? monthly payment? total interest?) and what the defaults imply — it does neither. It is adequate for invoking the tool but leaves the agent guessing about the result.

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

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

Schema description coverage is 100%, with per-parameter descriptions for fees, rate, term, basis and currency, so the schema does the heavy lifting. The description adds no parameter-level detail beyond the general framing that fees and flat rates are inputs. 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?

States a specific verb and resource: converts flat rates, adds upfront fees, and reports an APR plus a SAMA-style effective rate, illustrated with a concrete worked example. It is clearly not a plain loan-payment tool, but it never names the adjacent siblings (loan_calculator, simple_interest_calculator, amortization_calculator) so the boundary is inferred rather than declared.

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?

Usage is only implied by the example of a flat 2.99% loan with a 1.05% fee — an agent can infer this is for true-cost-of-credit comparisons. There is no explicit when-to-use, when-not-to-use, or alternative-tool routing against the many loan and interest calculators in the sibling list.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower. The description adds genuine output behavior beyond annotations: it reports the formula and the working steps, which matters because there is no output schema. It stops short of describing formatting or unit handling in the result.

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 compact sentences, front-loaded with the resource and supported shapes, then the output behavior. The documentation URL is mildly extraneous but not distracting.

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

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

With no output schema, the description correctly covers what comes back (formula plus working). What it omits is the shape-to-parameter mapping needed to call the tool correctly for non-rectangular shapes, and why 'z' exists and when it is required.

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 80%, so the schema already documents x (Length), y (Width), unit, and shape; baseline is 3. The description adds nothing about which of x/y/z applies to which shape, which is the key ambiguity here (e.g., a circle needs only one dimension, but x/y/z are all free-form numbers with 'z' completely undocumented in both schema and description).

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 a specific resource (area) and enumerates the exact shapes supported, which lets an agent know it covers rectangle/square/triangle/circle/trapezoid/parallelogram/ellipse. It does not, however, distinguish itself from overlapping siblings like circle_calculator, triangle_calculator, or square_footage_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?

No when-to-use or when-not-to-use guidance. Given the dense sibling set, the definition should have said whether this is the general-purpose geometry area tool that supersedes the shape-specific siblings; instead the agent must guess.

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

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

Annotations already establish that this is a read-only, idempotent calculation, so safety behavior is covered. The description adds useful context that it handles VAT, trade-in, balloon payments, and flat-rate-to-APR conversion, but it does not clarify exactly what results are returned beyond the single example.

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

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

The description is compact and front-loads a concrete example before explaining the calculator's features. The web page URL is useful but slightly ancillary; overall there is little wasted text.

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

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

With 10 optional parameters and no output schema, the description should ideally clarify the return values and usage context more fully. It gives a useful example output and mentions major features, but omits explicit description of what the calculator returns beyond the illustrative monthly payment and APR.

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

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

Schema description coverage is 100%, so parameter meaning is already well documented. The description reinforces a few key concepts, especially flat rate versus APR and the inclusion of VAT, trade-in, and balloon payments, but it does not add detailed semantics beyond the schema.

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

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

The description clearly identifies a car loan calculator and shows a concrete payment example. It also names key features (VAT, trade-in, balloon payment), which helps distinguish it from a generic loan calculator, though it does not explicitly contrast itself with siblings like car_lease_calculator or loan_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?

The description implies that this is for car loan calculations but gives no explicit guidance on when to use it instead of related tools. It does not mention alternatives, exclusions, or regional/use-case conditions beyond the feature list.

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

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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered. The description adds real value beyond them by disclosing the return shape (six statistics computed at once) and that per-statistic working is shown, including an explanation of why mean and median differ — useful for a tool with no 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?

Front-loaded with the action and the payoff, and the second clause justifies the value of seeing the working. The trailing marketing URL is the only low-value element, but the definition stays to two compact sentences.

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, read-only, idempotent calculator with no output schema, the description covers inputs, computed outputs, and the explanatory framing well enough to invoke it correctly. Edge-case behavior (invalid or empty input, very long lists) is unaddressed, which is acceptable but not 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?

Only one parameter and schema description coverage is 100%, so the separator syntax (commas, spaces, new lines) and the default list are already fully documented in the schema. The description adds nothing about input format or limits (e.g., the 100000-char cap), so baseline 3 applies.

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

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

Specific verb-plus-resource: ingests a pasted list of numbers and returns mean, median, mode, range, sum and count in one pass. It enumerates the outputs, which implicitly separates it from stat siblings like standard_deviation_calculator or percentage_calculator, but it never names or contrasts an alternative.

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?

"Paste a list of numbers" implies the input context, and the six-in-one output hints at bulk summarization rather than single-value math. However, there is no explicit when-to-use/when-not guidance and no routing to sibling calculators for related needs such as standard deviation or percentages.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing that the tool returns multiple derived values (BMI, healthy range, BMR, calorie needs), which matters because there is no output schema. It stops short of explaining how the metric/imperial parameters interact or which inputs drive which outputs.

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

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

The definition is short, but the leading sentence is a sample calculation rather than a purpose statement, so the front-loaded content does not tell the agent what the tool is or when to use it. The trailing web-page URL is promotional and consumes space without aiding invocation.

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 nine fully documented parameters, zero required inputs, and no output schema, the description does the necessary compensating work by enumerating the returned metrics (BMI, healthy weight range, BMR, daily calories). It leaves the metric-vs-imperial input convention and default behavior unexplained, which is a modest gap for a calculator with defaults pre-filled.

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

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

Schema description coverage is 100%, so the nine parameters and their enums are already documented by the schema, and the baseline of 3 applies. The description only gestures at parameter semantics through the 'kg/cm or lb/ft' phrasing, adding no detail beyond what the schema's units enum already conveys.

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 names concrete outputs — BMI in kg/cm or lb/ft, healthy weight range, BMR and daily calorie needs — and anchors them with a worked example (70 kg at 1.75 m = BMI 22.9), so an agent knows exactly what the tool computes. However, it does not differentiate itself from close siblings like bmr_calculator, tdee_calculator, and ideal_weight_calculator, which it arguably overlaps with; it never says how it differs from them.

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

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

There is no guidance on when to pick this over the many adjacent health calculators (bmr_calculator, tdee_calculator, body_fat_calculator, ideal_weight_calculator, macro_calculator). Because the tool advertises overlapping outputs (BMR, calorie needs), the omission is actively confusing rather than merely absent — an agent cannot infer selection criteria from the text.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing what the computation actually produces — three formula variants side by side plus calorie needs at five activity levels — which tells the agent the return shape despite there being no output schema. It stops short of noting the optional bodyFat dependency behavior or the metric/imperial parameter duplication.

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

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

Two sentences, the substance front-loaded and the URL relegated to the end. Every sentence carries information, though the trailing promotional web-page link is marginal for an agent's decision-making.

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 a stateless, read-only calculator, the description does the heavy lifting by enumerating the returned values and formulas. Combined with the fully documented schema, an agent has enough to invoke it correctly; only the unit-input interplay is left implicit.

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 9 documented parameters, so the baseline is 3. The description adds a little meaning (bodyFat feeds Katch–McArdle, and calorie output is generated at five activity levels rather than via a parameter), but it does not explain the metric/imperial switch or why both cm and ft/inch and kg and lb coexist.

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 names a specific resource (basal metabolic rate), the three named formulas (Mifflin–St Jeor, revised Harris–Benedict, Katch–McArdle), and the additional output (daily calorie needs at five activity levels). That is far more specific than a bare name restatement. It does not, however, distinguish itself from close siblings such as tdee_calculator, calorie_deficit_calculator, or macro_calculator, which an agent could easily confuse it with.

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

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

There is no when-to-use statement, no prerequisites, and no named alternative. With many overlapping fitness/energy siblings (tdee_calculator, calorie_deficit_calculator, calories_burned_calculator, macro_calculator), an agent gets no routing help about when BMR is the right tool versus those.

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

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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered. The description adds genuine value with no output schema present by naming what is returned (ACE category, fat mass, lean mass) and the formula used, but it omits that hips are only relevant for females in this formula and says nothing about metric/imperial switching.

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?

Front-loaded single sentence delivering formula, inputs and outputs, plus a web page link. Efficient overall, though the trailing URL is promotional rather than functional.

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 13-parameter tool with no required fields and no output schema, the description covers inputs and outputs but leaves real ambiguity unresolved: which units param to use, that height/weight and circumference each have metric and imperial duplicates, and that hip measurements apply only to women.

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

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

Schema coverage is 100%, so the schema already documents all 13 parameters with units and ranges; the description only restates neck/waist/hips. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no syntax or unit-selection guidance.

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 a specific verb and resource ('Body fat % from a tape measure'), names the exact formula (US Navy Hodgdon–Beckett), lists the inputs (neck, waist, hips) and outputs (ACE category, fat mass, lean mass). This clearly distinguishes it from siblings like bmi_calculator, lean_body_mass_calculator and waist_to_hip_ratio_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?

The tool is implicitly scoped to a tape-measure method, which hints at when it applies, but there is no explicit when-to-use/when-not guidance and no reference to the alternative body-composition siblings an agent would have to choose between.

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

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

Annotations already establish readOnly, idempotent, and non-open-world behavior. The description adds genuine value beyond them by disclosing that three formulas (Mosteller, Du Bois, Haycock) are returned and that both unit systems are supported, which an agent cannot derive from the annotations or schema alone.

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

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

Three short sentences with the worked example front-loaded, which is efficient. However, the leading example is a weak substitute for a purpose statement, and the trailing web-page URL is promotional padding that does not help an agent invoke the 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?

With no output schema, the description partially compensates by showing a sample result (1.82 m²) and naming the three returned formula values, so an agent can anticipate the return shape. The remaining gap is the absence of any explicit statement of which inputs map to which units.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and their bounds. The description only echoes units (metric/imperial) and implies height/weight, adding no syntax, ranges, or semantics beyond the schema. Baseline 3 applies.

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

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

The description never states the verb directly; it relies on an example ('A person 170 cm tall weighing 70 kg has a body surface area of 1.82 m²') plus formula names to imply that it computes BSA. The resource is clear from the name/title, but there is no explicit statement of what the tool does and no differentiation from siblings like bmi_calculator, body_fat_calculator, or lean_body_mass_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?

There is no guidance on when to use this tool versus related body-metric calculators, nor on which formula to prefer or when to pick metric vs imperial. The reader must infer all usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the return fields (units, revenue, contribution margin), which the absent output schema would otherwise hide, but says nothing about defaults being applied when inputs are omitted or about currency affecting the results.

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

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

Two tight sentences with the motivating question front-loaded, followed by inputs and outputs. The trailing marketing URL is minor padding but does not obscure the core 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?

With no output schema, the description usefully enumerates what comes back, and all four parameters are covered by the schema. It stops short of explaining default-driven behavior (e.g. a call with no arguments returns the 12000/50/30 case) or how currency shapes the outputs.

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

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

Schema description coverage is 100%, so the schema already documents fixed, price, variable and the currency enum. The description merely echoes three of the four parameters and adds no format, unit or default semantics, so the baseline of 3 applies.

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

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

The description states a specific question ('How many units must you sell before you make a profit?') and names both the inputs (fixed, price, variable) and the outputs (break-even units, revenue, contribution margin). It is clearly distinct from siblings like profit_margin_calculator or markup_calculator, though it never explicitly contrasts itself with them.

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?

Usage is only implied by the list of inputs; there is no statement of when to choose this tool over adjacent ones such as profit_margin_calculator or roi_calculator, and no prerequisites or exclusions. An agent must infer the scenario entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior. The description adds useful context by specifying output units and the Gulf climate setting for the UAE and Saudi, though it does not elaborate on calculation assumptions or edge cases.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's core function, supported inputs, output units, and a regional feature. The appended web page URL is minimal and useful.

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

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

With no output schema, the description fully explains the return values (BTU/h, tons, kW). It also summarizes the inputs and highlights the Gulf climate specialization, making it complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so all parameter details are already in the schema. The description names a few key inputs (area, ceiling height, sun, occupants) but adds no syntax, constraints, or defaults 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 states a specific verb ('Size') and resource ('air conditioner or heater'), names the output units (BTU/h, tons, kW), and lists key inputs. It clearly distinguishes this tool from generic area or unit converters by focusing on HVAC sizing.

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 purpose implies usage for sizing air conditioners or heaters, but there are no explicit when-to-use or when-not-to-use guidelines. Alternative sibling tools like area_calculator or electricity_cost_calculator are not mentioned, leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered and the description correctly does not contradict it. The example does add a small amount of behavioural signal by showing the output takes the form of a percentage split (63/17/20). However, it says nothing about how custom needsPct/wantsPct interact with actual rent and bills, or what the response contains.

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 short sentences plus a URL, so length is fine, but the structure is not front-loaded: it opens with a numeric example instead of stating what the tool does. The example itself requires the reader to reverse-engineer the inputs (which figure is income, which is annual rent) and does not earn its place without that context.

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

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

With 10 parameters and no output schema, the description carries the burden of explaining what the tool returns, and it does not do so beyond an implicit percentage split. It also omits any guidance on non-obvious inputs such as rentPeriod, cheques, and remitAs that materially change the result. For a parameter-rich calculator this leaves meaningful gaps.

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

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

Schema description coverage is 100%, so every parameter including rent, remit, remitAs, and cheques is already documented in the schema; baseline 3 applies. The description's mention of 'real rent and remittances' loosely reinforces those inputs but adds no syntax, default, or interaction detail beyond the schema. The confusing 66,000-rent-against-15,000-income example arguably muddies rather than clarifies the rent/rentPeriod and cheques 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 does convey, via 'Split pay by the 50/30/20 rule, real rent and remittances', that this tool divides income into needs/wants/savings while accounting for rent and remittances. But the leading sentence is a worked numeric example (AED 15,000 income vs AED 66,000 rent yielding 63/17/20) rather than a purpose statement, and the monthly-vs-annual framing is confusing on first read. No sibling differentiation is offered against near-neighbours like rent_affordability_calculator, take_home_pay_calculator, or savings_goal_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?

There is no when-to-use guidance at all: nothing says whether this is for planning a new budget, testing affordability, or evaluating a rent offer. No alternatives are named even though the sibling list contains several overlapping budgeting and affordability tools. The agent must infer the use case entirely from the tool 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?

Annotations already declare read-only, idempotent, and closed-world behavior. The description adds that results vary by weekend definition and subtract holidays, but it does not explain the return value or how count/add modes interact with the date parameters.

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

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

The definition is short and mostly wasted-motion-free, with a relevant illustrative example. The example appears before the core purpose and the web-page URL is extra, but neither is disruptive.

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 six-parameter calculator with no output schema, the description omits what is returned and how start, end, and days behave differently in count versus add mode. It covers the weekend and holiday concepts but leaves mode-specific parameter interaction 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%, so the baseline is 3. The description reinforces weekend, holidays, and count/add semantics already present in the schema, but adds no format or edge-case detail beyond it.

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

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

States a specific operation, 'Count or add business days,' and a specific resource, business days, with weekend and holidays context. This distinguishes it from generic date calculators, though it does not explicitly name sibling 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 implies use for business-day counting or adding with configurable weekends and public holidays. It gives no explicit when-not guidance or alternatives such as date_difference_calculator or holiday_entitlement_calculator.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and determinism are covered. The description adds useful behaviour beyond that: it can invert the calculation (reverse CAGR), derive doubling time, and layers inflation on top to produce a real growth rate. It does not say anything about rounding, output shape or how costs are treated, even though the example cites a post-cost figure.

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

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

Three sentences, with the illustrative example front-loaded so the agent immediately sees the shape of the answer. However the example spends half the text on an unparameterised cost scenario, and the feature list is a bare enumeration with no indication of which mode value enables which output.

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 8 parameters, no required fields and no output schema, the description should at minimum map the four mode enum values (rate, end, years, returns) to the advertised outputs, and it does not. It conveys enough to know the tool is a pure read-only calculator, but an agent must open the schema to learn how to drive 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%, so the schema already explains begin, end, years, rate, returns, currency and inflation, and the baseline of 3 applies. The description adds almost nothing parametrically, and the 'buying and selling costs' in the example map to no input parameter, which risks misleading an agent into expecting a cost field.

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

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

The description names the concrete outputs the tool computes (CAGR, reverse CAGR, doubling time, real growth) and anchors them with a worked example, so the resource is unambiguous. It stops short of differentiating from near-neighbours such as compound_interest_calculator, future_value_calculator, rule_of_72_calculator or roi_calculator, which an agent would need in order to pick correctly.

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

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

There is no when-to-use or when-not-to-use statement and no reference to any sibling tool. The investment example implies a growth-over-time scenario, but an agent comparing this against compound_interest_calculator or percentage_change_calculator gets no routing signal at all.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description does add one genuinely behavioral fact beyond the schema - results are 'never set below safe minimum intakes' - but says nothing about unit-pair resolution, rounding, or what happens when the goal weight is unreachable at the chosen rate.

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?

It is short, but the opening is a verbless fragment ('Your maintenance calories, a daily target... and the weeks to your goal weight') that takes a second read to parse. Roughly half the text is a promotional 'Web page:' URL that does not help an agent decide or invoke anything.

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

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

With no output schema, the description usefully enumerates the three returned values, which is the right move. However, for a 12-parameter tool with four metric/imperial duplicate pairs and a unit switch, it never explains how the two measurement systems interact or which inputs are ignored when a unit mode is chosen - a real gap for correct invocation.

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

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

Schema description coverage is 100% (12/12 params documented), so the schema already carries parameter meaning. The description only echoes the rate range (0.25-1 kg / 0.5-2 lb) and adds nothing about the cm/ft/inch and kg/lb duplicate pairs or how `units` selects between them. Baseline 3 applies.

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

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

Names the resource and the concrete outputs (maintenance calories, a daily deficit target, weeks-to-goal), which is more specific than a bare title restatement. It does not differentiate from close siblings such as tdee_calculator or bmr_calculator, both of which also produce maintenance/calorie figures, so an agent must infer the boundary.

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

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

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative despite a very crowded calorie/BMR/TDEE family. The only implied use case (weekly weight-loss planning) comes from the output description, not from routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful methodology context (results derive from Compendium MET values), but says nothing about output shape, precision, or how unit selection interacts with the kg/lb fields.

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?

A single front-loaded sentence carries the resource, method and inputs, with no redundancy. The trailing calcbright.com URL is extraneous for an agent invoking the tool but is not disruptive.

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 zero-required-parameter, annotation-covered calculator with a fully documented schema, the description supplies enough to invoke it correctly, and 'calories burned' adequately signals the return value despite no output schema. Minor gap: no mention of whether the result is a single kcal total or a per-activity breakdown.

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

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

Schema coverage is 100%, so the schema already documents all five parameters with types, defaults, ranges and enum members. The description restates body weight and time spent but adds no syntax or interaction guidance (e.g. that units governs whether kg or lb is honored). Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names the specific resource (calories burned across walking, running, cycling, swimming, lifting and 20+ activities) and the computation basis (Compendium MET values, body weight, time). An agent can tell it apart from generic siblings like tdee_calculator or bmr_calculator by the activity-based framing. It stops short of explicitly naming a sibling it displaces.

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

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

There is no when-to-use or when-not guidance, and no routing against the crowded fitness cluster (tdee_calculator, calorie_deficit_calculator, bmr_calculator, heart_rate_zone_calculator, pace_calculator). The agent must infer the use case purely from the name and description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds domain behavior (semi-annual compounding per Canadian law, CMHC premium inclusion, accelerated payment options) but says nothing about the output format or how premiums are surfaced in results.

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

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

Two tight sentences with the capabilities front-loaded, followed by a reference URL that is arguably useful rather than padding. No wasted words, though the URL is tangential to tool invocation.

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

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

With no output schema, the description should indicate what the calculator returns (e.g. payment amount, CMHC premium, total interest), but it only lists features. The input side is complete via the schema; the output side is left unspecified.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the semi-annual compounding note on rate and the first-time-buyer rule on buyer. The description's feature list mirrors that content without adding syntax or meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (Canadian mortgage payments) and lists distinguishing features: semi-annual compounding, CMHC premiums, minimum down payment, accelerated bi-weekly/weekly. This implicitly separates it from the generic mortgage_calculator and dubai_mortgage_calculator, but it never names or contrasts those siblings explicitly.

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

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

The word 'Canadian' implies the domain, but there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives like mortgage_calculator or down_payment_calculator, and no prerequisites. The agent must infer routing from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds useful behavioral scope by identifying federal tax, the 2026 tax year, the worked example, and specific tax rules handled; it still omits assumptions such as state-tax exclusion and output breakdown.

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

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

The description is three compact sentences with no wasted wording, and the example is front-loaded. The main weakness is that the example appears before a direct general-purpose statement.

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 seven-parameter calculator with no output schema, the description gives only a single example result and a feature list. It does not specify what the response contains (tax owed, effective rate, breakdown, assumptions), leaving an output-contract gap despite rich schema 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?

Schema description coverage is 100%, so the input schema already documents all seven parameters thoroughly. The description adds no parameter-specific syntax or meaning beyond the feature list, so baseline 3 is appropriate.

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

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

The concrete example ('$15,000 long-term gain... $2,250 in 2026 federal tax') and capital-gains-specific topics make clear this computes U.S. federal capital gains tax. It distinguishes itself from the generic income_tax_calculator, though it never states the overarching verb explicitly.

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

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

The description lists scenarios the calculator handles (short vs long term, 3.8% NIIT, home sale exclusion, expat stacking rule), which implies when it is relevant. However, it gives no explicit when-to-use guidance or comparison to alternatives such as income_tax_calculator.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety/behavioral profile is largely covered. The description adds that the output is split into depreciation, finance charge and tax, which is genuinely useful behavioral context beyond the annotations, but no output schema exists to specify the return shape further.

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 that lists inputs and the output decomposition, followed by a short URL. Efficient and well-structured, though the lengthy input enumeration slightly crowds the sentence.

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 10 parameters with full schema coverage, no output schema, and annotations declaring a safe read-only operation, the description covers the essential input semantics and output decomposition. It could better signal the rateType/mf-vs-apr relationship or clarify lease-specific behavior versus loans, but the schema carries most of the load.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters including the mf/apr relationship and rateType enum. The description merely lists parameter names without adding syntax, defaults, or format details beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb+resource (car lease payment calculation) and enumerates the exact inputs used (price, MSRP, residual, money factor or APR, term, sales tax). The tool is clearly distinguishable from auto_loan_calculator and other siblings by naming the lease-specific decomposition into depreciation, finance charge and 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 phrase 'to check a dealer quote' implies a usage scenario but does not explicitly state when to use this tool versus siblings like auto_loan_calculator or down_payment_calculator. No when-not-to-use guidance or alternatives are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds one genuinely useful behavioral fact: processing runs locally in the browser and nothing is uploaded, which is not derivable from the annotations. It says nothing about output format or limitations beyond the 100k maxLength, which is in the schema.

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

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

Two short sentences: the first front-loads the transformation and modes, the second adds the privacy guarantee; the URL is extra but harmless. No filler or repetition, though the trailing link is not meaningful to an agent.

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 two-parameter, zero-required, read-only text tool with full schema coverage, the basics are covered. However, with no output schema, the description never states what the tool returns (converted text? object?), and it omits which mode to choose when none is given beyond relying on the default. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so the enum values and text parameter are already documented in the schema; the description merely restates the same modes. Baseline 3 applies when the schema does the heavy lifting and the description adds little beyond it.

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

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

States a specific verb ('Switch text') and enumerates the concrete output modes, so an agent knows exactly what transformations are offered. The name and mode enum corroborate it. It doesn't explicitly distinguish itself from nearby text tools like word_counter, and the sibling list mostly contains calculators, so differentiation is implicit rather than stated.

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

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

There is no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. The default mode is 'title' (also the assumed default in the description ordering) but the description never tells the agent which mode to pick for a given intent. Usage context is entirely left to inference.

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

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

Annotations already establish this is a read-only, idempotent, closed-world computation. The description adds feature-level context: it handles APY vs APR quoting, taxes interest, and covers simple-interest deposits. It stops short of saying what a result contains or how the term/compounding options interact, so the added value is real but shallow.

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 tight sentences front-load a concrete numeric example before the capability summary. The trailing website URL is promotional and adds nothing for an agent, but overall there is little wasted prose.

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 seven optional parameters fully documented and no output schema, the description should compensate by describing the result shape, which it only partially does ('shows interest'). It never explains how compounding, rateType, and term interact in the output or how currency affects the result, leaving a meaningful gap for a financial 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 description coverage is 100%, so the schema already documents all seven parameters including the tax and rateType fields, making 3 the baseline. The description adds only a faint hint ('simple-interest deposits') toward the compounding='0' option and 'APY vs APR' toward rateType, without new format or constraint detail.

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 concrete resource ('CD calculator') and what it computes: interest for any term, APY vs APR, tax on interest, and simple-interest deposits. That is clearly more specific than the title alone, but it never distinguishes this tool from overlapping siblings such as fd_calculator, compound_interest_calculator, or simple_interest_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?

There is no explicit when-to-use or when-not-to-use guidance. The worked example ('$10,000 at 4.25% APY earns $425.00 in 12 months') implicitly demonstrates the default inputs, but an agent gets no rule for choosing this over fd_calculator or compound_interest_calculator.

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

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

Annotations already declare read-only, idempotent, and closed-world behavior. The description adds useful output context by stating that results include formulas, the working, and answers in terms of pi, which is valuable given there is no 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?

The description is front-loaded and uses two efficient sentences to state the input flexibility and output style. The appended web page URL is slightly extraneous for invocation but not disruptive.

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

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

For a simple calculator with full schema coverage and annotations, the description covers purpose, input flexibility, and expected output form. It omits unit handling details, but the schema's enum covers that sufficiently.

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

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

Schema description coverage is 100%, so the baseline is 3. The description clarifies that any one of four measurements can be entered, but it does not explain the unit parameter or add format/detail beyond what the schema already provides.

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

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

The description clearly identifies the resource (a circle) and the core operation: enter any one of radius, diameter, circumference, or area to get the other three. It does not explicitly distinguish this from other geometry siblings like area_calculator or volume_calculator, so it falls short of a 5.

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 opening question establishes the usage condition: use this when you know one circle measurement and want the others. It gives clear context but does not name alternatives or exclusions, so it is not a full 5.

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

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

Annotations indicate read-only, idempotent, and closed-world behavior, so the agent knows it is safe and deterministic. The description adds that it provides previews, contrast checks, and palettes, which is useful context about outputs. However, it does not mention performance, limitations (e.g., color name support), or return format beyond what the annotations cover. With annotations covering safety, a 3 is appropriate.

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

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

The description is a single sentence listing features, front-loaded with the core conversion capability. It is efficient and information-dense, though it could be slightly more structured. Every part earns its place by describing distinct outputs.

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 relative simplicity (color conversion with additional outputs), the description covers the main capabilities and expected outputs. It mentions contrast checking and palette generation, which might otherwise be surprising. No output schema exists, so the description adequately explains what the tool returns. The only minor gap is the lack of explicit usage scenarios.

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

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

Schema coverage is 100%, so the parameter is fully documented in the schema, including accepted formats and defaults. The description mentions supported formats but does not add syntax details or examples beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description clearly states the primary action (convert colors) and names the supported formats (HEX, RGB, HSL, HSV, CMYK). However, it does not distinguish itself from potential siblings that also involve conversion, though the color focus is unique. The extra capabilities (preview, WCAG contrast, palette) are listed but the core purpose is 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?

Usage context is implied by the listed features, but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions. The sibling tools are mostly calculators, so there is no direct color-related alternative. The description does not guide the agent on when exactly 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?

The description goes beyond simple calculation by referencing 'AER' and 'value after inflation'. This informs the agent about the tool's ability to handle complex financial metrics and contextualize the output, adding behavioral depth not present in the annotations or 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?

The definition is front-loaded with a highly effective calculation example, allowing the agent to immediately understand the tool's utility before even parsing the input schema.

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

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

Given the rich input schema, clear annotations (e.g., readOnlyHint), and the detailed illustrative example, the description provides all the necessary context for a comprehensive understanding of the tool's capability and application.

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

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

Since schema coverage is 100%, the description acts as a 'proof of concept'. It demonstrates how multiple parameters (initial deposit, monthly contribution, rate, years) work together in a real-world scenario and how the 'inflation' parameter results in 'value after inflation', adding crucial semantic 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 immediately establishes the tool's purpose (calculating compound interest) and provides a concrete, realistic example of its application. This makes it distinctly clear what the tool achieves compared to simpler siblings like 'simple_interest_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?

While it doesn't give formal exclusions (e.g., 'do not use for...'), the description sets a high bar by demonstrating complex, real-world usage involving monthly deposits, initial sums, and inflation. This strongly implies its suitability for detailed financial planning over basic calculators.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered. The description adds useful behavior beyond that (dual-unit results and premix bag counts), but says nothing about edge cases, defaults, or output shape. Adequate, not rich.

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

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

Two sentences, with the substantive scope statement front-loaded before the link. The trailing marketing URL is low-value filler, but the rest earns its place with no redundancy.

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

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

For a read-only, fully-schema-documented calculator with no output schema, the description supplies the key missing piece: what the tool returns (volume in two unit systems plus bag counts). It stops short of noting that all parameters have defaults or that the schema coverage is complete, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description reinforces the domain meaning of the outputs (cubic yards vs cubic meters, 40/60/80 lb and 25 kg bags) but adds no format or constraint detail beyond what the schema provides. Baseline 3 applies.

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

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

The description names a specific resource (concrete) and enumerates the scenarios it covers (slabs, wall footings, post holes) plus the exact outputs (cubic yards/meters, premix bag counts by weight). This is far more than a restatement of the name, though it does not explicitly distinguish itself from adjacent siblings such as gravel_calculator or volume_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?

Usage is implied by the enumerated job types (slab, footing, post hole) and the growing-context bag-sizing output, so an agent can infer when the tool applies. There is, however, no explicit when-to-use statement and no mention of alternatives like gravel_calculator or area_calculator for related material-estimate needs.

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

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description adds genuine value by disclosing what the tool returns (margin of error, critical value, every step shown), which matters because no output schema exists.

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

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

A single information-dense sentence leads with the core capability, and the trailing documentation URL is clearly segregated. Nothing is redundant, though the URL consumes space without aiding 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?

For a six-parameter, zero-required, no-output-schema tool with full schema coverage, the description is nearly sufficient: it tells the agent what inputs map to which methods and what outputs to expect. Minor gaps remain on how x/n interact for the proportion mode and how SD is handled for the z variant.

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

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

Schema description coverage is 100% and all six parameters are individually documented with ranges, defaults and enums, so the schema carries the parameter burden. The description's mention of t/z, Wald/Wilson and 80–99.9% only echoes the type and conf enums rather than adding new semantics.

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

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

The description names a specific statistical resource (confidence intervals for a mean via t/z, or a proportion via Wald/Wilson) and even enumerates the supported confidence levels and computed outputs. That specificity naturally separates it from adjacent siblings like p_value_calculator or standard_deviation_calculator, though no sibling is named explicitly.

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

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

Usage is implied by the stated scope: use it when you need an interval for a mean or a proportion. However, there is no explicit guidance on when to prefer mean-t vs mean-z vs prop, nor any exclusion pointing to alternative tools for related statistical needs.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses that results are density-dependent and that 'US cups' is the assumed convention, plus worked examples. It does not describe range limits or return format, so 3 is appropriate.

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 tightly written sentences with the conversion basis front-loaded and illustrative values that earn their place. The trailing web-page URL is mildly promotional but not disruptive.

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 read-only calculator with full schema coverage and no output schema, the description supplies the key missing context: that output depends on ingredient density and assumes US cups. An agent has enough to call it correctly; only explicit sibling routing is absent.

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

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

Schema description coverage is 100% and three parameters are enums, so the schema carries the parameter documentation burden. The description reinforces the from-units (cups/tbsp/tsp) and to-units (grams/ounces) and adds the ingredient-density concept, but adds no syntax or edge-case meaning beyond what the schema already lists.

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 a specific conversion direction (cups/tbsp/tsp to grams/ounces) grounded in ingredient density, which is the exact factor that separates it from the generic unit_converter sibling. It is clear and concrete, though it never names the sibling it overlaps with.

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

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

There is no explicit when-to-use guidance. With unit_converter, volume_calculator and fraction_calculator in the sibling list, the agent is left to infer that this tool is the density-aware one; the description states the density basis but does not frame it as a selection rule against alternatives.

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

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

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered. The description adds real behavioral value by disclosing what it computes (days, weeks, months, hours) and that it works for past dates as well as future — information no annotation or output schema supplies.

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

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

Two sentences front-load the core question and the output metrics, with no filler. The trailing marketing URL is mildly wasteful but does not dilute the operative 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?

With no output schema, the description correctly sketches the return metrics, but it never clarifies how preset and target interact (e.g., that a custom preset requires an explicit target, or that target defaults to 2027-01-01). An agent could plausibly pass a target while leaving preset at its christmas default and get unexpected results.

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

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

Schema coverage is 100%, so the preset, target, from and label semantics are fully documented in the schema, establishing a baseline of 3. The description reinforces the preset idea ('Christmas, New Year or your own date') but adds no syntax or precedence details beyond the schema.

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

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

The description states a specific computation (days/weeks/months/hours remaining) plus preset targets like Christmas and New Year, which distinguishes it from generic siblings such as date_difference_calculator. It does not explicitly name or contrast any sibling, so a 4 rather than a 5.

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?

Usage is implied through examples ('until Christmas, New Year or your own date') and the note that it also handles dates already passed. However, there is no explicit when-to-use guidance versus close siblings like date_difference_calculator or ramadan_countdown_calculator, leaving the agent to infer the boundary.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds a concrete worked example (9 years 9 months, AED 14,869.55 interest) that hints at what the result contains, but says nothing about how modes change the output or what happens with edge cases like a payment below the interest charge.

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 short sentences plus a URL, so it is not bloated. However, the lead position is spent on a marketing-style example rather than on stating what the tool computes, so the most important information is not front-loaded.

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

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

For a read-only calculator with full schema coverage and no output schema, the description gives enough of a flavor of the result (payoff date and total interest) to call it, though it does not explain how the three modes produce different outputs. The gap is small but real.

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 every parameter, so baseline is 3. The description's mention of '3.25% a month' and '5% minimum' loosely illustrates rateBasis and minPct but adds no syntax or constraint detail beyond the schema.

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

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

The description names the resource ('credit card payoff dates and payments') and implies the calculation, but never states a verb or what the tool actually returns for a given input. It is distinguishable from generic siblings only by the 'credit card' qualifier, with no explicit contrast to debt_payoff_calculator or mortgage_payoff_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?

No guidance on when to use this versus debt_payoff_calculator, loan_calculator, or amortization_calculator, and no explanation of when each of the three 'mode' settings is appropriate. The region mention (UAE, KSA, US) hints at scope but is not tied to any selection condition.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context: rates are mid-market and refreshed several times a day, and Gulf currencies are pegged with fixed examples. It does not discuss rate source caveats or precision, but the added freshness and peg behavior go beyond the annotations.

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

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

The description is only three short sentences plus a URL, and each sentence contributes something (peg example, core purpose plus rate freshness, source link). It is slightly back-loaded, with the core purpose appearing after the example, but it remains efficient and free of filler.

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?

This is a simple read-only calculator with no output schema needing explanation, and annotations cover the safety profile. The description supplies the essential facts: what it converts, how many currencies, rate type, refresh cadence, and a documentation link. Missing only minor details like rounding behavior or whether rates are indicative, so it is nearly 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 enums for from/to and a numeric amount field bounded at 0 to 1e15. The description does not add meaning beyond the schema — e.g., it doesn't explain rounding, default behavior, or how the amount is interpreted. Baseline 3 is appropriate when the schema fully documents 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 second sentence clearly states a specific verb and resource: convert 39 currencies at mid-market rates. That inherently distinguishes it from unit, cooking, or fuel-economy converters in the sibling list, though no alternative is named explicitly. The first sentence about Gulf pegs is a concrete example that reinforces the fixed-rate behavior rather than clouding the 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?

Usage is implied by 'Convert 39 currencies' — an agent can infer this is for currency exchange calculations. However, the description does not say when to choose this over a sibling like unit_converter, nor does it state any exclusions or prerequisites. No explicit when/when-not guidance is provided.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), so the description's job is to add context — and it does, disclosing that leap years and month ends are handled and that the result includes the weekday. It stops short of saying how multiple units combine or whether the calculation is calendar-based vs. fixed-length months.

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 tight sentences, front-loaded with the capability and an illustrative example. The trailing marketing URL is not strictly necessary for an agent to invoke the tool correctly, which costs it 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 zero-required-parameter, 6-param, no-output-schema tool, the description covers the essentials: what it computes, the units, and edge-case handling. Minor gaps remain — how multiple units combine in one call and the fact that everything defaults (op=add, start=today) — but these are covered in the schema.

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

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

Schema description coverage is 100%, so the schema already documents op, start, days, weeks, months and years including defaults and ranges. The description merely names the units, adding no syntax, combining rules, or explanation of the 'add'/'subtract' op beyond what is structured — the baseline 3 applies.

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

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

States a specific verb set (add/subtract), the units involved (days, weeks, months, years) and the output (exact date and weekday), so the core function is unambiguous. However, it never distinguishes itself from overlapping siblings such as date_difference_calculator, day_of_week_calculator or business_days_calculator, which an agent must choose between.

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?

Usage is only implied through the example '90 days from today'; there is no explicit when-to-use statement, no negative cases, and no routing to the many date-related siblings that could plausibly handle a related request. Adequate but leaves selection to inference.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-open-world), so the bar is lower. The description adds genuine value by disclosing the shape of the result — days plus weeks/months/years conversions and weekday/weekend counts — which matters because no output schema exists. It still omits edge-case behavior (e.g., reversed dates, end-date-empty meaning today).

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

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

Three short sentences, front-loaded with the core result and with the includeEnd option called out before the reference URL. No filler, though the URL is marginally extraneous to 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?

For a 3-parameter, zero-required, no-output-schema calculator, the description covers the computed outputs and the one behavioral toggle. It is nearly complete; only edge-case semantics and sibling disambiguation are missing, which is acceptable given the rich 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%, so all three parameters (start, end, includeEnd) are already documented in the schema. The description only gestures at includeEnd via "include the end date" and adds nothing about the date format or the empty-end default. 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 names a specific computation (days between two dates) plus the derived outputs (weeks, months, years, weekday/weekend counts), which distinguishes it from generic siblings like date_calculator or time_duration_calculator. However, it never explicitly names which sibling to use instead, so the differentiation is implied rather than stated.

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?

"Choose whether to include the end date for event lengths" gives a hint of the use case, but there is no explicit when-to-use statement, no exclusions, and no routing to competing tools such as business_days_calculator or time_duration_calculator. Usage is only implied.

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

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

Annotations already declare readOnly, idempotent, closed-world behavior, so the safety profile is covered. The description adds real value beyond that: a supported date range of 1000–9999 and the fact that Zeller's working is shown in the response. It stops short of describing the exact return shape.

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?

Front-loaded with the purpose question, followed by scope, use cases, and output detail in one tight sentence. The trailing web-page URL is promotional filler but brief enough not to bury the substantive 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 zero-required-parameter, single-input tool with rich read-only annotations and no output schema, the description supplies everything needed: what it computes, the valid range, and what the response includes. Nothing material is missing.

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

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

Schema coverage is 100% and the schema itself explains the empty-value default, so the baseline is already adequate. The description additionally constrains valid input to the years 1000–9999, which the schema's bare 'format: date' does not communicate.

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 a specific verb and resource ('Get the weekday for any date'), which is unambiguous about the single computation performed. It does not, however, name or contrast itself with adjacent siblings like date_difference_calculator or week_number_calculator, leaving the agent to infer the split.

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 examples ('birthdays, historic events, future plans') imply the intended contexts for use, which is useful framing. But there is no explicit when-not guidance and no routing to alternative date tools for adjacent needs.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safe-read behavior is covered. The description adds domain context (UAE card rates, loan fees, avalanche) and an example result, but no rate limits, auth needs, or output details beyond that example.

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

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

Three short sentences: an illustrative result, a one-line purpose, and a web page reference. There is no wasted wording, though the example precedes the purpose statement rather than front-loading the definition.

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 calculator with no output schema, the description supplies a concrete example output (30 months, $480.21 less interest), domain context, and method (avalanche). It could clarify whether it compares snowball vs avalanche or describe the full return shape, but it is largely complete.

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

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

Schema description coverage is 100%, and the schema already explains the debt line format, monthly-rate notation, optional prepayment fee, budget meaning, and currency enum. The description adds little parameter-specific meaning beyond 'UAE card rates and loan fees'.

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 a specific calculator and scope: debt payoff with avalanche, UAE card rates, and loan fees, plus an illustrative result. It does not explicitly distinguish itself from sibling credit_card_payoff_calculator or loan_calculator, so it is clear but not fully sibling-differentiating.

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

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

The description implies use for multi-debt payoff planning with UAE rates and loan fees through the example and 'avalanche' mention, but it never states when to choose it over credit_card_payoff_calculator or loan_calculator, nor any exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world). The description adds genuine domain context — that Gulf banks cap installments at 50%/33.33%/40% of salary and retirees get lower caps — which helps interpret the result. However, it never says what the tool returns (a ratio, a pass/fail per rule, both), and there is no output schema to fall back on.

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?

Only three sentences, but they are spent entirely on regulatory trivia and a promotional URL rather than on what the tool does. The link earns no place in a tool definition, and the core statement of purpose is missing entirely.

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 12 parameters, four enums, and no output schema, the description should explain the output shape and how the rules/earner switches change the result. Instead it supplies peripheral facts and a website link, leaving the agent to guess what comes back.

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%, including notes on the rules enum and the retiree cap, so the schema does the heavy lifting. The description adds nothing about which parameters to set (rules, earner, housingType) beyond loosely echoing the thresholds already in the schema text. Baseline 3 applies.

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

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

The reader can infer the domain (debt-to-income) from the name and from the lender-threshold facts, but the description never states the action: it never says the tool computes a DTI ratio from income and debt inputs. Nothing distinguishes it from siblings like home_affordability_calculator or loan_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?

No when-to-use guidance, no mention of alternatives, no note that this is for qualifying for a loan versus tracking payoff (debt_payoff_calculator). The thresholds hint at the use case but never state it explicitly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the method inventory and a worked numeric example that hints at the per-year output shape, which is useful since there is no output schema. It does not state whether a full depreciation schedule is returned, how rounding or currency formatting applies, or what the Saudi group semantics produce.

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?

It is short and mostly front-loaded, but the opening sentence is an unlabeled arithmetic statement rather than a statement of purpose, which delays the actual tool identification. The trailing web-page URL occupies space without helping an agent decide or invoke.

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 nine parameters, three enums and six methods whose relevant inputs differ, and no output schema, the description should map methods to parameters and describe the returned result. Instead it gives a single straight-line example, so an agent choosing method=uop or method=ksa gets no guidance on required 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?

Schema description coverage is 100%, so the baseline is 3. The example figures ($50,000 cost, $5,000 salvage, 5 years, $9,000/year) mirror the schema defaults and add a little intuition about the straight-line relationship, but the description adds no meaning about the conditional parameters (rate, group, units, totalUnits) beyond what the schema already documents.

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 names the resource and enumerates the supported methods: straight-line, DDB, SYD, reducing balance and Saudi tax groups. An agent can tell this apart from siblings like roi_calculator or capital_gains_tax_calculator. It stops short of any explicit sibling comparison, but the domain is unambiguous.

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

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

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives. More importantly for a 9-parameter tool, it never says which parameters matter for which method (units/totalUnits only for uop, group only for ksa, rate only for db/ddb), leaving the agent to infer method-dependent usage from the schema 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value by showing that an extra 20% applies to the already-reduced price (50% then 20% = 60% total, AED 400 to AED 160), which prevents the classic additive error. However, it says nothing about output shape, rounding, or currency formatting, and there is no output schema to compensate.

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

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

The description is short and free of filler, but it is not front-loaded: it opens with a numeric example before the second sentence states what the calculator actually does. The trailing URL is arguably unnecessary for tool selection. Reasonable length, suboptimal ordering.

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 six-parameter, all-optional, read-only calculator with no output schema, the definition is close to complete: the modes are described and the compounding rule is illustrated. The one real gap is that no parameter-to-mode mapping is given (which fields are needed when mode is 'percent' versus 'original'), leaving the agent to deduce combinations from the schema alone.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the note that extra applies to the already-reduced price. The worked example restates that interaction with concrete numbers but adds no new information about which parameters belong to which mode. Baseline 3 applies when the schema does the heavy lifting.

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

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

The second sentence names the resource (discount) and enumerates the three distinct computations: sale price, percent off between two prices, and the original price. That maps cleanly onto the three enum values of the mode parameter, letting an agent distinguish it from generic siblings like percentage_calculator or markup_calculator. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

Usage is implied by the three listed computations and the stacked-discount example, which signals the tool handles successive percentage reductions. There is no explicit when-to-use versus percentage_calculator or percent_error_calculator, and no statement about what the tool does not cover. The agent must infer selection from the mode enum.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful context by listing which fee components are included and showing a sample total, but it does not explain output granularity, assumptions, or whether rates are configurable.

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

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

The description is compact, with one dense sentence plus a URL, and no obvious filler. It is slightly less front-loaded than ideal because it opens with a sample scenario rather than a direct statement of purpose.

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

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

For a six-parameter calculator with no output schema, the description provides a useful example but does not explain the return value or breakdown. The schema and annotations cover parameters and safety, but the description could do more to describe calculation output and scope.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including enums and defaults. The description does not add parameter-level meaning beyond echoing cash purchase, AED 2M price, and 2% agent commission from the example.

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 makes clear that this is a Dubai property-purchase fee calculator by giving a concrete AED 2M example and naming the fee components: DLD transfer fee, trustee office, title deed, and agent commission plus VAT. It is clear but does not explicitly distinguish itself from nearby siblings such as dubai_mortgage_calculator or land_transfer_tax_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?

It gives no explicit when-to-use guidance, no exclusions, and no alternatives. The example implies it is for cash Dubai home purchases, but an agent must infer the trigger conditions rather than being told them.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered externally. The description contributes the expected outputs (monthly EMI, minimum down payment, full cash needed) and a numeric sanity check, which is useful, but says nothing about edge cases, rounding/currency of results, or error behavior for out-of-range input.

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

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

Three tight sentences with zero filler; the worked example makes the output concrete. It does lead with an example rather than the purpose statement, and the raw URL at the end is of marginal value to an agent, costing it a top 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?

With no output schema, the description must convey what comes back, and it does: monthly EMI, regulatory minimum down payment, and total cash required. For a 9-parameter pure-computation tool with full schema coverage and read-only annotations, the only meaningful gap is the lack of sibling disambiguation.

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% across all 9 parameters, including the Central Bank 25-year cap and VAT notes, so the schema does the heavy lifting. The description only implicitly maps inputs through its example (price, term, rate) and adds no meaning beyond the schema, making baseline 3 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?

States concretely what it computes: the Dubai mortgage EMI, the UAE Central Bank minimum down payment, and the total cash required, all anchored by a worked example (AED 1.6M / 25 years / 4.25% -> AED 8,667.81). The 'Dubai'/Central-Bank framing implicitly separates it from generic mortgage_calculator and canadian_mortgage_calculator, but it never names those siblings, so an agent must infer the boundary.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance, despite many overlapping siblings (mortgage_calculator, down_payment_calculator, dld_fee_calculator, loan_to_value_calculator). A caller has to infer applicability purely from the word 'Dubai' in the description and the tool 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?

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds real domain context the annotations cannot: the governing statute (Egypt's 2025 Labour Law) and a concrete output magnitude, but it says nothing about rounding, whether results are estimates, or how the optional insured-wage field affects the result.

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?

A single compact sentence pairs an illustrative computed result with the legal basis, then a URL. Front-loaded and waste-free, though the bare link is of marginal utility to an agent and no explicit purpose sentence precedes the example.

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

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

There is no output schema, so the description must convey what comes back; the example gives one sample figure but not the shape of the response (breakdown by service years, notice compensation, insured-wage interaction). Adequate to identify the tool, thin for anticipating its output.

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

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

Schema description coverage is 100%, including enum guidance for reason and a clear explanation of insured, so the schema carries the parameter burden and the baseline is 3. The description adds nothing per-parameter, though the example implicitly illustrates the default wage and tenure.

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 worked example (EGP 15,000/month for 7 years → at least EGP 210,000 for unjustified dismissal, plus EGP 45,000 for no notice) makes clear this computes Egyptian end-of-service/severance pay under the 2025 Labour Law. The jurisdiction is named, which separates it from jordan_end_of_service, saudi_end_of_service and morocco_severance siblings, but the description never states the action in a direct verb+resource sentence.

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?

Usage is only implied: the mention of 'unjustified dismissal' and 'no notice' hints that the reason and notice inputs drive the result. There is no explicit when-to-use guidance, no mention of the closest siblings (egypt_social_insurance_calculator, gcc_gratuity_calculator) and no statement of when this tool is the wrong choice.

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

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

Annotations already cover readOnly and idempotent, so the description doesn't need to. It does add useful domain behavior: the 11% employee and 18.75% employer rates and the 2026 wage band under Law 148. It does not explain the shape of what comes back, so it stops short of full 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?

It leads with a concrete example, then the legal limit band, then the source URL. It is compact and says nothing that is obviously wasted, although the limit range duplicates the schema.

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

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

For a one-parameter, read-only calculator with no nested objects and no output schema, the agent needs the rate split and a rough sense of the result. The example supplies both (employee and employer amounts). The description is nearly complete; the only real gap is that it doesn't describe the output fields explicitly.

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?

There is only one parameter, and schema coverage is 100%; the schema even repeats the EGP 2,700–16,700 limits. The description restates those limits verbatim, so it adds essentially nothing to what the structured field already says. A 3 is the baseline here.

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 worked example ('On an EGP 10,000 insurable wage you pay EGP 1,100 a month (11%) and your employer EGP 1,875 (18.75%)') makes it clear this computes employee and employer Egyptian social insurance contributions, and the country plus Law 148 reference separates it from siblings like jordan_social_security_calculator or gosi_calculator. However, the description never states the action in a direct verb+resource phrase; the purpose has to be inferred from the numbers.

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

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

There is no statement of when to choose this over social_security_calculator, gosi_calculator, or egypt_end_of_service_calculator, and no exclusions or prerequisites. The reader has to infer that this is the Egypt-specific tool from the name and the Law 148 mention.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world profile, so the safety bar is low. The description adds genuine value by disclosing the output dimensions (kWh and cost per day, month and year), which is not covered by any schema. It still omits details like rounding or currency handling, so it is good but not exhaustive.

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

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

Two tight sentences plus a link; the concrete example is front-loaded and immediately conveys the computation. The URL and marketing-flavored example consume some space that could carry behavioral detail, but there is little waste overall.

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

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

With six all-optional parameters, full schema coverage, and no output schema, the description does the important extra work of naming the outputs (kWh, daily/monthly/yearly cost). The only residual gap is the preset enum's behavior, which the schema already labels as 'Appliance.' Adequate to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description exceeds that by giving a concrete instantiation ('100 W TV on 5 hours a day ... at 17¢/kWh') that maps directly onto the watts, hours and price parameters and their units, reinforcing their meaning. It adds modest but real semantic value.

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

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

The description states a specific verb and resource: turning an appliance's watts and hours into kWh and running cost by day, month and year. This clearly distinguishes it from most siblings (e.g., fuel_cost_calculator covers a different resource), though it never explicitly names a sibling to contrast with. Purpose is unambiguous to an agent.

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?

Usage is only implied through the worked example and the phrase 'any appliance's watts and hours of use.' There is no explicit when-to-use, when-not, or alternative-tool guidance. For a standalone calculator the context is inferable, but nothing routes the agent explicitly.

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

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

Annotations already establish the safe read-only, idempotent profile, so the description's added value is the precision behavior: exact big integers for large results and disclosure that 'the rule used' is reported. That is meaningful context beyond the annotations, though it doesn't cover edge cases like domain errors for negative bases with fractional exponents.

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?

A single well-packed sentence leads with the purpose and capability list, followed by a reference URL. No filler, no redundancy, and the most important information is front-loaded.

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

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

For a 4-parameter, all-optional tool with no output schema, the description communicates what it computes, the input shapes it accepts, and a key output trait (exact integers, rule shown). Slightly more on the power/root mode distinction or error behavior would make it fully complete.

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

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

Schema description coverage is 100%, so the schema already documents base, exp, n and the mode enum, and the description's examples (2/3 as a fraction, negative exponents) simply illustrate what the schema explains. Nothing parameter-specific is added, which is the correct baseline of 3 under full 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 a clear verb+resource (exponent calculator) and enumerates concrete capabilities: negative, decimal and fractional powers plus nth roots, with worked examples (8^(2/3), 2⁻³, 2^100). It implicitly differentiates from square_root_calculator by covering general exponentiation, but never names or excludes sibling tools, keeping it short of a 5.

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

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

There is no when-to-use guidance, no stated prerequisites, and no routing to alternatives such as square_root_calculator for pure roots or logarithm_calculator for inverse problems. The agent must infer that this tool is the general-purpose option from the description 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful domain context that the annotations cannot convey: NRE and FCNR(B) interest is tax-free while non-resident, NRO is taxed, and treaty rates require a tax residency certificate. It still says nothing about what the response contains (maturity value, interest, TDS breakdown) or how quarterly payout changes results.

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

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

It is a single compact sentence with no filler, but it is front-loaded with an illustrative rupee figure rather than the tool's function, so the agent reads a number before learning what the tool computes. The trailing URL is low-value 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?

For an 8-parameter tool with no output schema, the description should say what comes back — maturity amount, interest earned, TDS deducted, post-tax total — and it does not. Interactions between the payout and compounding enums, and the meaning of the treaty codes, are left entirely to the schema, so an agent cannot predict the response shape.

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

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

Schema description coverage is 100%, so the baseline is 3. The worked example goes beyond the schema by binding concrete values to parameters (₹10 lakh principal, 6.5% rate, 3 years, NRE vs NRO depositor, UAE treaty) and showing how depositor plus treaty jointly change the result, which is meaningful semantic guidance the enum list alone does not provide.

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 'FD calculator after TDS' identifies the resource (fixed deposit) and the distinguishing tax dimension, so an agent can tell it is a maturity/proceeds calculator rather than a loan tool. However, it never states the purpose in a clean sentence and offers no differentiation from close siblings such as cd_calculator, compound_interest_calculator, or simple_interest_calculator. The opening is an example result rather than a definition of what the tool does.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The NRE/NRO example implies the tool applies to non-resident Indian fixed deposits, but the agent must infer that from a worked example rather than a stated condition.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds only a worked example; it does not mention that all inputs are optional/defaulted, that waste above ~15% is for diagonal/herringbone lay, or what the returned result contains.

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