API Tool Calls

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and determinism profile is fully covered by structured data. The description adds only a light clarification that input is 'source metadata' rather than free text, and says nothing about formatting rules, error behavior on incomplete metadata, or validation. With annotations doing the heavy lifting, 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?

A single front-loaded sentence with no filler; every word earns its place and the core action is stated first. It is arguably too sparse for a 20-parameter tool, but that is a completeness issue rather than 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 20 parameters, 0% schema description coverage, and no output explanation needed (an output schema exists), the description leaves the agent without any field-level or behavioral guidance. It does not clarify which fields apply to which source type or how partial metadata is handled, which is the critical missing context here.

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

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

Schema description coverage is 0% across 20 parameters, so the description must compensate and does not: it never mentions any field, the type enum (journal/book/chapter/webpage/report/video), or the meaning of flags like 'changing' and 'sentenceCase' (default true). 'Entered source metadata' is only a vague gesture at the field set. This is a substantial gap for a tool with 20 inputs.

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 (format) and a specific resource (APA reference and in-text citations) plus the input domain (entered source metadata). An agent can immediately tell what this does, and no sibling tool overlaps with citation formatting, so differentiation is inherent rather than stated. It stops short of specifying scope (e.g., APA 7th edition, which citation styles for which source types).

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives or when this tool is inappropriate (e.g., for non-APA styles). The only implied usage is the one-sentence purpose itself. Nothing tells the agent what metadata is mandatory versus optional before calling.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful fact that weighting applies only to a separately reported average (the other statistics stay unweighted), but says nothing about error behavior for mismatched weight/value lengths or invalid input. That is acceptable given annotation coverage, but 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?

A single sentence that front-loads the verb and resource, then lists outputs compactly. No filler or repetition of the title. The trailing 'plus an optional separately weighted average' clause is slightly awkwardly appended but still earns its place.

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

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

An output schema exists, so return values need not be explained, and both parameters are fully documented in the schema. The description covers what is computed and the weighted variant; the only gap is edge-case behavior (empty/oversized arrays, weight mismatch) which the schema bounds partially address.

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 documents units, bounds (±10^12), item limits (1–1000), and that weights must have at least one positive entry. The description's only parameter-level contribution is reinforcing that weights are optional and scoped to weightedAverage. 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 uses a specific verb (compute) and enumerates exactly which statistics are produced: mean, median, modes, range, sum, count, population/sample standard deviation, plus an optional weighted average. This clearly separates it from numeric siblings like z_score, logarithm, or percentage_calculator, which compute different things from the same kind of input.

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 / when-not-to-use guidance and no mention of alternate tools for related statistics. The only routing hint is the phrase 'optional separately weighted average', which signals a variant of the same operation rather than pointing at a sibling. For a self-evident calculator the omission is tolerable, but no explicit guidance is given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds value beyond them: exact BigInt arithmetic (no precision loss), a 1–4096 digit input bound, an explicit validity requirement in the source base, and the two's-complement reading rule when signed is true. It stops short of describing error output when input is invalid or out of range for the width.

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 dense sentences, front-loaded with purpose before constraints, and every clause carries information. Minor redundancy with the schema on the signed default and bitWidth requirement keeps it just short of ideal.

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 an output schema present, return values need not be explained, and the description covers the input contract, the optional bitWidth/signed interaction, and the arithmetic guarantee. What remains thin is failure behavior for invalid digits or values exceeding bitWidth, which an agent would benefit from knowing before calling.

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 60%, and the description mostly restates schema text (digits 0–9/A–Z, no prefix/sign/separators, signed defaults to false, bitWidth required when signed). The undocumented fromBase/toBase parameters are only covered implicitly by 'bases 2 through 36', so it does not fully compensate for the coverage gap; baseline 3 fits.

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 (converts), a specific resource (integer string), and a precise scope (bases 2 through 36, exact BigInt arithmetic). The digit-count bound and two's-complement/bitWidth framing distinguish it from generic converters like unit_convert or decimal_to_fraction without needing to name 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?

The scope implies when to reach for it (integer base conversion with optional bit-pattern validation), and the conditional 'signed=true requires a width' is a useful usage rule. However, it never names or excludes siblings such as unit_convert, epoch_convert, roman_numeral, or decimal_to_fraction, so routing between the many converters is 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?

The description adds substantial behavioral detail beyond the annotations (readOnly, idempotent, non-destructive): it returns every rule-matched possible cause, evidence, safe first checks, trade referrals, and sources; hazard stops come first; it provides no probabilities or structural diagnosis; it is pure rules with no network or model. This is rich context for an agent.

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

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

The description is three sentences, front-loaded with the core purpose, followed by output details and constraints. Every sentence earns its place and there is no redundancy.

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

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

For a tool with 8 optional parameters and no output schema, the description covers the output content (causes, evidence, checks, referrals, sources) and key limitations (hazard stops first, no probabilities, pure rules). It does not explain that all parameters are optional or how to combine observations, but the schema covers that. Minor gap.

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

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

Schema description coverage is 100%, and each parameter's enum values are thoroughly described in the schema. The tool description does not add meaning beyond the schema; it only refers to 'eight observation groups' without detailing individual parameters. 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 states a specific verb and resource: 'Narrow down why a basement gets wet and who fixes it.' It also details the output: eight observation groups returning rule-matched causes, evidence, safe first checks, trade referrals, and sources. This distinguishes it from generic calculators, though the sibling yard_drainage_cause is not explicitly named.

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: the tool is for diagnosing basement water issues. There is no explicit guidance on when to use this versus alternatives, such as the sibling yard_drainage_cause, and no exclusions or conditions are stated.

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, non-destructive and closed-world, so the safety profile is covered. The description adds that output includes the classification band and that the calculation targets adults, but discloses no further behavioral traits (e.g. 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?

A single front-loaded sentence with zero filler. Every clause earns its place by naming the action, output, and inputs.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a deterministic calculator the description covers essentials, though it omits unit-mismatch or range caveats.

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 67% and both height and weight carry unit-interpretation descriptions, while units is a self-documenting enum with a default. The description merely names the three inputs and adds no 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 verb (Calculate) and resource (adult BMI and its band) with clear inputs (weight, height, units). The 'adult' qualifier usefully scopes it and separates it from siblings like body_fat_calculator without ambiguity.

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, when-not, or alternative-tool guidance is given. With related siblings such as body_fat_calculator and one_rep_max_calculator present, the description offers nothing to route an agent between 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that per-row prices are optional and that a priced subtotal is produced, which is useful context, but it does not disclose edge cases, unit handling, or other behavioral details beyond the purpose.

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, front-loaded sentence that communicates the computation, inputs, and optional pricing without any filler. Every phrase contributes to understanding 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?

Given the rich annotations, detailed input schema, and presence of an output schema, the description is complete enough for an agent to understand the tool. Return values need not be explained because an output schema exists, and the description correctly focuses on the calculation and optional pricing 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 reported as 0%, so the description must compensate for the single top-level 'rows' parameter. It names the relevant concepts (dimensions, whole piece counts, per-row optional prices), but omits unit defaults and quantity defaults that are present in the nested schema properties.

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: 'Sum board-foot lumber volumes' and specifies the inputs (entered dimensions and whole piece counts) plus optional pricing. This clearly distinguishes it from sibling calculators such as square_footage_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 purpose: it is for computing board-foot lumber volumes from dimensions and piece counts. However, the description does not explicitly say when to use this tool versus alternative calculators or when it is not appropriate, leaving the agent to infer.

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 destructiveHint=false, so the safety profile is covered. The description adds the 'Navy' formula context, which is genuinely useful, but omits the sex-conditional input contract and the units default that affect behavior.

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

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

One tightly written sentence with the verb front-loaded and no filler. It is appropriately short for the tool, though brevity comes at the cost of the missing conditional detail.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. However, with 7 parameters and a sex-conditional oneOf requirement, the description is too thin on the input contract and units handling to be 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 71% and the schema documents most parameters, so baseline 3 applies. The description's 'sex and tape measurements' is vague and does not clarify the oneOf conditional (waist/hip required for female, abdomen for male) or the metric/imperial units parameter.

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+resource: it states it calculates Navy-method body fat percentage and hints at inputs (sex, tape measurements). This distinguishes it from the many other calculators, though it does not explicitly name the closest sibling (bmi_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 bmi_calculator or other body-composition tools, and no mention of the sex-conditional input requirement (abdomen for male, waist/hip for female) or the metric/imperial default. The agent gets no routing or precondition help.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld=false. The description adds behavioral context by specifying the output components and a month-end convention, which is useful beyond the annotations, though the convention itself is not concretely defined.

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 the core calculation and followed by essential input guidance. No redundant or wasted language.

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

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

Given the low complexity, rich input schema, present output schema, and informative annotations, the description is nearly complete. It could clarify parameter ordering and the exact month-end convention, but the required information for correct invocation is largely present.

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

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

Schema description coverage is 100%, so the schema already documents both date parameters. The description adds 'birth dates' and mentions month-end handling, but it does not name or further explain date1/date2 semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: calculating years, months, days, and total days between two birth dates. This clearly identifies the operation, though it does not explicitly distinguish itself from sibling tools like date_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 gives input guidance ('Use explicit Gregorian dates and a stated month-end convention') but does not say when to choose this tool over alternatives such as date_calculator. Usage is implied from the age-difference context, not explicitly scoped.

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 destructiveHint=false, so the safety profile is covered without the description. The description adds that it computes two distinct outputs (resting energy vs daily calories), but does not explain that daily calories depend on the activity multiplier. With annotations doing the heavy lifting, 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?

A single, front-loaded sentence with no filler. Efficient, though it omits a lot that would have been worth the words: the method names and the bodyFat requirement for katch.

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 10-parameter tool with complex oneOf/anyOf branch constraints and 60% schema coverage, the description is thin. It never mentions the imperial-vs-metric branching, the method enum, or the activity-level multiplier that drives daily calories. Output schema exists, so return values are exempt, but the input constraints are inadequately conveyed.

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 60%, so the schema already documents some parameters (height, feet, inches, weight, bodyFat, age). The description names formula, activity level and measurements as inputs, which is useful framing, but it does not explain the method enum (mifflin/harris/katch, where katch requires bodyFat) or clarify units handling. It neither compensates fully for the coverage gap nor adds nothing.

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 (Calculate) and resource (resting energy and daily calories), and names the inputs it draws from. It does not differentiate itself from close siblings like body_fat_calculator or bmi_calculator, though the 'resting energy and daily calories' output focus is fairly distinctive.

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 exclusions, and no mention of alternatives. The 'adult measurements' constraint is the only hint at applicability, and the tool does not route agents to bmi_calculator or body_fat_calculator when those are what the user 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral detail — that characters means Unicode characters and bytes means UTF-8 — which clarifies the counting semantics beyond annotations, but it omits ambiguity-relevant behavior such as whitespace/newline handling or grapheme-cluster treatment.

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 with zero filler; the enumerated outputs are the highest-value information and appear immediately.

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

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

For a one-parameter, read-only counting utility with a full output schema, this is nearly complete — the output schema carries the return-value burden and the annotations carry the safety burden. The only residual gap is lack of differentiation from the sibling word_count and unspecified edge-case 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 0% and the single 'text' parameter has an empty description, so the description carries the burden of clarifying input. 'from text' confirms the input is raw text, but adds no format, length-limit, or encoding guidance beyond the schema's own example 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?

States a specific verb ('Count') and enumerates the exact units measured (Unicode characters, words, lines, UTF-8 bytes), so the agent knows precisely what this tool computes. It does not, however, explicitly distinguish itself from the sibling word_count tool, which is the closest overlap in the list.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives. The presence of a sibling 'word_count' makes this gap meaningful — the agent gets no signal about when to pick character_count over word_count (or vice versa).

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 the tool as read-only, idempotent, non-destructive, and not open-world. The description adds that computation is 'exact' and inputs are 'bounded integers', which is useful behavioral context, but the bounds themselves are fully specified in the schema. No contradiction with annotations.

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

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

A single, front-loaded sentence with no filler. Every word contributes to stating the operation and its input constraint.

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?

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. The schema fully documents all three parameters. The main missing element is explicit usage guidance when choosing between combinations and permutations, but the mode enum partially covers that distinction.

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's mention of 'nCr' and 'nPr' loosely maps to the mode enum, and 'bounded integer inputs' gestures at n and r, but it adds no meaning beyond what the schema already provides for each parameter.

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 gives a specific verb ('Compute') and resource ('combinations nCr or permutations nPr'), making the tool's operation unambiguous. It does not explicitly differentiate from any sibling tool, though none of the listed siblings perform combinatorial counting, so the lack of direct naming is minor.

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 offers no when-to-use guidance, no when-not-to-use conditions, and no alternatives. It only states what the tool computes. For a calculator among many sibling calculators, it does not help the agent decide when this is the right tool versus, say, scientific_evaluate or power.

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/openWorld/idempotent/non-destructive, so the safety profile is handled. The description adds genuinely useful behavior beyond them: page text is sent to a language model, there is a small shared free daily allowance without a key, and an X-OpenRouter-Key header lets callers use their own key. That discloses rate-limit and auth behavior an agent needs.

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

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

Two tight sentences: the first front-loads what it does and returns, the second carries the LLM/auth/allowance detail. No filler, and the purpose is stated before the operational caveats.

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, yet the description enumerates the returned fields and their provenance, plus the auth and rate-limit context. For a one-parameter read-only tool with rich annotations, nothing an agent needs to invoke it correctly 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 url field is fully documented, so the baseline would be 3. The description adds meaning beyond the schema by clarifying that the single URL is the entry point and the tool also reads the business's about and contact pages, so the agent understands one homepage URL fans out to multiple pages.

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 precise verb and resource ('Read a business's own home, about and contact pages') and enumerates the exact fields returned, so an agent knows exactly what it gets. It is clearly distinct from calculator siblings, but it never names or differentiates itself from web-fetching siblings like page_check or page_to_markdown, which is the closest ambiguity.

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 when to reach for it (when you need business identity details from a URL), but there is no explicit when-to-use/when-not guidance and no mention of the alternative page tools. The second sentence adds operational context (keys, allowance) but not selection 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered without description help. The description adds only the enumeration of computed outputs, with no extra behavioral context (e.g., rounding, currency, precision behavior) beyond what annotations supply.

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 with no filler; the long output enumeration makes it slightly list-heavy, but every clause maps to something the tool actually produces.

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?

An output schema exists, so return values need no explanation, and the schema carries all parameter detail. The description is complete enough for an agent to call correctly; only the absent sibling-routing and mode caveats keep it from being fully self-sufficient.

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

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

Schema description coverage is 100%, so all eight parameters are already documented in the schema with defaults, ranges and units. The description only paraphrases the top-level inputs (principal, nominal rate, term, deposit timing) and adds no syntax or edge-case detail 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?

The description names a specific verb (Calculate) and resource (compound or simple interest) and enumerates the concrete outputs (balance, total contributed, interest earned, APY, yearly balances) plus the driving inputs. It clearly separates the two modes, though it does not differentiate itself from numerically adjacent siblings such as loan_schedule, roi, or inflation_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 is given. The agent is not told how this differs from loan_schedule or roi, nor any preconditions such as the constraint that simple mode forbids contributions (though that lives in the schema).

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely useful behavioral context the schema does not: results are derived from QUIKRETE No. 1101 yields and bag counts are rounded to whole bags, which tells the agent the numeric basis and rounding behavior of the output.

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 dense sentence with zero filler, front-loaded on the verb and scope. Every clause (shapes, volume, waste allowance, bag counts, yield source) carries distinct information.

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

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

Output schema exists so return values need not be re-explained, and annotations plus full schema coverage handle the mechanics. The description still supplies the calculation basis (QUIKRETE No. 1101) and shape coverage for an 11-parameter tool; only an explicit routing note toward generic volume tools 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 description coverage is 100%, so all 11 parameters (unit, count, waste, steps, rise, run, etc.) are already documented in structured data. The description mentions the shape families and waste allowance but adds no syntax, defaults, or unit detail beyond the schema; 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 ('Computes') with a precise resource set: slab/footing/cylindrical-column/solid-step concrete volume, waste allowance, and whole 40/60/80 lb bag counts. It is immediately distinguishable from near-siblings like volume_calculator or gravel_calculator, which do not produce bag counts from a named mix yield.

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 shape list and concrete-specific scope imply when the tool applies (concrete pour estimates), but there is no explicit when-to-use statement or named alternative such as volume_calculator for non-concrete volumes. Usage is inferable but not stated.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioural detail beyond that: results are signed (direction matters) and month arithmetic clamps at month end, neither of which appears in 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?

A single front-loaded sentence that pairs each mode with its defining behaviour and wastes no words. Both branches are covered in one compact clause each, which is exactly the right size for this 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers both modes plus clamping, leaving only minor gaps such as inclusive-endpoint defaults (which the schema already documents) and explicit 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% and every parameter (mode, start/end, date/amount/unit, inclusive, weekdaysOnly) is documented in the schema itself. The description restates the concepts of weekdays and calendar units without adding format, default, or edge-case semantics beyond what the schema already provides, 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?

The description names a specific verb pair (count / add-subtract) and the exact resource (calendar days, weekdays, calendar units), and it distinguishes the two operating modes ('between' vs 'shift') that the schema's oneOf encodes. It is nearly enough to separate it from neighbours like calendar_age_difference or julian_day_convert, though it never names 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?

Usage is implied rather than stated: the reader can infer that date-range counting uses the 'between' branch and arithmetic uses the 'shift' branch. There is no explicit when-to-use/when-not guidance and no routing away from overlapping siblings such as calendar_age_difference, so an agent must infer selection from the schema.

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

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

Beyond the annotations (read-only, idempotent, closed-world), the description discloses deterministic behavior: rounding half up to two decimals, returning the sum plus the ratio percentage, and explicitly omitting comparison bands or classification. It does not mention error behavior for invalid income, but the added behavioral detail exceeds the annotation baseline.

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?

One dense sentence front-loads the arithmetic scope and then the output/rounding behavior; every clause carries information. Slightly packed, but nothing is redundant or padded.

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 calculator with an output schema, the description covers inputs, the operation, and the rounding/output shape. Missing only edge-case handling (e.g., non-numeric or over-limit inputs), which the schema largely constrains already.

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 are already documented, including numeric limits and the empty-array-means-zero rule. The description adds the count cap ('up to 100 payments') and 'positive' income, both of which mirror schema constraints 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?

Names a specific verb+resource (sum monthly debt payments and divide by gross monthly income) and states the scope 'arithmetic on entered numbers only', which separates it from fetch/classification-style siblings. The clause 'no comparison bands or classification' further distinguishes it from other ratio-style tools an agent might consider.

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 'entered numbers only' implies when this tool applies (user-supplied figures, not looked-up data) and rules out classification workflows, but no alternative sibling is named and there is no explicit when-not guidance. Usage is implied rather than stated.

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, destructiveHint=false and openWorldHint=false, so safety and determinism are covered. The description adds that the result is 'exact' and 'simplified' and produces multiple display forms, which is modest added context. It doesn't disclose error behavior (e.g., what happens for non-terminating non-repeating input), but with annotations covering the safety profile 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?

A single front-loaded sentence that names the conversion and the outputs with no filler. Appropriately sized for a one-parameter utility, though it could have used a second short sentence to route among siblings without bloat.

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?

An output schema exists, so return values (fraction, mixed number, decimal display) need no elaboration, and annotations cover the safety/idempotency profile. The only meaningful omission is guidance on invalid or ambiguous input and on sibling selection, which keeps it just short of 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%, and the schema itself richly documents the notation (0.125, 0.(3), 0.1(6), bars, and the '...' convention) with an example. The description only echoes the accepted input category, adding no syntax or format detail beyond the schema. Baseline 3 applies when the schema carries the parameter documentation.

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

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

States a specific verb (converts) and precisely scopes the resource: a 'terminating or explicitly repeating decimal'. It also names the three output forms (exact simplified fraction, mixed number, decimal display). It does not explicitly contrast with siblings like fraction_calculator or round_decimal, but the input/output scoping makes the tool's role 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 is only implied through the input description ('terminating or explicitly repeating decimal'). There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., fraction_calculator for fraction arithmetic, round_decimal for rounding). An agent must 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 destructiveHint=false, so safety is covered. The description's genuinely additive detail is the computation order (discounts stacked in sequence, tax applied after discounts), but the schema's discount and tax field descriptions already state this ordering and the cent rounding, so the gain over structured fields is modest. No return format or edge-case behavior (e.g., zero price) is disclosed.

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

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

A single front-loaded sentence with no filler, opening on the primary action. It is dense and slightly awkward to parse ('ordered stacked percentage discounts ... total with an entered sales tax percentage'), but nothing is wasted and no critical clause is buried.

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 full schema coverage, all annotations present, and an output schema covering the returned values, the description only needs to frame the operation and it does. A stronger version would add a one-line routing hint against the other calculator siblings, but nothing required to call it correctly 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 description coverage is 100% with numeric bounds and an example, so the schema fully documents price, discounts, and salesTaxPercent. The description merely restates them in prose ('entered sales tax percentage', 'stacked percentage discounts') without adding format or constraint information beyond the schema.

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

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

States a specific verb and resource (calculate a discounted price) and enumerates the concrete outputs: stacked discounts, savings, effective discount, and tax-inclusive total. That is enough to separate it from siblings like percentage_calculator or tip_calculator, though the description never names an alternative to sharpen the distinction.

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 and no exclusions. An agent facing percentage_calculator, unit_price, or margin_calculator gets no signal about which one applies to an ordered multi-discount scenario; the tool's niche is implied solely by the word 'stacked'.

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 read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower; the description still adds that it is 'pure arithmetic, no network or model' and discloses what is not priced and what dated sources back the ranges.

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

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

Four compact sentences, front-loaded with the core estimate purpose and then the scoping caveats. Dense but each clause carries information, though 'Includes unpriced checks' is vague relative to its neighbours.

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

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

No output schema exists, and the description compensates by describing the return as national installed ranges with no typical figure plus two reference cards and dated sources. Slightly imprecise about result structure, but sufficient 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 surface, existing and sections are already fully documented, and the description largely restates them ('for a given size', removal only for existing concrete). Baseline 3 is appropriate where 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?

States a specific verb and resource ('Estimate driveway replacement costs') scoped by size, and distinguishes itself from surface-adjacent siblings (concrete_calculator, flooring_cost, fence_cost) by naming the ten surfaces it compares in one call.

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?

Gives clear context: one call compares all ten surfaces, and it explicitly scopes out base, drainage and permits, and limits removal pricing to existing concrete. It stops short of naming a sibling alternative to use instead, but the exclusions make the right call obvious.

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

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior. The description adds genuinely beyond that: it discloses automatic unit detection by magnitude and that zone-less strings are interpreted in the supplied zone, plus the guarantee of no network/model/clock dependence. It stops short of describing output shape or error behavior.

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

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

Three tight sentences with the core action front-loaded and details following in descending priority; no filler sentences. Dense but each clause (unit detection, zone defaults, output list) carries information.

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

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

With no output schema, the description correctly enumerates the returned values (epoch seconds, epoch ms, ISO UTC, same moment in tz, weekday). Combined with the 100%-covered schema and affirmative annotations, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so a 3 is the baseline, but the description adds real interpretive rules: numeric values are auto-detected as seconds or milliseconds by size, and the zone applies both to zone-less date strings and to the tz-relative outputs. That interaction between tz and value is the kind of semantics the schema only partially 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?

States a specific verb and resource ('Convert between Unix timestamps and dates') and enumerates the exact conversion direction and outputs. It is easily distinguished from neighbors like julian_day_convert, date_calculator, and hours_calculator without opening any schema.

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

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

The description implies the use case (converting epoch <-> ISO dates) but never names when to prefer this over date_calculator or julian_day_convert, nor any exclusions. The 'Pure standard-library rules, no network, model or clock' note gives useful context about determinism but is not 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 readOnly/idempotent/non-destructive/closed-world, but the description adds real context beyond them: reference cards are DOE/utility figures and not a price for this home, the tool is pure rules/Decimal with no network/model/clock, and web and MCP share a free daily allowance (rate-limit 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?

Purpose is front-loaded in the first sentence and the following sentences carry distinct caveats (reference-figure disclaimer, licensing, determinism, rate limit). It is dense but each sentence contributes; no obvious 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?

With no output schema, the description carries the burden of describing returns, and it does list them (safety first, breaker calc, panel triage, unpriced extras, 30C rules). Zero required parameters is not clarified, but otherwise it is complete enough to call 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 89%, so the schema already documents nearly all nine parameters in detail. The description adds domain framing (125% minimum breaker calculation, panel triage, unpriced extras, dated 30C rules) but no parameter syntax beyond what the schema provides, 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 verb-and-resource set: work out the required circuit, panel triage, utility install cost references, and federal 30C credit rules for a home EV charger. It is clearly distinguished from generic cost siblings by its EV-charger scope, though it does not name any sibling it competes 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 or routing against alternatives among the many *_cost siblings. The only guidance is a caveat that a licensed electrician and permit are needed, which is a disclaimer rather than a usage 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so credit goes to the added context: 'Pure standard library, no network or model', the labeling/counting behavior, file-order output, and the 2,000-string cap. Input validation and failure modes (bad base64, oversized file) are not stated.

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

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

Front-loaded with purpose in the first clause, and every clause carries information (extraction rule, labeling, filtering, limits, no-network stance). It is one very dense run-on sentence, which slightly hurts scanability, but there is no padding.

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 carries the return burden and does cover labels, counts, ordering, byte offsets and the list cap, which is good. However it omits error/failure behavior for malformed base64 or truncated input and does not explain the interaction between encodings and false positives beyond a schema-level remark.

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, and the description largely paraphrases it (kinds filtering, counts covering all, default/max limit, case-insensitive contains, encodings). The one genuine addition beyond the schema is that results carry byte offsets, which is return-shape information rather than parameter semantics.

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

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

Names a specific verb and resource ('List the readable text inside any file') and immediately scopes it with the input format (base64) and extraction rule (runs of ASCII/UTF-16LE characters). This clearly separates it from adjacent siblings like inspect_binary, inspect_apk, find_data and get_transcript.

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

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

The description implies the use case (pulling readable strings out of a binary/blob) and states the 2,000,000-byte ceiling, but never explicitly says when to choose this over inspect_binary, inspect_apk, or find_data, nor what happens with a non-base64 or oversized input. Usage is inferable but not routed.

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 safe, idempotent, non-destructive read with no open-world access, so the safety profile is covered. The description goes further by disclosing the data provenance (exact City of Sunrise FL 2020 municipal bid rows), the return structure (low/median/high bid bounds plus scope, sources, and permit guidance), and an explicit accuracy caveat about historical bids.

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 the core purpose before the data-source and caveat details. Dense but every clause carries signal; only mild compression is possible.

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 carries the burden of describing returns (low/median/high bounds, scope, sources, permit guidance) and sets expectations about data vintage. It is nearly complete, though it omits any note on how unsupported inputs (e.g. local_quote gates) are handled in 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% and the enum values are self-documenting, so the baseline is 3. The description's 'net non-gate length and gate widths' merely restates what the schema already says (including 'do not subtract them again'), adding no format or unit detail beyond the structured fields.

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

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

States a specific verb ('Estimate') and resource ('fence and gate costs') plus the exact inputs it works from (net non-gate length, gate widths). This cleanly separates it from cost siblings like driveway_cost, flooring_cost, and roof_replacement_cost without the agent needing to open the schema.

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 calculator framing, and the closing caveat ('Historical public bid observations are not current homeowner prices') usefully bounds when the output is appropriate. However, it never states when to prefer this over sibling cost tools or what inputs make it unsuitable (e.g. non-Sunrise-FL locations, unsupported materials).

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 (readOnly, idempotent, non-destructive, closed-world). The description adds the key behavioral trait that this is a static/offline plan rather than a live lookup, which is valuable context beyond annotations. However, it doesn't describe output format, limits on the three sources, or how resale clause data is sourced.

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 the primary purpose, then defaults. Efficient and readable, though the plan-content list is somewhat dense and could be trimmed.

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-param tool with an output plan and no output schema, the description explains what the plan contains and the defaults, which is adequate. It leaves gaps on parameter formats and the boundary of the three-source limit, preventing a high score.

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 only 25%, with three of four parameters (geo, resell, volume) undocumented in the schema. The description partly compensates by stating defaults for volume, geo, and resell, but doesn't clarify expected geo format (country, state, city?) or the business meaning of volume/resell. Baseline 3 is warranted given the schema gap is partially offset.

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

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

The description clearly states the tool produces a 'full Data Finder plan' for up to three data sources, enumerating the plan contents (fit, cost, resale terms, URL/read date, DIY guidance). This is a specific verb+resource, though it doesn't differentiate from any sibling tool by name — unsurprising given the siblings are mostly unrelated calculators.

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

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

It gives clear context: 'No live source lookup' sets the expectation, and the defaults (volume 0, US, no resale) tell the agent what happens when args are omitted. It stops short of saying when to prefer this tool over alternatives, but the non-live nature is 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, no-network behavior (openWorldHint=false), and the description corroborates 'pure arithmetic, no network or model.' It adds genuine behavioral detail beyond annotations: output shape (installed ranges only, no labor-only or typical figure), hardwood order guidance, an unpriced prep checklist, a Census reference card, and dated sources. With no output schema, this disclosure is valuable.

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 core purpose and no filler sentences. The later clauses are densely packed comma-separated lists, slightly run-on, but each conveys distinct information about outputs and comparisons.

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 calculator with 100% schema coverage, no output schema, and annotations covering the safety profile, the description supplies the needed return-value context (ranges, omitted figures, extras like prep checklist and sources). Nothing critical to correct invocation is missing, though layout's non-effect on the estimate could be restated.

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 rooms, layout, and material semantics including the net-area rule. The description's mention of 'net room area' and hardwood order guidance aligns with but does not meaningfully extend the schema, 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?

States a specific verb (Estimate) and resource (installed flooring costs) with scope (given room sizes). Distinguishes itself from cost siblings like concrete_calculator, paint_quantity, and driveway_cost by naming flooring specifically and its national installed-range output.

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 'One call compares all eight materials' implies usage (avoid multiple calls) and the returned/not-returned figures clarify scope, but no explicit alternative tools or when-not conditions are named. Usage is implied rather than stated.

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 destructiveHint=false, so the safety profile is covered externally. The description adds nothing beyond this: it does not explain how non-letter characters (e.g. '123!' in the example) are handled, whether output is deterministic per style, or any behavioral nuance. With annotations present, the bar is lower, but the description contributes no additional context.

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

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

A single, front-loaded sentence with no filler, so it is efficiently structured. It is arguably under-specified rather than over-long, but there is no 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?

The tool is simple (2 required params, one enum) and an output schema exists, so return values need not be described. However, with 0% schema description coverage and no clarification of edge cases like digits, punctuation, or unsupported characters, the description leaves real gaps 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 0% – both 'text' and 'style' have empty descriptions and only an example and enum list to work from. The description's phrase 'selected Unicode letter style' loosely points at the style parameter but adds no meaning about accepted input for 'text' or how the 16 enum styles differ. It does not compensate for the coverage gap.

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 ('Convert') and resource ('text' → 'Unicode letter style'), which is concrete and unambiguous. It implicitly distinguishes itself from siblings like word_count or character_count, though it never names an alternative. Clear but without explicit sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or constraints. An agent must infer the use case entirely from the purpose sentence.

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, non-destructive and closed-world, so the safety profile is fully covered without the description. The description adds one genuinely useful behavioral detail — that results are 'exact' and returned as simplified, mixed, and decimal forms — but since an output schema exists, this is modest added value.

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-formed sentence that front-loads the operation and resource before the output detail. There is no filler and every clause carries information.

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

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

With rich annotations, a fully documented 3-parameter schema, and an output schema covering return values, the description is nearly sufficient for an agent to call this correctly. Only the absence of any routing hint toward sibling tools keeps it from being 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 a, b, and the operation enum with its default. The description adds nothing about accepted input syntax beyond what the schema's 'integer, fraction, decimal or signed mixed number' wording already provides; 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?

The description gives a precise verb (computes) plus the exact resource and supported operand types (fractions and mixed numbers), and enumerates all four operations. It clearly separates this arithmetic tool from conversion siblings like decimal_to_fraction, though it never names an alternative explicitly, keeping it just 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?

Usage is only implied by the tool's nature — an agent can infer 'use this to do fraction arithmetic' but the description states no conditions, prerequisites, or when-not-to-use guidance. No alternative tool (e.g., decimal_to_fraction, round_decimal) is mentioned for related tasks.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing behavioral beyond that — no note that this is a pure offline arithmetic computation with no external data or rate lookups (that detail sits in the schema's currency field instead).

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-formed sentence that front-loads the core action and appends the supported unit systems. Every clause 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 deterministic, stateless arithmetic tool with full annotation coverage, a complete output schema, and 100% schema description coverage, the description supplies everything needed to invoke it correctly. Return values need not be explained since an output schema exists.

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 five parameters (including the units enum and the conditional mile-vs-kilometer semantics) are already documented in the schema. The description restates the parameter list without adding syntax, defaults, or edge-case guidance 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?

States a specific verb and resource ('Calculate trip fuel quantity and cost') and enumerates the exact inputs it consumes (distance, fuel economy, price, currency). The supported unit systems (US mpg, L/100 km, km/L) make it clearly distinct from generic siblings like unit_convert or unit_price.

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 narrow purpose — an agent can infer this is the tool for fuel cost estimation — but the description names no alternatives and gives no explicit when-to-use or when-not-to-use guidance. The only exclusion ('Imperial mpg not accepted') lives in the schema, not the 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 only cover safety and idempotency, and the description adds real behavioral context well beyond them: output ordering (FTC Funeral Rule rights returned first), data provenance (NFDA 2023 medians from an industry member survey), that missing prices are kept visible rather than dropped, that it is pure rules with Decimal money and no network or model calls, and that web and MCP share a free daily allowance (a quota constraint).

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 core purpose is front-loaded in the first sentence, and each following sentence adds a distinct fact (ordering, provenance, bundle applicability, missing-price handling, quota). It is slightly dense and a phrase like 'Pure rules and Decimal money' is terse, but nothing is truly redundant.

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 carries the return-value burden and does explain ordering (rights first) and what the worksheet produces. It does not sketch the shape of the returned reference-cost data or clarify that only disposition and service are required while prices is optional, but it is otherwise sufficient for an agent 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 description coverage is 75% and the nested prices object documents all 16 line items with their applicability rules, so the schema does the heavy lifting. The description echoes the omit-vs-zero convention ('keeps missing prices visible') but adds no syntax or format detail beyond it; its viewing-vs-direct nuance concerns which reference figures are shown rather than how to fill the 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 names three specific deliverables with distinct verbs: showing consumer rights, showing national reference costs, and summing a funeral home's itemized prices. That is precise enough to separate it from the home-project cost estimators (driveway_cost, roof_replacement_cost, etc.) sharing the toolset, which only compute a single figure.

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 clear context for when the results apply (bundle cards only for services with viewing; direct services have no national bundle figure) and warns that the figures are national medians, not local prices, so an agent knows when the reference data is inappropriate. There is no explicit when-to-use-vs-alternative statement, but no sibling covers funeral planning, so the gap is minor.

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, non-destructive behavior, so the description's job is to add computation context, which it does: it keeps NAHB and InterNACHI life guidance separate, applies EPA age guidance, uses the DOE repair comparison against user-supplied quotes, and returns historical vs. modeled references as distinct labels. It does not explain the response shape or how the labeled references are structured, which keeps it below 5.

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 dense sentence that is front-loaded with the core purpose (estimate furnace age from serial or confirmed date) followed by side-effect details. Every clause carries information, though the sentence is long enough that it reads as a run-on rather than crisply sectioned 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?

For a 9-parameter, no-output-schema tool, the description covers the key inputs (serial format confirmation, maker-confirmed date override) and the nature of the output (separately labeled historical and modeled replacement references). It stops short of describing the return structure in any detail, which leaves a modest gap given there is no output schema.

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

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

Schema description coverage is 100%, so parameter documentation is already handled by the schema. The description reinforces the confirmation requirements (format_confirmed, maker-confirmed century/date) and the separation of the two quote inputs, but adds no format or syntax detail beyond what the schema already provides; baseline 3 is appropriate.

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

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

States a specific verb (estimate) and resource (furnace manufacture age) and scopes it to enumerated serial formats (Lennox legacy, Rheem, Nordyne) plus a maker-confirmed date fallback. No sibling tool covers furnace age, and the input conditions are clear enough that an agent can distinguish it from generic calculators like calendar_age_difference.

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

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

The description implies the required preconditions for use: a confirmed serial format or a maker-confirmed manufacture date, and other brands requiring dealer confirmation. It gives clear context for when the tool applies but does not explicitly state exclusions or when a different tool should be used instead.

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

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

Annotations already declare the safe-read profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description's added value is in disclosing arithmetic behavior: exact BigInt precision (no float error) and that prime factorizations are also returned. That is genuinely useful context beyond what annotations state, though it stops short of noting edge cases such as negative operands.

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 with zero filler; the operation, its input scope, and its precision/derived-output characteristics are all packed in without repetition.

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

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

For a one-parameter, deterministic math tool with a fully documented schema and an output schema present, the description covers everything needed: op, input domain, arithmetic guarantees, and that factorization output accompanies 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%, and the schema already documents the ±10^12 bound, the string-of-digits format, and the 2–20 item constraint. The description restates the 2–20 range but adds no format or edge-case 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 verb and resource ('Compute the greatest common factor'), plus concrete scope ('2–20 integers') and method ('exact BigInt arithmetic and complete prime factorizations'). It does not explicitly name the natural sibling lcm_calculator, but the resource is self-distinguishing from the rest of the math siblings.

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

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

Usage is implied by the self-explanatory name and purpose; an agent can infer this is the tool for GCF computations. However, there is no explicit when-to-use guidance and no mention of lcm_calculator as the alternative for the complementary operation, so nothing routes the agent deliberately.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new constraint context beyond them: only public videos are accessible, and no video/audio is fetched, only text captions. It stops short of describing failure modes (private videos, missing caption tracks) or rate limits.

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

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

Two short sentences, output scope front-loaded, no redundant restatement of the title or schema. Every clause carries information.

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

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

For a two-parameter read tool with full schema coverage and rich annotations, the description is nearly sufficient, and it even gestures at the return shape ('timestamped plain text') despite no output schema. Only error/fallback behavior when no captions exist is unaddressed.

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 (url with its video-id form, lang with its fallback behavior) are already fully documented in the schema. The description adds no parameter-level detail beyond the 'public' qualifier, 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 verb (Read) and resource (public YouTube captions) plus the output form (timestamped plain text), which is far more precise than the sibling calculators. It does not name a sibling alternative, but the 'captions only, no video or audio' clause effectively separates it from media-download or page_to_markdown tools.

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

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

'Read public YouTube captions' implies the applicable case (a YouTube URL with public captions) and the exclusion of video/audio, but there is no explicit when-to-use statement or routing to alternatives such as page_to_markdown for non-YouTube pages. Usage is inferable rather than stated.

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, non-destructive behavior. The description adds meaningful calculation behavior: the exact grade mapping, optional honors/AP bonuses for passing grades, and a caveat that school conventions vary. This goes beyond the safety profile in 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?

A single, front-loaded sentence with no wasted words. It packs the core formula, bonus rules, and caveat efficiently.

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

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

Given the low complexity, existing output schema, and rich annotations, the description is nearly complete for calling the tool correctly. The main gap is the absence of explicit usage guidance or sibling differentiation, which is minor for a simple calculator.

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

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

Schema description coverage is 50%, so the description must add meaning. It contributes the bonus values for honors and AP levels (+0.5 / +1.0) and clarifies that credit weighting is used, which are not fully documented in the schema's level or top-level parameters. It partially repeats the grade scale already detailed in the schema.

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

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

States a specific verb (computes) and resource (credit-weighted GPA), and includes the base scale and bonus conventions. It is clear what the tool does, but it does not distinguish itself from likely siblings such as grade_calculator or average_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 offers no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Usage is only implied by the tool name and purpose statement.

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 safe, read-only, idempotent, closed-world computation, so the safety profile is fully covered elsewhere. The description adds only the dual computation modes and says nothing about edge cases (unreachable targets, weight totals not summing to 100, or exceeding max scores), which is mild added value over 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?

A single front-loaded sentence that leads with the primary computation and appends the optional mode. No preamble, no filler, every clause carries information.

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

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

With an output schema present the description need not explain return values, and annotations cover the safety profile, so the remaining burden is modest. It covers both computation modes adequately but does not clarify the schema's anyOf pairing constraint (target + finalWeight together) or behavior when the target is unreachable, leaving a small gap.

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

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

Schema description coverage is 67%, above nothing but well below the 80% threshold where the schema would clearly carry the load. The description restates the meaning of 'target', 'finalWeight', and weighted categories at a high level but adds no format, unit, or constraint detail (e.g., the anyOf rule that target and finalWeight must be supplied together) 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 a specific operation (weighted category average) plus an optional secondary output (final-exam percentage needed to hit a target), which uniquely separates it from generic calculators like average_calculator or percentage_calculator. It never names a sibling explicitly, so it stops 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 word 'optionally' signals that the final-exam calculation is conditional, giving implied usage guidance for the two modes. However there is no explicit when-to-use, when-not-to-use, or pointer to the closest alternatives (gpa_calculator, average_calculator) for the agent 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that bulk density is editable and that output is in US short tons, which is useful context, but it omits anything about the density default-dependency or how results vary with unit selection.

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 with no filler; the primary action and output are stated first. It is dense but every clause (input shapes, depth, density) carries information.

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

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

Output schema exists, so return format need not be explained, and the schema fully covers parameters. The description mentions the shape options, units, depth, and density, giving an agent enough to invoke it correctly, though it lacks guidance on when gravel versus adjacent calculators apply.

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 eight parameters are already documented in the schema, including depth units, area semantics, and density default. The description only restates a few of these (depth in inches, editable density) without adding syntax or format detail 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 verb (Calculate) and resource (gravel layer volume and US short tons), plus the three supported input modes (rectangle, circle, total area). It is clear what the tool does, though it does not explicitly differentiate itself from close siblings such as mulch_calculator or concrete_calculator, which an agent might 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?

The description enumerates supported input shapes but gives no when-to-use guidance, prerequisites, or exclusions relative to the many other volume/cost calculators in the sibling list. Usage must be inferred entirely from the tool name and inputs.

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 only cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds substantial behavior beyond that: secret redaction of cookies/login headers/secret-named fields, host/method/path-template grouping, parameter and schema inference, sign-in method naming, exclusion of static assets and preflights, and the guarantee of no network, model or clock use.

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 purpose is front-loaded in the first sentence, and the remaining sentences each carry distinct, non-redundant behavioral facts (cleaning rules, grouping, inference, exclusions, output form, environmental guarantees). No 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?

With no output schema, the description still states the return value ('the OpenAPI document as JSON and the endpoint count'). Combined with the input constraints and the safety/behavior disclosures, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so baseline is 3, but the description reinforces parameter meaning in prose: 'example values are off unless asked for' maps to the examples flag and 'leaves out page loads, static files and preflights unless asked' maps to include_static, plus the host scoping. It clarifies consequences of the toggles rather than just restating them.

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 precise verb and resource: converting a HAR network export into an OpenAPI 3.1 description. It is unmistakably distinct from every sibling tool (converters, calculators, formatters), so an agent can select it without ambiguity.

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 clearly frames the input context (a browser network export) and the default-on/default-off conditions ('unless asked', 'off unless asked for') that govern output. There is no true sibling alternative to route against, so no explicit alternative is needed, but there is also no explicit when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds the meaningful scope detail that it derives both max HR and moderate/vigorous zones from age plus optional measured rates, but says nothing about the formula choice or the resting-below-max constraint.

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 that states the action, the primary output, and the inputs with no filler or redundancy. Nothing is wasted.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a 4-parameter tool where the method enum and the relationship between resting and measuredMax drive the result, the description omits guidance an agent would need to invoke it optimally.

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 75%, below the high-coverage baseline, and the 'method' enum (220 vs tanaka) has no description in either schema or prose — a material choice for a heart-rate calculator that goes unexplained. The phrase 'optional measured rates' loosely gestures at resting/measuredMax but does not clarify their distinct roles.

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 (calculate) and concrete resources (adult maximum heart rate, moderate and vigorous target zones) plus the inputs (age, optional measured rates). It is easily distinguished from numeric siblings like bmi_calculator or one_rep_max_calculator, though it never explicitly names 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?

Usage is implied by the calculator framing — an agent infers it applies when a user wants HR training zones — but there is no explicit when-to-use, when-not-to-use, or pointer to related tools. Adequate but leaves 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 the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description carries a light burden. It adds that the break is unpaid and that the calculation depends on the overnight flag, but discloses no computation edge cases, rounding rules, or limits beyond what the schema already states (e.g. max 24 hours).

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 20-word sentence, front-loaded with the verb and the outputs. No filler, no repetition; every clause maps to a real part of the tool's contract.

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 deterministic calculator with 100% schema coverage, an output schema, and annotations covering safety, the description supplies enough to call it correctly. The one real omission is disambiguation from time_card_calculator, which an agent facing this sibling set would benefit from.

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 all four parameters documented, so the baseline is 3. The description restates the same four inputs (clock times, overnight flag, unpaid break) without adding format, range, or interaction semantics beyond the schema, such as what happens when the computed shift crosses midnight without the overnight flag.

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 (calculate) and concrete outputs (worked minutes, decimal hours, H:MM) from identifiable inputs (clock times, overnight flag, unpaid break). An agent can tell this is a shift-duration calculator. However, it does not distinguish itself from the very similar sibling time_card_calculator, which also produces hours worked from clock times.

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 exclusions, and no routing to alternatives. This matters here because time_card_calculator sits in the sibling list doing an overlapping job, and the description gives the agent no basis for choosing between 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real value beyond them: the failure behavior ('unavailable periods are rejected'), the mode switch, and a scope disclaimer ('not financial advice').

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 dense sentences, front-loaded with the core action, then outputs, then the mode rule and caveat. No wasted words, though the output enumeration is slightly list-heavy for a single 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?

An output schema exists, so return values need not be explained, yet the description still names them helpfully. Modes, rejection behavior, and scope caveat are all present; only parameter-level detail is thin, which is the main residual gap.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the startMonth/endMonth annual-vs-monthly rule, which is meaningful given the oneOf constraint, but says nothing about amount or the start/end year semantics. Partial compensation only.

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 (convert) and resource (US dollars via BLS CPI-U) with a clear scope boundary (since 1913). It is unmistakably distinct from adjacent arithmetic siblings like compound_interest_calculator or calendar_age_difference.

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

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

Tells the agent how to drive the two modes ('Omit both months for annual mode') and that unavailable periods are rejected. It gives clear operational context but never names when to prefer an alternative tool, so it falls short of full when/when-not routing.

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 safe read profile, and the description adds genuinely useful context beyond them: 'Runs nothing. Pure standard library, no network or model' and the certificate is 'read but never verified.' The safety-critical nuance that signing is inspected but not validated is exactly the kind of disclosure an agent needs.

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

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

A single dense paragraph with the input contract front-loaded and the return surface enumerated after. Every clause carries information, though the long enumeration of return fields is on the heavy side.

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 compensates by listing every returned artifact (package metadata, grouped permissions, exported components, host-grouped URLs, signer certificate fields). An agent knows precisely what to expect from a call.

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, but the description adds meaning by pinning the constraint to the decoded size ('at most 2,000,000 bytes') and calling out that input may be base64 or a data URL, clarifying the required 'file' param beyond the schema text.

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 ('Read') and resource ('.apk') and immediately enumerates exactly what it returns (package/version/SDKs, permissions, components, URLs, signer). It is distinguishable from generic siblings like inspect_binary and extract_strings because it specializes on Android APK structure.

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 the input contract (base64 APK, max size) but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as inspect_binary or extract_strings despite their overlap with the string-table feature described here.

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 non-destructive, yet the description adds substantial behavioral context: 'Reads headers and tables only; runs nothing,' certificate/signature presence is 'never checked,' and it is 'pure standard library, no network or model.' The one shortfall is that it does not describe failure behavior or the exact return shape, keeping it short of 5.

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 purpose and format scope, then returns, then safety constraints; every clause carries information. It is dense and slightly overpacked into two long sentences, but there is no 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?

With no output schema, the description fully enumerates what the tool returns (format, type, architecture, bitness, entry point, sections with offset/size/address/flags/entropy, imports/exports, resources, signature presence, .NET flag). Nothing an agent needs to call it correctly 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 description coverage is 100%, so all three parameters are already documented, and the description largely restates the size cap and format list. Baseline 3 applies since the description adds little semantic detail 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?

States a specific verb ('Read the structure of') and resource ('a program file') and enumerates the exact accepted formats (PE, ELF, Mach-O, thin/universal). This clearly separates it from siblings such as inspect_apk, extract_strings, and find_data, which operate on different inputs or produce different outputs.

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 rich input constraints (base64 encoding, 2,000,000-byte cap, supported formats) which implicitly tell the agent when the tool applies, but it never names an alternative or states when to prefer inspect_apk, extract_strings, or find_data instead. Usage is therefore implied rather than directed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait -- 'preserving number tokens' -- warning that numeric literals will not be coerced or reformatted, which is exactly the kind of context annotations cannot convey.

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 with no filler; every clause (the three actions, the resource, the number-token caveat) carries information. Nothing is repeated from the schema or annotations.

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

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

Complexity is low, an output schema exists so return values need no explanation, and annotations cover the safety/idempotency profile. The remaining gap is the ambiguous 'sort' parameter, but the description plus structured fields are sufficient to invoke 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 description coverage is 0%, so the description must compensate. It partially does: naming format/minify/validate gives meaning to the 'action' enum beyond the bare values. However, 'sort' (keys vs values? ordering?) and 'indent' applicability are left entirely undocumented, so only one of four parameters is clarified.

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 (format, minify, validate) against a specific resource (JSON text), which is unambiguous. No sibling tool does JSON processing, so the scope is inherently distinguished, though the description does not need to route anywhere.

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 three modes are named but there is no guidance on when to pick format vs minify vs validate, no prerequisites, and no when-not-to-use context. The agent must infer all selection logic from the action enum in the schema.

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

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

Annotations already establish readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description contributes the convention context ('explicit UTC', 'proleptic Gregorian'), but the second sentence is only a dangling pointer ('See the noon epoch, time-scale convention and ordinal day') that never explains the rules it names.

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 first sentence is well front-loaded and wastes nothing. The second sentence gestures at concepts ('noon epoch', 'ordinal day') that appear nowhere else, so it consumes space without delivering usable information.

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

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

An output schema exists so return values need no explanation, and annotations plus a 100%-documented schema carry most of the load. What remains unstated is the accepted timestamp string format beyond the single ISO example, and the referenced conventions are left unexplained, making the definition only minimally adequate.

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

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

Schema description coverage is 100%, so value, direction and convention are already documented with ranges and enum values. The description repeats the convention theme but adds no rules 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 verb (convert) and resource (UTC civil timestamps <-> Julian day) plus the calendar basis (proleptic Gregorian). It is clearly a two-way conversion, but it never names or contrasts with the obvious sibling epoch_convert, leaving the agent to work out the boundary itself.

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 and no mention of the sibling epoch_convert, which performs a closely related date conversion. The agent must infer that this tool is for Julian day values specifically and epoch_convert for Unix epoch values.

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, idempotent, closed-world and non-destructive behavior, yet the description adds real context beyond them: the operation is 'pure arithmetic, no network or model', the output is a range rounded to the nearest $100, and it returns two dated reference cards with sources. It does not discuss error handling for out-of-range inputs, which keeps it from a 5.

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 purpose is front-loaded, but the middle sentence is garbled ('with no published typical figure, two separate dated reference cards and sources') and the no-line-items point is restated across sentences 2 and 3. Roughly a third of the text is redundant or unclear phrasing.

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 carries the return-value burden and does so: it states the shape (a rounded range), the provenance (dated reference cards and sources) and the key limitation (no line items or labor/material split). Inputs, output and behavior are all covered, leaving only edge-case behavior unstated.

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% — the enum bands, area bounds (20–1,000 sq ft) and the length/width exclusivity rule are all fully documented in the schema. The description only loosely maps 'finishes' onto the scope enum and adds no syntax or format detail beyond what is already structured, 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?

The opening sentence gives a precise verb and resource ('Estimate a kitchen remodel budget') and names the inputs ('kitchen size and finishes'). Within a sibling set full of *_cost calculators (driveway_cost, flooring_cost, roof_replacement_cost), the kitchen-remodel domain makes the selection unambiguous without needing to open the schema.

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 statement or named alternative, but the description implies its role as a planning-stage estimator ('national planning estimate') and supplies a negative constraint: it will not give line items or a labor/material split. That implicit scoping is more than nothing but falls short of explicit 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 readOnly, idempotent, closed-world and non-destructive behavior, so the safety profile is covered. The description adds genuine value beyond that by disclosing exact BigInt arithmetic (no floating-point rounding) and that outputs include complete prime factorizations, which an agent cannot learn from 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?

A single sentence that front-loads the operation, the input bounds, and the two notable behavioral traits before any trailing detail. Zero filler and nothing redundant.

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 an output schema present, return values need no explanation, and the annotations cover the safety profile; the description usefully supplements with precision and scope. Only minor gaps remain, such as what happens on out-of-range or non-integer input, which the schema pattern implies but does not state.

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%: the single parameter already documents the ±10^12 range, the no-separators/no-exponents rule, and exact BigInt parsing. The description's "2–20 integers" merely restates the schema's minItems/maxItems, adding no syntax or format detail beyond it, 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 verb ("Compute") and resource ("least common multiple") with an explicit input scope of 2–20 integers, so an agent can tell what the tool returns. It does not, however, distinguish itself from the closely related sibling gcf_calculator or from prime_number_checker, which share the same numeric domain.

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 2–20 integer scope implicitly signals when the tool applies, but the description never states when to prefer it over gcf_calculator, fraction_calculator, or prime_number_checker, and offers no exclusions. Usage must be inferred from the domain constraint 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 cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context: exact rational arithmetic, nearest-cent half-up rounding, a 360-row cap, and explicit exclusion of taxes/insurance/PMI/fees. It does not describe error behavior for invalid inputs, but the disclosed computation semantics are substantial.

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 dense sentences, each carrying distinct content (computation, optional inputs, arithmetic/rounding, exclusions), front-loaded with the core purpose. Slightly list-like, but no filler 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?

Output schema exists so return values need not be re-specified, yet the description still summarizes the amortization table shape. Combined with the 360-row cap, rounding rules, and exclusions, an agent has everything needed 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: down payment 'reduces principal' and extra monthly principal 'shortens the modeled term'. That clarifies the interaction between optional parameters that the schema documents only individually.

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 fixed-rate monthly principal and interest payments') plus the full output scope (total interest, payoff month, amortization table). It is clearly distinguishable from sibling calculators like compound_interest_calculator because it names mortgage-style P&I plus amortization.

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?

Gives clear context for when the tool applies (fixed-rate amortized loans) and explains optional behaviors like down payment and extra principal. It never explicitly routes the agent away from a sibling (e.g. compound_interest_calculator or debt_to_income), so it stops short of full when-not 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 cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds domain constraints (value positive, base positive and not 1), but these largely duplicate the schema; no edge-case behavior or output format is described beyond what structured fields provide.

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 with no wasted words. It is appropriately sized for a simple deterministic math operation.

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

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

Given the simple operation, rich schema with example, complete annotations, and an output schema, the description is nearly complete. It correctly omits return-value details because the output schema exists, though it could have added brief routing guidance for sibling calculator tools.

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

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

Schema description coverage is 100%, and both parameters are already documented in the input schema. The description restates the base constraint and adds that the value must be positive, but this adds only marginal meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Compute a logarithm.' It also specifies valid input domains, but does not distinguish this tool from siblings such as power, scientific_evaluate, or simplify_sqrt.

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, no alternatives named, and no conditions under which another tool should be preferred. The implied use is clear from the tool name alone, but the description adds no routing 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description does add one piece of real behavioral context — that results may be terminating, repeating, or truncated — which explains what the 'digits' bound does. It stops there and adds nothing about return shape beyond that.

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 tight sentence with no filler, and the core capability (exact division with quotient and remainder) is front-loaded. It is efficient, though the second clause is slightly compressed rather than broken out for scanability.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. For a three-parameter calculator the description covers the essentials; the only real gap is the absence of guidance on choosing it over adjacent converter/calculator siblings.

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

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

Schema description coverage is 100% — each of the three parameters is documented in the schema, including defaults, bounds, and the plain-decimal/no-exponent constraint. The description's 'truncated decimals' phrase weakly reinforces the meaning of 'digits' but adds no syntax or format detail beyond the schema, 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?

States a specific verb (divide) and resource (decimal strings) plus the distinctive output (long division steps, integer quotient and remainder), so it reads clearly as an exact-division tool. It does not name or contrast any sibling (e.g. fraction_calculator, decimal_to_fraction), so sibling differentiation is left to inference.

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

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

The description implies a use case (exact division with steps and remainder) but never says when to prefer this over fraction_calculator, decimal_to_fraction, or round_decimal. No conditions, 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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it validates retail check digits and lengths (i.e. it can fail on bad input) and documents the bracketed GS1 application-identifier input syntax.

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: output form first, then validation behavior, then input syntax, then the alternative tool. Every sentence carries distinct information with no repetition of the schema.

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

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

With no output schema, the description correctly names the return artifact (SVG), and it covers validation failures and GS1 syntax for a two-parameter tool. Minor gaps remain: no mention of symbol sizing/options or what a validation failure looks like in the response.

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

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

Schema coverage is only 50% (format has no description), so the description compensates by explaining the GS1-128/DataMatrix bracketed input form such as (01)GTIN(17)YYMMDD(10)lot and the per-format validation rules that constrain `text`. The 1024-byte limit is left to the schema, which already states 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 and resource ("Make an SVG barcode") plus the formats it supports, and explicitly separates itself from make_qr. An agent can distinguish it from read_barcode and make_qr without opening either schema.

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

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

Explicitly routes QR requests to make_qr, which is the main sibling ambiguity in this space. It does not, however, say when to pick each barcode format (e.g. ean13 vs code128 vs datamatrix), so format selection is left to the 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and repeatability profile is fully covered by structured data. The description's only added behavioral fact is that the output is SVG, which is modest but genuine; it says nothing about return shape or size limits.

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

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

A single front-loaded sentence that states the output format and the accepted inputs with zero filler. It is hard to trim further, though it is so terse that it omits useful routing information.

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

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

There is no output schema, so the description should ideally say what the caller receives (inline SVG markup, a file, an image). Naming 'SVG' partially covers this, and the input side is adequately documented in the schema, making the definition minimally viable 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?

Schema description coverage is 67%, and the schema itself documents the text/wifi fields and the wifi precedence rule, so the description does not need to compensate heavily. It reinforces the input kinds and the SVG format but adds no syntax or format 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?

Specific verb+resource ('Make an SVG QR code') with the three supported input kinds spelled out (text, URL, Wi-Fi details), which is more than a restatement of the name. It does not distinguish itself from the sibling make_barcode or explain why one would pick a QR code over a barcode, 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 description says what it produces but never states when to use it versus alternatives such as make_barcode or read_barcode, nor any prerequisites or exclusions. An agent gets no routing guidance beyond 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 cover read-only, idempotent, non-destructive, closed-world status, so the bar is lower. The description adds real value: the 3% distance tolerance, the return payload (Google Maps links + encoded polyline), and the ODbL attribution requirement, which hints at reliance on external routing data.

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, front-loaded with the core behavior and constraint, no padding. The closing attribution sentence is compliance boilerplate but legitimately informative about data provenance.

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?

Return format is covered (links + polyline, so no output schema is needed), but for an eight-parameter route generator the description says nothing about how via/stops/prefer/direction shape the loop. An agent must reverse-engineer the route-building semantics from bare schemas.

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?

Eight parameters with only 13% schema description coverage, and the description names no parameter at all. It implicitly constrains 'distance_km' via the 3% tolerance and 'start' via the start/end-at-one-point rule, but leaves 'via', 'stops', 'prefer', and 'direction' entirely to the schema, which does not document them.

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 and resource: 'Make walking/running loops that start and end at one point,' plus a precise behavioral constraint (each loop within 3% of target distance). No sibling tool performs route generation, so the tool is unambiguous against the surrounding calculator/citation tools.

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

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

The activity type (walking/running) implies the use case, but there is no explicit when-to-use, when-not-to-use, or alternative routing mode. Usage is inferable rather than stated.

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 destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it computes a set of derived metrics from any valid pair of inputs, which tells the agent how dynamic the tool is. It does not describe validation/lookup failures, but the schema's oneOf enforces input combinations.

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 that states the action, the outputs, and the input pattern with no filler. Nothing is wasted and the key information comes first.

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?

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. The description is sufficient for an agent to invoke the tool correctly, though it could say a word about which input combinations are valid (the oneOf constraint) rather than leaving that entirely to 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% and each parameter is documented with bounds and units (USD, percent-of-price vs percent-of-cost), so the schema carries the semantic load. The description reinforces the cost/price pairing and the output set but adds no syntax or format detail beyond the schema; baseline 3 is appropriate.

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