AgentTools Hub

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: the reference date defaults to today in UTC, and the call is metered at $0.001/call via x402 (USDC, eip155:8453). That pricing and timezone-default context is real behavioral value not found in the schema. It does not state that the operation is a side-effect-free computation or how invalid/future dates are handled.

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?

Core capability is front-loaded in the first clause and the trailing sentence is a single compact fragment carrying the default date and price. Both parts earn their place, though the em-dash price append reads slightly as tacked-on rather than integrated.

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

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

For a simple two-parameter computation with no output schema and no annotations, the description supplies what is needed: the inputs, the output units, the default reference date, and the cost. Missing only edge-case behavior (invalid or future dates) and the exact return shape, which are minor for this tool.

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

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

Schema coverage is 100% with only two simple parameters, so the schema already documents both 'birth' and 'on' including the YYYY-MM-DD format and the today default. The description echoes the default-date behavior but adds no format or edge-case semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Calculate a person's exact age ... from their date of birth') and enumerates the output units plus total days lived, so the agent knows precisely what comes back. It never names or contrasts with the closest sibling, calculators_date_difference_calculator, so it stops short of full 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?

Usage is implied by the phrasing rather than stated: the agent can infer this is for age-from-DOB rather than general date arithmetic, and the 'defaults to today (UTC)' note clarifies the common case. There is no explicit when-to-use/when-not-to-use guidance or pointer to the date_difference sibling that handles overlapping territory.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses that the tool returns the WHO weight category and healthy BMI range, and it states the x402 price per call, which is useful operational context. It does not describe side effects, but 'Calculate' strongly implies a pure read-only computation.

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

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

The description is two tightly packed clauses: the calculation and its outputs come first, followed by the pricing detail. There is no filler, and the most important information is front-loaded.

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

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

With no output schema, the description must explain what is returned, and it does so by naming the WHO category and healthy range. It could be more complete by specifying the response structure or field names, but for a simple two-parameter calculator it is nearly 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%, and both parameters already specify units '(kg)' and '(cm)'. The description repeats those units but adds no new syntax, constraints, or edge-case meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description gives a specific verb (Calculate), resource (Body Mass Index), required inputs (weight in kg, height in cm), and additional outputs (WHO category, healthy BMI range). This is enough to distinguish it from the many sibling converters and calculators without opening 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?

The description implies the tool is used whenever BMI is needed and clearly lists the required inputs, but it provides no explicit when-to-use vs. when-not-to-use guidance and names no alternatives. The context is adequate but not enriched with routing information.

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

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

No annotations are supplied, so the description carries the full burden, and a pure read-only math tool has a low risk profile, so little is needed. It does add genuinely useful behavioral context by disclosing cost and payment rail ($0.002/call, USDC, eip155:8453), but says nothing about output shape, precision or rounding 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?

Single front-loaded sentence that states the outcome first, with the pricing note clearly segregated after an em dash. Efficient, though the price clause is slightly disruptive to the sentence flow.

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 four-parameter deterministic calculator with no output schema, the description covers the inputs and hints at the return values ('future value' and 'total interest earned'). Nothing critical is missing, though a note on output fields would fully close the loop.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, setting the baseline at 3. The description restates the compounding choice mapped to the timesPerYear enum but adds no units, ranges, or interpretation guidance 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 ('Project the future value of a deposit with compound interest') and enumerates the compounding options, which cleanly separates it from sibling calculators like loan_payment, CAGR and ROI.

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

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

There is no guidance on when to pick this over finance_cagr_calculator or calculators_loan_payment_calculator, and no prerequisites or exclusions stated. The enumeration of compounding periods is parameter information, not usage guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the paid x402 pricing model ($0.001/call in USDC on eip155:8453), which is real behavioral context. However it says nothing about boundary semantics (whether end is inclusive), timezone assumptions for the ISO dates, handling of start > end, 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?

Two sentences, front-loaded with the compute description followed by the pricing note; every clause carries information. The pricing sentence is somewhat disjunctive from the functional description but is justified for a metered tool.

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

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

For a two-param calculator with no output schema, the description usefully describes the return shape (total days, weeks+days, years/months/days), filling the gap left by the missing output schema. It is nearly complete; only edge-case semantics are 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 only two params, so the schema already documents 'start' and 'end' as ISO YYYY-MM-DD strings. The description adds no syntax, range, or ordering detail beyond that, 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+resource ('count the total days between two dates') and enumerates the three output breakdowns, which tells an agent exactly what the tool computes. It implicitly distinguishes itself from the calendar-counting siblings, though it never names live_business_days, the closest functional 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 only implied: an agent can infer this is the tool for calendar-day spans, but there is no explicit when-to-use guidance or exclusion. The most valuable guidance here – that this counts calendar days while live_business_days counts working days – is absent.

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

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

No annotations are provided, so the description carries the burden. It does add useful disclosure: the return value (final price, savings, working) and an explicit x402 cost of $0.001/call in USDC on eip155:8453, which is real behavioral context. However, it says nothing about rounding, currency assumptions, or determinism/purity of the computation.

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

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

One tight sentence describing the computation, followed by a separated pricing note. Front-loaded with the core purpose and free of filler, though the pricing tail is only loosely tied to the functional description.

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 naming the return values (final price, amount saved, working shown). For a two-parameter, single-purpose calculator with full schema coverage, this is close to sufficient; only edge-case behavior (rounding, currency) is left unspecified.

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

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

Schema description coverage is 100% with only two parameters ('price' and 'discount'), so the schema fully documents them. The description's mention of 'any price and percent-off discount' confirms the unit (percent) but adds little beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource: calculate final sale price and amount saved given price and percent-off discount. It is clearly distinguished from most siblings (tip, VAT, loan), though it does not explicitly contrast with calculators_percentage_calculator. The 'working shown' clause also hints at the response content.

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

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

No when-to-use guidance, no mention of when a plain percentage calculator would be preferable, and no prerequisites stated. The pricing note describes cost, not usage context.

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

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

No annotations are provided, so the description carries the disclosure burden. It does surface a genuinely useful behavioral trait — the x402 paid-call model ($0.001/call in USDC on eip155:8453) — but says nothing about rate limits, error behavior, or response format.

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

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

The purpose and inputs are front-loaded in one dense sentence, with pricing appended. Slightly awkward em-dash stacking, but no wasted sentences 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?

For a 4-required-parameter calculator with no output schema and no annotations, the description covers inputs, the computed outputs, and the cost model. It could note result rounding or currency for cost, but the essentials an agent needs are 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 coverage is 100%, so baseline is 3, but the description adds real meaning by pinning units (L/100 km, price per liter) and clarifying the vague 'people' parameter as cost splitting between passengers, which the schema only calls 'Split between'.

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 two concrete outputs (liters of fuel, total cost) with the exact inputs that drive them (distance, consumption, price per liter). Among a sibling set of unrelated unit calculators, the fuel/trip domain is unmistakable, though it never explicitly contrasts itself with any sibling.

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

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

Usage is implied by the stated purpose — you invoke it to compute trip fuel cost. The mention of 'optional cost splitting between passengers' hints at a secondary scenario, but there is no explicit when-to-use, when-not-to-use, or alternative named.

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

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

With no annotations, the description carries the full burden. It usefully discloses cost and payment mechanics ('x402 price $0.002/call (USDC, eip155:8453)') and the computational method, which are real traits beyond the schema. However, it says nothing about error behavior for invalid inputs (negative principal, zero years) or rounding/precision of results.

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

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

Two compact segments: the computation sentence first, then the pricing detail. Every clause earns its place — inputs, outputs, and formula are packed into one sentence with 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?

No output schema exists, but the description compensates by naming the three returned quantities and the formula used, so an agent knows what comes back. Since none of the parameters are optional and the math is deterministic, little else is needed; only edge-case handling 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 the schema already documents all three parameters, and this is the baseline 3 case. The description's phrasing 'annual interest rate' adds mild disambiguation of the rate unit (percent, per schema) but no format, bounds, or constraint details beyond it.

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

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

States a specific verb and resource ('Calculate the fixed monthly payment for a loan'), names all three inputs, and enumerates the outputs (total repaid, total interest) plus the method (annuity formula). An agent can distinguish this from finance_roi_calculator or calculators_compound_interest_calculator without opening 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 name and the stated inputs, but there is no explicit when-to-use versus the many sibling calculators (compound interest, ROI, margin) and no exclusions or prerequisites. An agent must infer routing from the description alone.

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

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

With no annotations, the description carries the full burden, and it adds two genuinely useful behavioral facts: output includes step-by-step working, and each call costs $0.001 USDC via x402 on eip155:8453. It does not state read-only/pure-computation nature, but the payment and output-format disclosures are valuable context a schema would not 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?

Two front-loaded sentences with zero waste: the capability statement comes first, followed by the pricing note. Every clause earns its place and nothing is 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 simple, stateless three-parameter calculator with no output schema, the description covers what it computes, that it returns step-by-step working, and the payment requirement. An extra note on return shape would make it fully self-contained, but nothing essential 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 the baseline is 3. The description loosely maps its three computations to the op enum values (percent_of, what_percent, change), but adds no syntax or numeric-format detail beyond what the schema already provides.

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

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

States a specific verb (Calculate) and resource (percentage) and enumerates the three exact computations it performs, which map directly to the op enum. This clearly distinguishes it from specialized siblings like tip_calculator, vat_calculator, and discount_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 three enumerated operations imply when the tool applies, but there is no explicit when-to-use guidance and no mention of alternatives such as the specialized percentage-style calculators in the sibling list. Usage is left to inference from the described operations.

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

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

No annotations exist, so the description carries the burden. It usefully discloses the paid-call model (x402, $0.001/call, USDC on eip155:8453), which is real behavioral context, but it says nothing about the result shape (minutes/seconds), accuracy, or what happens for edge inputs like zero words.

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, front-loaded with the core capability, then the pricing note. The em-dash price suffix is slightly awkward but 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 trivial two-parameter calculator with full schema coverage and no output schema, the description is nearly sufficient, but it leaves the return unit/format unspecified and its 'defaults to 200 wpm' claim conflicts with the required wpm parameter.

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

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

Schema coverage is 100%, so baseline is 3; the description's 'at any reading speed' adds little beyond the schema's own '200 = silent reading · 130 = read aloud' examples. It also claims a 200 wpm default while the schema marks wpm as required, which is a minor inconsistency that could mislead an agent into omitting a required field.

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

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

States a specific verb (estimate) and resource (reading time) plus the input basis (word count at any reading speed). An agent can distinguish this from the many sibling calculators and from dev_token_estimator without opening 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 narrow single-purpose nature of the tool, but there is no explicit when-to-use guidance, no mention of when to prefer an alternative (e.g., token estimator or LLM cost calculator for LLM token budgeting), and no prerequisites.

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

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

No annotations exist, so the description carries the full disclosure burden. It reveals two useful traits — the 15% default tip and a per-call price of $0.001 (USDC, eip155:8453) — but says nothing about rounding, currency assumption, or error behavior. It also conflicts mildly with the schema, which marks tipPercent as required, undercutting the 'defaults to 15%' claim.

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 tight sentence front-loads the core operation and outputs; nothing is wasted. The appended pricing string is relevant but stylistically detached from the calculator description.

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

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

With no output schema, the description must carry the return contract, and it does list the three outputs. However it omits rounding/precision, currency, and the tipPercent-required discrepancy, leaving gaps for a three-parameter tool.

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

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

Schema description coverage is 100% for all three parameters (bill, tipPercent, people), so baseline is 3. The description adds only the tip default and the split semantics, without clarifying units or edge cases 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 (tip for a bill) plus the derived outputs (grand total, per-person split), which cleanly separates it from sibling calculators like vat_calculator, discount_calculator, and loan_payment_calculator. An agent can identify the operation without opening 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?

The description never says when to pick this over the many adjacent calculators in the family, nor any when-not condition. Only the 15% default hints at intended usage; there is no routing guidance at all.

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

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

With no annotations supplied, the description carries the full burden and it does disclose meaningful operational context: built-in rates for 36 countries and, importantly, the payment/auth requirement (x402 price $0.001/call in USDC on eip155:8453). It omits rounding behavior, what happens on invalid country/rate combinations, and the return shape, so it is not fully transparent.

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

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

Three tight, front-loaded sentences: purpose first, then rate behavior, then pricing. The trailing x402 payment line is useful but slightly transactional; overall there is little waste.

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

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

For a 4-required-param calculator with no annotations and no output schema, the description covers operations, rates, and cost but never says what the tool returns (net/VAT/gross breakdown) or how the required 'rate' behaves against a country default, leaving a real gap.

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

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

Schema coverage is 100%, so the four parameters (op, rate, amount, country) are already documented and the baseline is 3. The description's mention of standard rates and custom overrides largely restates the schema, and it does not resolve the ambiguity of how a required 'rate' interacts with the built-in standard rate.

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 with both operation modes ('add VAT to a net amount or remove VAT from a gross amount'), which cleanly distinguishes it from siblings like percentage_calculator or discount_calculator. An agent can identify what this does without opening 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?

Explains the two applicable modes (add vs remove) and the rate selection strategy (built-in standard rates vs a custom override), giving clear context for use. It stops short of naming alternatives or stating when this tool is preferable to a generic percentage calculator.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a non-obvious operational trait — the x402 pay-per-call price ($0.001 USDC on eip155:8453) — which an agent needs before invoking. It says nothing about precision, rounding, invalid-unit handling, or the return value, which for a conversion tool is a moderate but tolerable gap given the operation is stateless and non-destructive.

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

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

Two compact sentences, with the core purpose front-loaded before the ancillary pricing detail. The unit list is a slightly dense run-on, but 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?

For a three-parameter, no-output-schema converter the description is close to sufficient, but it omits the return shape (a single numeric value) and whether errors occur for unsupported units. Given zero annotation coverage and placeholder schema descriptions, a bit more disclosure would be warranted.

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 nominally 100%, but the actual descriptions are placeholder-level ("To", "From", "Value"), so the schema conveys almost no meaning. The description partially compensates by mapping human-readable unit names to enum codes (hectares→ha, acres→acre, square miles→mi2), but the mapping is incomplete and the mm2 mismatch leaves one 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 (area units) and enumerates the unit set, so an agent can tell it apart from the sibling length/volume/weight converters at a glance. However, the enumerated units do not fully match the schema enum: "square millimeters" (mm2) is listed but absent from the enum, while the enum's cm2 is described only as "centimeters," creating a small ambiguity about scope.

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 mention of how this differs from or relates to the many sibling converters. The only additional context is a pricing note, which is not usage guidance.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses cost/access context ($0.001/call via x402 in USDC on eip155:8453), which an agent needs before invoking. However, it says nothing about rounding precision, how the two systems are presented in the result, or error behavior for non-numeric input.

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

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

One dense sentence front-loads the core capability with the unit taxonomy, then a short pricing note. No filler. Slightly packed with parenthetical asides, but every clause 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?

With no output schema and no annotations, the description is the sole source of truth. It hints at the return shape ('both systems side by side') and cost, but omits precision/rounding rules and output structure detail. Adequate for a simple 3-param converter, but not fully self-contained.

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

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

Schema coverage is 100%, but the schema descriptions are bare ('To', 'From', 'Value'). The description compensates meaningfully by explaining that KB/MB/GB are decimal (×1000) and KiB/MiB/GiB are binary (×1024), which is exactly the disambiguation an agent needs to pick between the two enum families. It adds real meaning beyond the enum list itself.

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) plus resource (digital storage units) and enumerates the exact unit sets handled, including the decimal vs binary distinction. An agent can tell this apart from sibling converters like converters_length_converter or crypto_wei_eth_converter without opening a 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 tool name and unit list but there is no explicit when-to-use guidance, no note about which sibling converter handles related cases (e.g., dev_number_base_converter), and no prerequisites. For a self-evident single-purpose converter this is minimally adequate.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the x402 payment cost, which is useful, but does not state side-effect-free/deterministic behavior, error handling for invalid units, or return shape beyond what the schema implies.

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: purpose front-loaded first, pricing second. The unit enumeration is functional rather than filler, and no sentence 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?

For a simple 3-parameter deterministic converter with full schema coverage, the description is nearly complete. It lacks an explicit return-value description, which is minor because the expected numeric result is obvious and no output schema exists to explain.

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

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

Schema coverage is 100% with enums for 'from' and 'to' and a number type for 'value'. The description lists unit names, which mirrors the enum rather than adding syntax, examples, or edge-case meaning 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 the specific verb 'convert' and the resource 'length units', listing both metric and imperial unit families. The length-unit scope makes it clearly separable from sibling converters such as weight, volume, and area.

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 applicable context is strongly implied by the unit list, but there is no explicit when-to-use guidance, no named alternative, and no exclusion. For a simple converter, the intent is clear without being directly 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the accepted range (1–3999), strict validation that rejects malformed numerals like IIIM or VX, and the x402 payment price. However, it does not state error behavior on invalid input, return format, or whether the operation has any side effects.

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

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

The definition is front-loaded with the core conversion behavior in one clear sentence, followed by a validation note and a compact pricing disclosure. Every sentence earns its place and 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?

For a simple bidirectional converter with full schema coverage and no output schema, the description covers the essential range, validation strictness, and cost. A minor gap is the absence of return-value format guidance, though the operation is simple enough that this is unlikely to block 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 coverage is 100%, so the schema already documents both parameters (op with enum direction, and value). The description adds no syntax or format details beyond what the schema provides, matching the baseline of 3 when structured fields do 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 states a specific verb (Convert) and resource (numbers / Roman numerals), including both directions and the supported range (1–3999). It also distinguishes itself from sibling converters by specializing in Roman numerals and noting strict validation.

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 strongly implied by the tool name and description (use for Roman numeral conversions), but there is no explicit when-to-use, when-not-to-use, or alternative tool guidance. No sibling overlaps exist, so the lack of exclusions is less harmful, but the description still 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?

No annotations are provided, so the description carries the full burden. It discloses pricing ($0.001/call, USDC, eip155:8453) and that output includes exact formulas, reference points, and step-by-step working. However, it omits precision/rounding, error behavior, and side-effect profile.

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

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

Two sentences, front-loaded with purpose, then price. No wasted words.

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

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

For a simple converter with a fully described schema and no output schema, the description provides the core purpose and hints at return format (step-by-step working, reference points). It is largely complete, though it doesn't explicitly state the return type.

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 documents all parameters. The description adds no additional meaning (e.g., value units, enum semantics) 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 'Convert' and resource 'Celsius, Fahrenheit and Kelvin', and lists additional output features. It is clearly distinguishable from sibling converters like area/length by 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?

No explicit when-to-use or alternatives are given, but since it is the only temperature converter among siblings, usage is implied by its name and purpose.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful behaviors: automatic millisecond detection and rejection of invalid dates with clear errors, plus per-call pricing. However it omits timezone assumptions for the to_timestamp direction and what the returned value looks like, leaving notable behavioral gaps for a no-annotation tool.

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

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

Two compact sentences front-load the core conversion behavior and the ms-detection/error-handling facts; the appended pricing note is separated by a dash and doesn't bury the primary purpose. Slightly dense given three distinct ideas packed into two 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?

No output schema and no annotations exist, so the description should fully cover input and return semantics. It covers the value formats and error behavior but never specifies the return type for either direction (e.g., epoch seconds vs. ISO string), which is a real gap for an agent invoking 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% and the enum on 'op' documents direction, so the schema already handles the parameters. The description adds only marginal meaning ('Millisecond timestamps are detected automatically', 'invalid dates are rejected') tied to the value parameter, so the 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 (convert) and resource (Unix epoch timestamps / ISO-UTC dates) with bidirectional scope made explicit by 'and back'. This clearly separates it from nearby siblings like calculators_date_difference_calculator and dev_natural_date.

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 establishes context (timestamp<->date conversion, automatic millisecond detection) but never states when to prefer this tool over alternatives such as dev_natural_date or calculators_date_difference_calculator, nor any exclusion cases. Usage is only implied by the tool's name and description.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the payment requirement (x402 price $0.001/call, USDC, eip155:8453), which an agent must know before calling, but says nothing about precision/rounding, error behavior on invalid units, or the shape of the returned 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?

Purpose is front-loaded in the first clause and the pricing note is appended as a brief second element. The unit enumeration is lengthy but functionally informative, so the text is appropriately sized with little waste.

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

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

For a simple three-parameter converter with no output schema and no annotations, the description covers the what and the cost but omits the return format and any precision guarantees. It is minimally viable rather than fully complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's unit list merely restates the enum values already present for 'from' and 'to', and adds nothing about the numeric 'value' parameter's range or format, so no credit above baseline is warranted.

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 ('cooking and liquid volume units') and enumerates the supported units, making it immediately distinguishable from sibling converters like length, weight, or temperature. An agent can select it without opening 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?

The phrase 'cooking and liquid volume units' implicitly scopes usage to volume conversions, which is enough to separate it from non-volume siblings. However, there is no explicit when-to-use/when-not statement or routing to alternatives, so guidance remains 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?

With no annotations, the description carries the full behavioral burden. It discloses that conversions use 'exact international definitions' and states the x402 price per call, which adds useful context. However, it does not describe return format, precision guarantees, 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?

The description is a single, front-loaded sentence stating purpose and units, followed by a brief pricing clause. Every part is relevant and 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?

For a simple conversion tool with no annotations and no output schema, the description covers the purpose, supported units, precision stance, and cost. It omits return value details, but those are minor for a straightforward converter.

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

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

Schema coverage is 100%, but the schema descriptions are trivial ('From', 'To', 'Value') and the enum values are cryptic abbreviations. The description lists the full unit names (metric tons, kilograms, etc.), directly mapping to the enum values for 'from' and 'to', which adds meaningful semantic clarity.

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 (Convert), the resource (weight and mass units), and enumerates all units covered. This resource focus cleanly distinguishes it from sibling converters like area, length, or temperature 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states what it does, leaving usage entirely 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?

With no annotations, the description carries the behavioral burden, and it does disclose two useful traits: exact BigInt arithmetic for wei amounts (precision/determinism) and a per-call cost of $0.001 USDC on eip155:8453, which implies payment/auth is required. It stops short of stating it is a pure side-effect-free computation or handling error 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?

Two sentences, front-loaded with the core formula before the pricing aside. Every clause contributes; nothing is 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 3-param calculator with no output schema, the description conveys both the computation and the two result currencies (ETH cost and USD), which largely covers the return. It does not state the exact output fields or rounding, a minor gap for a trivial tool.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes further by explaining how the three inputs combine mathematically (gasUnits × gweiPrice, then × ethPriceUsd), which adds computational meaning beyond the terse schema labels.

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 (gas fee) and spells out the exact formula (gas units × gwei price → ETH → × ETH price → USD). This unambiguously separates it from neighbors like crypto_wei_eth_converter or dev_llm_cost_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 alternatives such as crypto_wei_eth_converter or live_exchange_rates for sourcing the ETH price. The only usage-adjacent sentence is the x402 pricing note, which is cost information, not invocation guidance.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: a 60-second cache and, notably, that the tool is a paid x402 call at $0.002/call via USDC on eip155:8453. Rate limits, error behavior, and response shape remain unstated, keeping it short of 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?

Effectively one dense sentence stating capability and inputs, followed by cache and price metadata. Front-loaded and waste-free, though the payment clause is slightly cryptic in 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?

For a two-parameter read tool with no annotations and no output schema, the description supplies what an agent needs: source, returned fields, accepted inputs, caching, and cost. Only the exact response structure and failure modes are left implicit.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning by clarifying that 'ids' accepts either CoinGecko ids or common tickers (btc, eth, sol) and that the quote currencies are the four USD/EUR/GBP/JPY options. That goes beyond the terse schema strings.

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

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

States a specific verb+resource (live crypto prices), the data source (CoinGecko public API), the exact payload (price in USD/EUR/GBP/JPY plus 24h change), and the accepted input forms (id or ticker). This clearly separates it from fiat-oriented siblings like live_exchange_rates.

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 implies when to use it ('live cryptocurrency prices', ticker examples) and notes a 60s cache, but never names an alternative or states when another tool (e.g. live_exchange_rates) should be preferred. Usage is inferable but not explicit.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral detail: 'rejection sampling, no modulo bias' and 'cryptographically secure' disclose the algorithm's guarantees. However, it omits required permissions, error/retry behavior, and the shape of the returned value, which for a 7-required-param tool leaves gaps.

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, purpose front-loaded, with the security warning and pricing tacked on efficiently. The x402 price note is contextual noise for pure capability selection but relevant cost/usage data, so it only mildly dilutes.

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 7-param tool with no annotations and no output schema, the description covers purpose, modes, and algorithm guarantees well, but it never describes the return payload (e.g. what a generated password or key looks like), which is the main remaining gap.

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

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

Schema coverage is 100%, but the schema descriptions themselves are terse ('Mode', 'Int maximum', 'Length (password/hex)'). The description compensates by mapping parameters to modes and clarifying charset rules ('passwords with charset rules', 'hex keys of any byte length', 'uniform random integers'), adding genuine semantic value.

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

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

States a specific verb ('Generate') and resource ('cryptographically secure randomness'), then enumerates the three concrete modes (passwords, hex keys, uniform ints) so an agent knows exactly what it produces. Sibling tools are all calculators/converters, so no differentiation is needed.

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?

'Never use Math.random for secrets' gives a clear use context (secret generation) and implicitly excludes the weak-RNG approach, but there is no explicit when-not guidance or named alternatives within the toolset. Usage is implied rather than spelled out.

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

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

With no annotations the description carries the full behavioral burden, and it does disclose the data source (Blockscout), the fact that results are derived conclusions with fresh-wallet and high-volume flags rather than raw RPC, and the x402 payment ($0.005/call USDC on Base) which an agent must know before invoking. It omits rate limits and latency/freshness guarantees, keeping it short of 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?

Front-loads the core purpose, then the return contents, then the differentiating 'conclusion not raw data' claim, then the price. It is a slightly long compound sentence, but each clause adds distinct information and 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?

For a 2-param tool with no output schema and no annotations, the description compensates well by enumerating the returned fields and the payment requirement. Only minor gaps remain (error behavior, rate limits), and the payment/return detail covers what an agent most needs.

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 'address' and 'chain' (enum base/ethereum) are already documented in the schema. The description confirms the two supported chains but adds no syntax, format, or validation detail beyond the structured fields, 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 ('on-chain profile of any Ethereum or Base wallet') and enumerates exactly what it returns: balance, tx/transfer counts, recency, token holdings, counterparties, flags. The 'who is this address?' framing pins down the intent unambiguously and no sibling overlaps this resource.

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

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

The description implies usage by framing the tool as the answer to 'who is this address?' and by listing two supported chains, but it states no when-to-use condition, no exclusions, and names no alternative (there is no true sibling, yet prerequisites like payment or rate limits are not framed as usage guidance).

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

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

With no annotations, the description carries the full burden. It does add real behavioral value by disclosing exact BigInt arithmetic and no floating-point error for arbitrary magnitudes, plus the x402 cost. It omits what happens on invalid input, whether output is a string, and whether rounding/truncation ever occurs.

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 and tight: the conversion scope and precision guarantee come first, followed by a compact pricing note. Two sentences plus a price tag, with negligible waste.

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

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

No output schema and no annotations, so the description should cover more. It explains the computation contract but says nothing about the return shape, error behavior, or edge cases, leaving an agent to infer the output form.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the unit vocabulary and the exact-precision intent for the value param, but the schema descriptions themselves are bare restatements ('From', 'To') and the value format is already in the schema. It also uses 'microether'/'milliether' while the enum uses 'microeth'/'millieth', which is a minor naming mismatch rather than added clarity.

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 (wei/kwei/mwei/gwei/microether/milliether/ether) plus the mechanism (exact BigInt arithmetic). An agent can distinguish this from the generic converters_number_base_converter and from crypto_gas_fee_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?

No statement of when to use this versus siblings such as crypto_gas_fee_calculator or converters_number_base_converter, and no prerequisites or exclusions. Usage is only implied by the tool name and the unit list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that this is a paid x402 endpoint ($0.001/call in USDC on eip155:8453) and states dataset scope/coverage, but says nothing about error behavior (unknown code), rate limits, or response shape.

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

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

Two tight sentences: purpose and both usage modes are front-loaded, with pricing appended. Slightly telegraphic in the pricing clause, but no padded or redundant 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 3-parameter tool with no annotations and no output schema, the description covers purpose, modes, and dataset scope, which is close to sufficient. However, it never resolves the schema oddity that code, state, and limit are all required while the schema says code may be left empty to list by state, leaving an agent unsure how to invoke the listing mode.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description corroborates the code/state relationship but adds no format detail (e.g. valid code shapes, whether limit is optional in practice). Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Look up any US telephone area code') plus an explicit second mode ('list every area code in a given state'), and scopes the data ('all 404 NANP codes in use, including overlays'). Easily distinguished from the nearest sibling, databases_countries.

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 makes the two operating modes explicit: pass a code to resolve a state, or list by state. That gives clear context for which parameter drives which behavior, but it offers no exclusions or guidance on when to prefer one mode over the other in a workflow.

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

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

No annotations are provided, so the description must carry the behavioral load. It usefully discloses the dataset contents and the x402 price of $0.002 per call, but it does not describe read-only status, auth/payment flow beyond price, rate limits, or response behavior.

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

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

The description is three tight sentences: dataset scope, usage modes, then pricing. It is front-loaded and every sentence adds concrete 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 three-parameter read tool with no output schema, the description gives enough context: the available fields, the lookup modes, and the payment price. It could be more explicit about combining empty country/region values, but the schema covers those details.

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

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

Schema description coverage is 100%, so the schema already documents country, region, and limit. The description only adds that country lookup versus regional listing is possible, without adding syntax or constraints 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 resource (reference database of all 250 countries and territories) and a specific action (look up a single country or list by region). It also enumerates the data fields available, so an agent can tell this apart from unrelated calculator, converter, and lookup siblings.

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

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

It clearly states the two primary modes: look up one country or list by region. It does not name alternatives or explicit exclusions, but for this tool the usage context is sufficiently clear from the description and schema.

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

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

With no annotations, the description carries the full burden, and it does disclose genuinely useful operational context: a per-call price of $0.002 in USDC on chain eip155:8453, which the agent cannot learn from the schema. It still omits the payment/auth flow (how the x402 payment is settled) and any rate-limit or error behavior, so it is good but not complete.

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 return values are front-loaded in a single tight sentence, followed by use cases and pricing. Nothing is redundant, though the appended price clause is dense enough to slightly interrupt the flow.

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 tool with no output schema, the description usefully enumerates the returned fields and discloses cost, which is the main thing an agent needs before spending money. Payment mechanics and failure modes remain unstated, keeping it 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?

There is a single parameter with 100% schema description coverage, so the baseline is 3. The description adds only marginal meaning beyond the schema ('any URL' vs. the schema's 'URL or domain'), giving no format, normalization, or edge-case guidance.

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

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

States a specific verb and resource ('Query the Internet Archive's Wayback index for any URL') and enumerates exactly what comes back: first archive date, most recent snapshot, span in years, recent captures. This clearly separates it from siblings like dev_url_reader and live_url_metadata, which fetch current page content rather than historical snapshots.

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?

Names three concrete situations ('fact-checking page history, finding deleted content and due-diligence'), which gives the agent a clear positive trigger. It stops short of naming an alternative tool or stating when not to use it, so it falls below the explicit routing bar.

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

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

With no annotations, the description carries the full burden. It discloses two useful behavioral traits: full UTF-8 support (emoji, non-Latin scripts) and the x402 cost model ($0.001/call in USDC). It does not cover error behavior on malformed base64 input or the return shape, which are unaddressed given there is no output schema.

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

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

Two tight, front-loaded sentences with the functional behavior first and the cost note appended. The pricing clause is slightly bolted-on but every element 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 2-parameter, enum-driven utility with 100% schema coverage and no output schema, the description covers purpose, the UTF-8 edge case, and cost. Only malformed-input handling is missing, which is minor.

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 direction enum is fully enumerated, so the schema already documents both parameters. The description adds no syntax or format details beyond what the schema provides, making the baseline 3 correct.

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 pair ('Encode text to base64 or decode base64 back to text') and clarifies the bidirectional nature that the encode-oriented name obscures. It doesn't differentiate from siblings like dev_url_encoder or dev_hash, but the base64 resource is unambiguous.

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

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

Usage is implied by the encode/decode phrasing, but there is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives such as dev_url_encoder or dev_hash. Adequate for a trivial utility but leaves selection to inference.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add meaningful behavioral context: the automatic camelCase boundary splitting and the x402 payment model ($0.001/call in USDC on eip155:8453), which is important for an agent to know before invoking. It still says nothing about error behavior, input limits, or return format.

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

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

Two tight sentences plus a price note; the capability is front-loaded before the secondary behavioral and pricing details. Every clause carries information with 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?

For a simple two-parameter, non-nested, no-output-schema tool, the description covers the full option space and one notable behavioral rule. The only gap is that it does not state the return shape (plain converted string), which is minor given the tool's simplicity.

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

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

Schema description coverage is 100% and the enum fully enumerates the styles, so the schema does the heavy lifting. The description's list of display-style names (UPPER, Title, Sentence, kebab-case) adds a light mapping to the terse enum values (upper, title, sentence, kebab), but no syntax or edge-case detail beyond that.

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 letter cases) and enumerates all nine output styles, which is exactly what the enum offers. This clearly differentiates it from adjacent siblings like dev_number_base_converter and dev_base64_encode, which transform different data 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?

The purpose makes the usage context self-evident (case transformation), and the note that 'camelCase boundaries are split automatically' hints at expected input. However, there is no explicit when-to-use/when-not, no mention of which sibling to prefer for adjacent tasks (e.g. text_chunker for splitting), so guidance 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?

With no annotations, the description carries the full burden and does disclose two valuable traits: determinism (no guessing) and the x402 payment requirement at $0.001/call with chain ID. It does not say how invalid expressions are surfaced or what the response shape looks like, leaving some behavioral gaps.

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 that front-load the capability before the value proposition, with the pricing clause cleanly appended. Slightly dense with three verbs in one sentence but 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?

For a two-parameter tool with no output schema, it conveys the input contract, the returned content (plain English plus next fire times), and the payment model. Remaining gaps are edge-case behavior on malformed expressions and the exact output format.

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 schema, including the 5-field format for 'expr'. The description adds no syntax, format, or defaulting detail beyond that, so the baseline of 3 applies.

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

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

States three specific functions on a specific resource: translate a cron expression to plain English, validate it, and compute the next execution times. This is unambiguous and clearly distinct from every calculator/converter sibling.

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

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

Frames the use case sharply ('when does this cron actually fire?') which signals when to reach for it, and no sibling overlaps in domain. It stops short of explicit when-not guidance or naming an alternative for partial needs (e.g. a plain validator).

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

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

With no annotations, the description carries the burden and discloses key behavioral traits: LCS-based determinism, unified-diff output, and a per-call price. It does not describe limits, error behavior, or auth mechanics beyond the price, but it adds meaningful context beyond the schema.

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

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

The description is two sentences: the core operation comes first, followed by a compact differentiator and pricing note. No sentence feels redundant or bloated.

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

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

For a simple read-only diff tool with complete parameter schema coverage and no output schema, the description sufficiently explains what the tool returns (unified-diff additions, removals, context). It omits input size limits or error cases, which are minor gaps.

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

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

Schema description coverage is 100%, with each parameter documented in the input schema. The description mentions line-by-line comparison and context but adds no parameter syntax or constraints beyond what the schema already provides.

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

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

The description states a specific verb and resource: compare two texts line by line. It also names the algorithm (LCS diff) and output format (unified-diff style), so an agent can distinguish this from generic text tools without opening 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?

The phrase 'Deterministic, unlike asking a model to find the differences' implies a usage context, but it does not explicitly say when to choose this tool over alternatives or when not to use it. Usage remains largely inferred from the tool's name and purpose.

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

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

With no annotations, the description carries the full burden and does disclose a genuinely important behavior — the tool is x402-paid at $0.002/call in USDC on eip155:8453 — plus the fact that it fans out to two sources (own catalog and live third-party Bazaar). It does not clarify whether payment is incurred on search or on downstream invocation, and says nothing about result shape or pagination.

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-loads what the tool does in the first clause, then layers the source scope and the pricing tag. Three tight fragments with little waste, though the 'agent's meta-tool' line is somewhat promotional rather than operational.

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 search tool with no annotations and no output schema, it covers purpose, source scope, optionality, and the payment model. The notable remaining gap is what a returned result contains (e.g., whether returned APIs include invocation details), but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that results come from two sources, which clarifies both the 'includeBazaar' toggle and the 'Max results per source' semantics of 'limit'. It still doesn't state defaults for limit or the string-vs-boolean quirk of includeBazaar.

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 concrete action (describe a need, receive matching APIs) and names the resource precisely: the 54-tool internal catalog plus the live x402 Bazaar. The sentence 'The agent's meta-tool — instead of knowing an API exists, ask for the capability' distinguishes it cleanly from every single-purpose sibling calculator/converter tool.

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

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

Gives clear usage context: use it when you don't know an API exists and want to ask by capability, and it explains that Bazaar inclusion is optional. It stops short of explicit when-not guidance (e.g., that direct siblings should be called when the capability is already known) or spelling out a concrete alternative.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: two validation layers, a live network DNS MX lookup (implying latency and possible DNS failure), and pricing at $0.001/call in USDC on eip155:8453. It does not say how syntax-stage failures are reported versus DNS-stage failures, which is the remaining gap.

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

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

Two sentences front-load the layered validation logic and the practical benefit, then a compact price clause. No filler; every sentence earns its place.

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

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

For a one-parameter tool with no output schema and no annotations, the description covers method, benefit, cost, and network behavior adequately. It only omits how results are returned for the two failure modes, a minor gap given the tool's simplicity.

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

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

There is a single parameter at 100% schema description coverage, so the schema already documents it fully. The description adds no format or syntax constraints beyond 'email address', 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?

Names a specific verb and resource (validate an email address) and breaks the operation into its two concrete layers: RFC-style syntax and a live DNS MX lookup. This is clearly distinguishable from sibling validators like finance_iban_validator and from regex-only checks.

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 'Catches the typos and fake domains that pure regex misses' tells the agent when this tool is preferred over simpler validation. It stops short of naming a sibling alternative or stating when not to use it (e.g., batch/offline scenarios), so it is clear context but not a full routing rule.

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

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

With no annotations, the description carries the full burden and does a solid job: server-side fetching, an SSRF guard, both RSS 2.0 and Atom dialects, ISO-8601 dates, and a per-call x402 price. It omits failure modes such as timeouts, malformed feeds, and rate limits, which keeps it short of 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?

Two tight sentences with the core action front-loaded; the return-field list is compact. The trailing price clause is a bit appositive and marked off with an em dash, slightly interrupting an otherwise clean structure.

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

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

No output schema exists, and the description compensates by naming the returned fields (title, link, ISO publication date, summary). Combined with the safety and pricing notes, an agent has enough to invoke it, though error and limit behavior remain 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%, so 'Feed URL' and 'Max items' are already documented in the schema. The description adds no syntax, default, or bounds information for either parameter, 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 (fetch) and resource (RSS/Atom feed) plus the normalized return shape, which cleanly separates it from siblings like dev_url_reader, live_url_metadata, and dev_ics_parser. An agent can pick this tool without opening any other definition.

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 implies the use case (pulling structured items from a feed) and notes dialect coverage, but offers no explicit when-to-use guidance, no alternatives named, and no exclusions (e.g., when to prefer dev_url_reader for raw HTML). Usage must be inferred.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses determinism, UTF-8 input handling, implementation details (Web Crypto / pure-JS MD5), and an x402 price, but it does not explain the return format (e.g., hex vs base64) 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?

The description is front-loaded with the core action, then adds determinism and pricing in compact form. Every element earns its place, and there is no redundant restatement of the tool name or schema.

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

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

For a low-complexity two-parameter tool, the description covers algorithms and determinism but omits the output digest format. With no output schema and no annotations, that missing detail leaves a noticeable gap for an agent that needs to consume the result 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%, but the schema itself only labels the parameters as 'Algorithm' and 'Text'. The description adds meaningful context by specifying UTF-8 text and grouping the algorithm choices into SHA-family and legacy MD5 use cases, which goes beyond the bare enum.

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

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

The description gives a specific verb and resource: compute exact hash digests of UTF-8 text. It names the supported algorithm families (SHA via Web Crypto, MD5 for legacy checksums), which distinguishes it clearly from sibling tools like base64_encode or uuid.

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 states what the tool does but gives no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives or scenarios where hashing is preferred over related dev utilities, leaving selection entirely to the agent's 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?

With no annotations, the description must carry behavioral burden. It usefully discloses pricing ($0.001/call via x402 on eip155:8453), which is genuine context, but says nothing about return format, pagination of the limit param, or empty-result 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?

Two compact sentences that front-load the resource definition before the usage modes. The appended pricing clause is slightly awkward but brief and earns its place as cost context.

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

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

For a read-only reference lookup with no output schema or annotations, the description covers what is returned (phrase, category, explanation) and the two query modes, which is enough to call it correctly. Slightly more detail on limits/pagination would round it out.

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

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

Schema coverage is 100%, so the schema already documents code, category and limit. The description adds marginal value by framing the two lookup modes (specific code vs. whole category), which clarifies the code/category interaction, but no syntax beyond the schema's own enum and notes.

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 (look up) and resource (HTTP response status codes) plus the returned fields (phrase, category, explanation). The purpose is unambiguous, though it doesn't explicitly differentiate from any sibling, which is largely unnecessary given the unique resource.

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?

"Look up a specific code or list a whole category (1xx–5xx)" gives two implied usage modes and clarifies the code-vs-category choice. However there is no when-to-use/when-not guidance or named alternatives, leaving usage only implied.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses a paid-call model (x402, $0.002/call in USDC on eip155:8453) and the parser's target domain, which is real added context. It says nothing about failure modes for malformed .ics content, truncation behavior when 'limit' is hit, or rate/authentication constraints, so the disclosure is partial.

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 paragraph with the core purpose front-loaded and the output fields enumerated compactly. The trailing pricing note is appended rather than woven in, which is slightly awkward but costs only a point.

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 parser with no output schema, the description covers purpose, input domain, and the shape of the returned event JSON inline, which is what an agent needs before calling. The remaining gap is behavioral (malformed-input handling, limit semantics) rather than structural.

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

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

Schema coverage is 100% for both parameters, so the schema already documents 'ics' and 'limit'. The description adds no semantics beyond that — it does not clarify whether 'limit' truncates silently or errors, nor the expected structure of the .ics payload. Baseline 3 is appropriate when the schema does the work.

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 ('Parse iCalendar (.ics) content') and enumerates the structured output fields, so the agent knows exactly what it gets back. It does not differentiate itself from the nearby dev_feed_parser sibling, which is a similar parse-into-JSON tool, 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 examples ('meeting invites, conference calendars, exports from Google/Outlook') imply the intended input domain, which is useful implied usage guidance. However, there is no explicit when-to-use vs when-not, no mention of an alternative parser, and no stated prerequisites for the input content.

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

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

With no annotations, the description carries the full burden. It usefully discloses the paid x402 pricing ($0.001/call, USDC on eip155:8453) and that error messages are precise, but it never says what happens on malformed JSON, whether the three operations run together in one call, or what the response looks like for each mode.

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 capability sentence is tight and front-loaded, with no filler. The trailing x402 price clause is legitimately useful meta-information for a paid tool but does interrupt the description, so it is not perfectly economical.

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

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

With no output schema and no annotations, the description should cover return and failure behavior. It sketches the outputs (top-level type, element counts) but omits the error path for invalid JSON and the interaction between the three advertised operations, leaving gaps for a tool with two required parameters and no structured safety metadata.

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. Both schema descriptions are terse ('JSON', 'Indent spaces'); the description adds 'any indent' but does not clarify the indent unit, valid range, or whether indent is irrelevant when only validating, so it adds little 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 three concrete operations (validate, pretty-print, inspect top-level type/element counts) on a specific resource (JSON), which is far more than a restatement of the name. It does not explicitly contrast with any sibling, but the sibling list contains no other JSON tool, so differentiation is implicit rather than stated.

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

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

The listed capabilities imply when the tool is useful, but there is no explicit guidance on when to prefer this over alternatives, no noted prerequisites, and no statement about which inputs are required for a validate-only vs pretty-print call. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the burden and does well: it discloses the non-verification semantics, that no secret is needed, that exp/iat are rendered as dates, and the per-call price. It omits behavior on malformed/invalid tokens (error vs. partial decode), which a caller would want to know.

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 action, then the critical caveat, then output formatting notes and pricing. No sentence is wasted and nothing important 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?

For a single-parameter decoder with no output schema, the description adequately previews the return shape (header/payload JSON, dates rendered) and the pricing/auth profile. Only error-handling behavior is left unspecified.

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

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

Only one parameter and schema description coverage is 100%; the schema already supplies the header.payload.signature format. The description adds no 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 (Decode) and resource (JSON Web Token's header and payload) plus the output form (readable JSON). No sibling tool overlaps with JWT decoding, so the agent can identify it unambiguously.

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 line 'Pure decoding: signatures are NOT verified and no secret is needed' clearly demarcates this from a token-verification tool and tells the agent no credentials are required. It does not name an explicit alternative tool or state when-not-to-use, so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose meaningful traits: pricing derived from published per-million rates, automatic batch multiplier for volume estimates, model coverage scope, and the x402 payment terms ($0.001/call, USDC on eip155:8453). It still omits how current the price table is and any freshness/rate-limit caveats, but the paid-call disclosure is above 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?

Three compact fragments with no filler, and the core purpose is front-loaded ahead of the pricing/payment details. Every clause adds information an agent can act on.

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

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

For a 4-parameter, no-output-schema calculation tool, the description covers what it computes, which models are supported (enum also in schema), and the cost of invoking it. Missing only output-shape/currency expectations and price-table freshness, which are minor for this tool class.

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

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

Schema description coverage is 100% and all four parameters are documented there, so the baseline is 3. The description adds the pricing formula concept (tokens × per-million price) and the batch-multiplier behavior, but not per-parameter meaning beyond what the schema already states.

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 — converting input/output token counts into LLM API cost — plus the concrete pricing basis (published per-million prices across 15 named providers). This is enough to distinguish it from the nearest sibling dev_token_estimator (which counts tokens) and from the other *_calculator tools.

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

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

Use context is only implied: the mention of a batch multiplier for 'monthly estimates' suggests a projection use case, but there is no explicit when-to-use or when-not-to-use guidance and no pointer to the complementary token-estimation tool. Adequate but leaves routing inference to the agent.

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

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

With no annotations, the description carries the full behavioral burden; it usefully discloses the paid model (x402, $0.001/call USDC on eip155:8453), which is real cost context an agent needs. It does not say what happens on a miss, whether matching is case-insensitive, or how results are shaped, so gaps remain for an unannotated tool.

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

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

Two sentences, purpose front-loaded, with the pricing clause clearly separated by an em-dash. Efficient, though the appended price tail slightly dilutes the single-purpose lead 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?

For a 3-required-parameter, no-annotation, no-output-schema tool, the description covers purpose and cost but omits result shape and the required-category/empty-string behavior. Adequate to invoke, but not complete given annotations contribute nothing.

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 query, category, and limit are already documented structurally; baseline 3 applies. The description adds the mild nuance that 'query' accepts a file extension as well as a substring, but does not explain that category must be explicitly provided (empty string for all) despite being required.

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 (look up) and resource (MIME content types) plus the three access modes: type substring, file extension, or category listing. The covered category set (text, application, image, audio, video, font, multipart) makes the scope explicit, and no sibling tool does MIME resolution, so it is unambiguously distinguishable.

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 how to query (substring, extension, or category) but never states when to prefer one mode over another, nor any prerequisites or exclusions. There are no true alternatives among siblings to route against, so the guidance is functional but not selective.

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

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

With no annotations, the description carries the full burden and does well: it discloses determinism (no LLM guessing), that relative expressions are resolved against a caller-supplied reference, and the per-call price/chain. It stops short of stating error behavior for unparseable input or output formatting beyond the ISO claim.

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 action, examples inline, and the pricing detail trailing. Nearly every clause earns its place, though the x402 price fragment reads as appended boilerplate rather than operational guidance.

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

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

For a simple two-param tool with no output schema, the description covers input intent and return format (ISO 8601). Only failure modes and timezone handling on 'ref' are left implicit.

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

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

Schema description coverage is 100%, so the two parameters are already documented; the description reinforces that 'ref' is a caller-controlled reference moment, which mirrors the schema's 'Defaults to now'. Baseline 3 is appropriate since it adds little 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 precise verb+resource ('parse natural-language date and time expressions into ISO 8601 dates') and anchors it with three concrete example inputs. It is unmistakably distinct from the sibling calculators_date_difference_calculator and converters_unix_timestamp_converter.

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?

Clearly signals the use case (fuzzy human phrasing → machine date) and notes a controllable reference moment, but does not explicitly say when to prefer a sibling such as live_now or calculators_date_difference_calculator. Context is evident 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses BigInt precision and no magnitude limit, and mentions the x402 price, but it does not state the return format, error behavior, or input validation rules.

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

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

The description is front-loaded and concise, using a single functional sentence followed by a short price note. The price fragment is extra but does not obscure the main purpose.

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

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

For a simple conversion tool, the description covers the core operation, supported base range, and precision. However, with no output schema and no annotations, it does not explain the return value or error cases, leaving some contextual gaps.

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

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

Schema description coverage is 100%, so the schema already defines value, from, and to with base ranges. The description repeats the 2–36 base range and adds BigInt context, but does not meaningfully clarify the parameters beyond what the schema provides.

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

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

The description clearly states the action (convert integers) and the resource domain (number bases 2–36), with concrete examples such as binary, octal, decimal, and hexadecimal. It does not explicitly distinguish itself from sibling converters like roman numeral or base64 encoding, 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 gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states what it does and includes a price note, leaving usage context entirely 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?

With no annotations the description carries the full burden, and it does so well: SSRF-guarding on the fetch path, deterministic parsing with no LLM hallucination risk, and the text-only limitation. It omits failure modes/error behavior and any statement about what happens when maxChars truncates, 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?

Three compact clauses, front-loaded with the core action, then limitations, then cost. Nothing is padding; the pricing boundary is separated with a dash and does not dilute the operational content.

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

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

No output schema exists, and the description partly compensates by naming the return (text plus page count). Inputs, pricing, safety, and scope limitations are all covered. A brief note on truncation via maxChars or on error responses would make it 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 coverage is 100% so baseline is 3, but the description adds value the schema actively muddles: the schema marks url AND base64 both required while the url field says 'Or provide base64 instead'. The description's 'by URL ... or accept it as base64' clarifies this is an either/or input, which is genuine semantic clarification 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 (extract) on a specific resource (PDF text), plus both supported input modes (URL or base64) and the returned artifact (readable text + page count). The PDF focus distinguishes it cleanly from siblings like dev_text_extract and dev_url_reader.

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 a clear exclusion: text-based PDFs only, scanned images need OCR and that is not included. That is real when-not-to-use guidance. It stops short of naming an alternative tool to route to, so it does not reach 5.

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

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

With no annotations, the description carries the full burden. It usefully discloses the overlap mechanism ('overlap between consecutive chunks preserves context') and the commercial terms (x402, $0.002/call in USDC on eip155:8453), which is real value. It omits behavioral limits: maximum input size, what happens when text is shorter than targetTokens, and any failure modes.

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, all doing work: operation, mechanism, and pricing. It is front-loaded with the core action. The inline pricing clause interrupts the flow slightly but is short and earns its place by exposing cost.

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 and no annotations, so the description should describe the return shape, and it does not say whether the result is a list of strings, objects with offsets, or token counts. For a three-required-parameter tool that is otherwise well described, this is a meaningful remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the terse schema labels: 'targetTokens' is framed as a token budget and 'overlapTokens' is explained as the mechanism that preserves context across splits. That interpretation is not available from 'Overlap tokens' alone.

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

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

States a specific verb and resource with meaningful scope modifiers: 'Split text into retrieval-friendly chunks with a token budget and sentence-aware boundaries.' An agent knows exactly what operation it performs. It does not, however, contrast itself with the adjacent dev_token_estimator or dev_text_extract siblings.

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

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

The phrase 'the standard preparation step before embedding' gives implied context for when to reach for it, which is more than nothing. But there is no explicit when-not guidance, no statement about chunk-size selection, and no routing to alternatives such as dev_token_estimator.

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

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

With no annotations, the description carries the full burden, but it does disclose genuinely useful behavioral facts: results are deduplicated and categorized, and each call costs $0.002 via x402 on eip155:8453. It omits any statement about input size limits, error behavior, or auth/payment failure handling, which matters for a paid endpoint.

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

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

Three short fragments, capability first, with the pricing detail last where it belongs. Slightly clipped style ('Deduplicated, categorized, machine-ready') but nothing that wastes space.

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 tool with no output schema, the description should sketch the return shape; it gestures at this ('structured entities', 'categorized') but never states the response format or whether each category is keyed separately. Adequate for invocation, thin on what to expect back.

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

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

Schema coverage is 100% and both parameters are documented (the enum values map directly to the entity types named in the description). The description adds no syntax hints, size limits for 'text', or explanation of what 'all' returns, so it does not exceed the schema baseline.

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

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

States a specific verb (extract) and resource (structured entities from unstructured text) and enumerates the exact entity types returned, so the agent knows precisely what comes out. It does not, however, distinguish itself from nearby siblings such as dev_email_validator or dev_url_parser, which target overlapping entity 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?

The phrase 'Scan unstructured text' implies the input context (freeform text rather than a single field), but there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives like dev_email_validator for validating one address. Usage is inferable, 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?

With no annotations provided, the description carries the full behavioral burden and adds important context: it is a heuristic within roughly 10% of real tokenizers, has zero dependencies, and requires an x402 payment of $0.001 per call. It does not describe return shape or rate limits, but for a lightweight estimation tool this is a strong 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?

The main purpose is front-loaded in a single information-dense sentence, followed by a compact pricing note. It is appropriately sized for the tool, though the em-dash pricing fragment could be cleaner.

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 one-parameter estimator with no output schema, the description is largely complete: it explains the input concept, the output families, the heuristic nature, and the payment requirement. It could state more about the returned structure, but the core calling requirements are covered.

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

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

Schema description coverage is 100% and there is only one parameter, text, whose name and schema already make its meaning clear. The description adds no extra syntax, constraints, or formatting details beyond what the schema provides, so the baseline score 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: estimating token consumption for multiple named model families. It clearly distinguishes itself as a heuristic estimator rather than a full BPE tokenizer, but it does not explicitly contrast itself with the sibling dev_llm_cost_calculator or other token-adjacent 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?

It implies usage for context budgeting and cost math, which gives an agent a sense of when the tool is appropriate. However, there is no explicit when-not guidance or named alternative for related tasks such as cost calculation.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It usefully states that it uses standard encodeURIComponent rules and includes the cost ($0.001/call), but it does not describe error behavior for malformed decode input or explicitly confirm the operation is stateless/read-only.

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

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

The description is front-loaded with the core encode/decode behavior in two efficient sentences. The trailing price line is relevant but feels slightly appended rather than integrated, keeping it just short of a 5.

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

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

For a simple stateless encode/decode utility with full schema coverage and no output schema, the description is mostly complete. It explains the operation and the encoding standard, but could be more complete by noting return value expectations or decode error behavior.

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

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

Schema description coverage is 100%, so the schema already documents both required parameters (op enum and text). The description adds no syntax, format, or edge-case meaning beyond what the schema provides, making the 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 states a specific verb and resource: percent-encode or decode text for URL/query-string safety. It is clear what the tool does, but it does not explicitly differentiate from nearby siblings like dev_url_parser, dev_url_reader, or dev_base64_encode.

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

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

The description implies usage by saying 'for safe inclusion in URLs and query strings' and 'decode percent-encoded text back,' but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer from the tool name and purpose.

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

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

With no annotations, the description carries the full burden. It usefully discloses that this is a paid call ($0.001 USDC on eip155:8453 via x402), which is real behavioral context an agent needs before invoking. It does not disclose what happens on malformed input or how query parameters with duplicates/encoding are handled, so the disclosure is partial.

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

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

Two tight sentences with the core purpose front-loaded and no filler. The pricing clause is appended after an em-dash and reads as an unrelated tag rather than integrated information, which slightly disrupts the flow but does not waste space.

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 correctly enumerates the returned components, which is exactly what an agent needs to know the shape of the result. It omits error behavior for invalid URLs and any note about query-string edge cases, leaving a small gap for a tool of this simplicity.

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

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

There is a single parameter with 100% schema description coverage, so the baseline is 3. The schema description is only 'URL', and the description adds nothing about accepted formats (absolute vs relative, scheme required, encoding) beyond restating that a URL is parsed.

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 ('Parse') and resource ('a URL') and enumerates the exact output components (protocol, hostname, port, path segments, query params as a clean object, hash, credentials). This enumeration implicitly separates it from siblings like dev_url_encoder, dev_url_reader, and live_url_metadata 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 phrase 'Exact — no guessing by eye' hints at when to prefer this over manual inspection, which is a mild usage cue. However, there is no explicit when-to-use guidance and no comparison against the closely related siblings dev_url_encoder, dev_url_reader, or live_url_metadata, so the 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?

With no annotations, the description carries the full burden and does so well: server-side fetch, SSRF guard with redirects re-validated, 10s timeout, 1MB cap, and an explicit x402 price ($0.005/call, USDC, eip155:8453). Security posture, resource limits, and cost are all disclosed—far beyond typical coverage.

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 action and output, then the operational constraints. The marketing-flavored clause ('The reader pattern agents use to actually understand web pages') is softer than the rest but still hints at usage; overall tight and well ordered.

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 annotations or output schema, the description supplies purpose, output shape, safety, limits, and pricing—enough to invoke correctly. Minor gaps remain: behavior on non-HTML/PDF pages, whether JS is rendered, and what a truncated response looks like at maxChars.

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 url and maxChars are already documented in the schema, and the description adds no per-parameter semantics (e.g., truncation behavior when maxChars is hit). The '1MB cap' refers to a server limit, not to maxChars semantics. 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?

Specific verb+resource: 'Fetch a web page server-side and convert it to clean markdown,' with concrete detail on what is kept (headings, links, lists, tables, text) and stripped (scripts, styles, boilerplate). This clearly separates it from data-extraction siblings like live_url_metadata or dev_pdf_to_text, which do not return readable page markdown.

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 line 'The reader pattern agents use to actually understand web pages' implies when to reach for it (full-content comprehension rather than metadata), but it never names an alternative or states an exclusion, despite the domain-overlapping sibling live_url_metadata. Usage is inferred 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?

With no annotations, the description carries the full burden. It usefully discloses the randomness source (real CSPRNG), the v4-vs-v7 distinction (random vs time-sortable), and what validation covers (format, version, variant bits), plus a $0.001/call x402 price. However, it says nothing about output shape, error behavior on malformed input, or the odd requirement that all three parameters be supplied.

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 covering both operations, followed by a compact pricing note. Nothing is redundant, though the trailing pricing clause is a slight dilution of an otherwise tight definition.

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

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

There is no output schema and no annotations, so the description is the only source of behavioral detail. It covers the generation and validation semantics well but omits return format and the fact that the schema marks all three parameters as required even though 'value' and 'version' are operation-specific, which an agent needs to know 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 the baseline is 3, but the description adds real semantic value: it explains that v7 is time-sortable while v4 is purely random, and that validation inspects version and variant bits, which is more than the bare 'Operation'/'Version (generate)' schema descriptions convey.

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 specific verbs and resources: generating UUIDv4/UUIDv7 values and validating a UUID's format, version and variant bits. It distinguishes the two operations clearly, and no sibling in the list overlaps with UUID generation/validation, so the agent can place it immediately.

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 implies the two modes ('generate ... and validate ...') and mentions the CSPRNG source, but gives no explicit when-to-use guidance, no note that 'value' applies only to validate and 'version' only to generate, and no mention of alternatives. Usage is inferable from the operation split 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses a payment requirement (x402, $0.001/call in USDC on eip155:8453), which is real context an agent needs. However it says nothing about edge cases (zero/negative values or years), whether the result is a decimal or percentage, or failure behavior for invalid inputs.

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

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

Front-loaded formula statement followed by the pricing note in a single compact block, with no filler. The em-dash-joined pricing clause is slightly awkward but costs almost nothing.

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

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

For a three-param math tool with no output schema and no annotations, the definition covers inputs and cost but omits the return format (percentage vs. decimal) and edge-case behavior. Adequate but with a clear gap for an agent that must interpret 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 coverage is 100%, so all three parameters (initial, final, years) are already documented in the schema. The description restates the same three inputs without adding units, sign conventions, or expected ranges. Baseline 3 is appropriate when the schema does the work.

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 metric (compound annual growth rate) and gives the exact framing — initial value, final value, number of years — which is precise enough to distinguish it from a generic interest calculator. It does not explicitly route against its closest siblings (compound_interest_calculator, roi_calculator), so it falls short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative tool is named. 'The standard way to annualize returns' implies the use case but leaves the agent to infer that compound_interest_calculator or roi_calculator are the wrong choice.

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

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

With no annotations, the description carries the full burden. It usefully discloses the validation steps, that a pretty-printed grouping is returned when valid, and the per-call x402 price/payment chain. However, it never states what happens on invalid input (error vs. boolean), so a mutation-free-read tool's failure behavior remains opaque.

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 clause describing what is checked followed by return-value and pricing notes; the core purpose is front-loaded and no sentence is wasted. The em-dash price suffix is slightly awkward but compact.

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 validator with no annotations and no output schema, the description covers the validation semantics, the valid-case return value, and the payment requirement. It is only short of the invalid-case response shape, which for a boolean-style validator is a minor omission.

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

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

Schema description coverage is 100% and the single 'iban' parameter is already documented, including that spaces are ignored. The description adds no syntax, format, or normalization detail beyond what the schema 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?

States a specific verb (Validate) plus the exact resource (International Bank Account Number) and enumerates the checks performed: country code, country-specific length, and ISO 7064 MOD 97-10 check digits. This is unambiguous and clearly distinct from the calculator/converter 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 — you validate an IBAN before relying on it — but there is no explicit when-to-use, when-not-to-use, or alternative named (the nearest analog, dev_email_validator, is not referenced, though it is a different domain so that is forgivable). Adequate but with a clear gap.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the core computation outputs and adds a useful cost notice (x402 price $0.001/call), but it omits output format, rounding behavior, and edge-case handling.

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

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

The definition is compact and front-loads the calculation before appending the payment detail. The aside about 'the two numbers people constantly mix up' adds mild educational value without derailing the main instruction.

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 low-complexity two-parameter calculator with no output schema, the description names the computed values but does not describe the return structure, numeric precision, or handling of zero/negative inputs. It is adequate but incomplete.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds minor clarity by calling cost a 'unit cost' and price a 'selling price', but does not contribute units, currency, or validation rules beyond the schema.

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

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

The description clearly states a specific verb (Calculate) and resources (gross profit, profit margin, markup) scoped to cost and selling price. It does not explicitly differentiate itself from sibling calculators like finance_roi_calculator or calculators_percentage_calculator, so it falls just short of the top score.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternative tools. The role is implied by the calculation description, but the definition provides no routing signals for choosing this over sibling finance or percentage calculators.

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

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

With no annotations, the description carries the full burden. It usefully discloses the x402 payment model and exact price ($0.001/call, USDC on Base), which is real behavioral context, and defines the returned quantities. It does not, however, state error behavior (e.g., what happens if initial=0) or latency/payment-failure handling.

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

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

Two front-loaded sentences: the computation first, then pricing set off by an em dash. Little waste, though the pricing detail could arguably sit in a separate cost field.

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

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

For a simple two-parameter compute tool with no output schema, the description supplies the semantics of both results (profit/loss and percentage) plus cost per call, which is enough to invoke it correctly. Only payment-error and edge-case behavior are 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% and both parameters are documented there as 'Amount invested' and 'Final value'. The description's phrase 'relative to the initial amount invested' only echoes the schema, adding no new syntax or constraint information, 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 ('return on investment') and spells out the two outputs: profit/loss and percentage return. This clearly separates it from siblings like finance_cagr_calculator and finance_margin_calculator, which compute different financial ratios.

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 choose this tool over the other finance calculators, and no mention of prerequisites such as needing a funded x402 wallet. The agent must infer usage purely from the name and formula 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?

With no annotations, the description carries the full behavioral burden. It does disclose useful behavior: weekends are excluded, real public holidays for the supplied country are fetched from Nager.Date and excluded, and the response includes a weekend/holiday breakdown. It omits date format expectations, invalid-range handling, and network dependency failure modes, so it is helpful but incomplete.

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 dense sentences with the core behavior front-loaded and zero filler. The trailing x402 price note is relevant but appended in a slightly clipped way rather than integrated.

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

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

For a three-parameter tool with no annotations and no output schema, the description covers purpose and the exclusion behavior adequately, but leaves the caller guessing about date format, ordering, edge cases (start after end), and failure behavior when the holiday service is unavailable.

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 three parameters are already documented in the schema. The description reinforces the country/holiday linkage and the start/end date range but adds no format, range, or ordering semantics beyond it — baseline 3.

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

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

States a specific verb and resource ('Count business days (Mon–Fri) between two dates') plus the distinguishing feature (weekend and holiday breakdown, holidays via country code). It is clearly distinct from the generic siblings like calculators_date_difference_calculator, though it never names that sibling explicitly to route the agent.

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

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

Usage is implied by the description — you call it when you need business-day counts rather than raw date differences — but there is no explicit when-to-use/when-not guidance or named alternative, leaving the agent to infer the selection rule.

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

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

With no annotations, the description carries the full burden. It usefully discloses the resolver source, that results are live, and the paid access model ('x402 price $0.002/call (USDC, eip155:8453)'), which is real behavioral context. However it says nothing about failure behavior for nonexistent domains, caching/TTL freshness, rate limits, or timeouts.

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 verb and resource, followed by use cases and pricing in a compact two-clause form. The trailing price fragment is terse but not wasteful; nothing is 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 lookup with no output schema and no annotations, the description covers purpose, context and cost but is silent on what a response looks like (record values, multiple answers, error shape for NXDOMAIN). An agent can call it correctly but cannot anticipate 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 both parameters are documented with the record-type enum, so the schema does the heavy lifting. The description's record-type list mirrors the enum and adds no syntax or format detail (e.g. whether domain accepts subdomains, IDN, or trailing dots).

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 ('Query live DNS records') and enumerates the record types supported (A, AAAA, MX, TXT, NS, CNAME, SOA), which the agent can map directly onto the schema enum. It also names the resolving backend (Cloudflare DNS-over-HTTPS), distinguishing it from lookups like live_ip_lookup.

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 concrete use cases ('domain validation, email deliverability pre-checks and infrastructure discovery'), which tells the agent when this tool is the right pick. It does not name alternatives (e.g. live_ip_lookup) or state when not to use it, so it stops short of full 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?

With no annotations, the description carries the full burden and does well: it discloses the upstream source (ECB via frankfurter.dev), the refresh cadence (every business day), the one-hour cache TTL, and a per-call price with chain/currency. It omits error/rate-limit behavior and what an empty 'from'/'to' means, but the operational profile is substantially richer than the schema alone.

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

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

Front-loaded and compact — the data source and the two modes come first, with pricing appended. No wasted framing, though the em-dash price block is somewhat dense.

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 5-parameter, no-annotation, no-output-schema tool, the description covers provenance, freshness, and cost but leaves the op-to-parameter mapping and response shape unexplained. The agent has enough to know what it is, but not fully how to fill all five required fields correctly per mode.

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, and the schema descriptions are notably terse ('Operation', 'Convert to', 'Amount'). The description mentions the base-currency table and amount conversion but never clarifies which of the five required parameters apply to which op, leaving that inference to the agent.

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 ('Live foreign-exchange reference rates from the European Central Bank') and enumerates the two operating modes (full rate table vs cross-rate conversion). This clearly differentiates it from sibling tools like crypto_price, converters_*, and finance_* calculators.

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

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

The description describes the two available behaviors but never explicitly maps them to the 'rates'/'convert' op values, nor states when to prefer this tool over alternatives such as crypto_price or the static converters. Usage is 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the payment requirement and pricing ($0.002/call USDC, eip155:8453) and the return shape, but says nothing about error behavior, rate limits, or what 'any covered country' actually covers.

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-loads the capability and the returned fields in one sentence, then appends the price/call detail. Efficient with no redundancy, though the marketing-ish 'Essential for scheduling agents' clause adds little operational value.

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

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

There is no output schema or annotations, and the description compensates by naming the returned fields (names, dates, nationwide) plus the source and cost. Still missing coverage limits, defaults for `year`/`count`, and error behavior, 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 description coverage is 100%, so op/year/count/country are already documented. The description adds only that the two ops correspond to 'upcoming' vs 'full-year', which slightly enriches the enum but not the other 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?

States a specific verb and resource ('List upcoming or full-year public holidays'), names the data source (Nager.Date) and the returned fields (names, dates, nationwide flag). It's inherently distinguishable from the closest sibling live_business_days, but never explicitly differentiates itself from it.

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

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

'Essential for scheduling agents' implies a usage context but gives no explicit when-to-use or when-not-to-use guidance, and no comparison to alternatives such as live_business_days. Usage must be inferred from the verb and the two `op` 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?

With no annotations supplied, the description carries the full burden and does add real behavior: a 24-hour per-IP cache and a per-call x402 price with the payment chain (USDC, eip155:8453). It does not cover failure modes, rate limits, or auth mechanics, which keeps it out of the top band.

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

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

Front-loaded with the action and the return-field list, then appends the caching and pricing clauses. Dense but no filler; slightly long single-sentence packaging keeps it just under the top band.

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 tool with no output schema and no annotations, the description compensates well by enumerating return fields, cache lifetime, and cost. It lacks any note on error behavior or rate limits, but an agent has enough to call it correctly.

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

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

There is a single parameter with 100% schema description coverage; the schema already states 'Leave empty to look up the caller's IP' and the description merely restates that omission behavior. Baseline 3 is appropriate since 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 (geolocate) plus resource (IPv4/IPv6 address) and lists exactly what is returned (country, region, city, coordinates, timezone, ASN/network owner, currency). No other sibling tool in the catalog does IP geolocation, so differentiation is unambiguous.

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

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

The description implies usage by noting the address is optional and the caller's own IP is used when omitted, which tells the agent one key trigger condition. However, it offers no explicit when-to-use guidance relative to alternatives and no exclusions or prerequisites beyond the price note.

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

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

With no annotations, the description carries the full burden, and it does disclose the paid x402 model ('$0.0005/call, USDC, eip155:8453'), which is non-obvious and materially affects whether an agent invokes it. It also lists the return formats rather than leaving output undefined. It omits error behavior for an invalid tz string and any rate limit, so it is solid but not exhaustive.

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

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

Two sentences: purpose/output enumeration first, then the usage directive and pricing. Front-loaded and largely waste-free, though the long return-format list and the price tag hang off the same sentence rather than being cleanly separated.

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

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

For a single-parameter tool with no output schema, the description compensates by enumerating the returned representations (Unix, ISO 8601, weekday, day-of-year), and it covers cost. The remaining gap is failure behavior for an unrecognized time zone, which an agent might want 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?

Only one parameter (tz), and schema description coverage is 100% with concrete examples, so the schema already does most of the work. The description adds the term 'IANA time zone', which pins the accepted format more definitively than the examples alone, slightly exceeding the baseline.

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

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

The description gives a specific verb+resource ('Returns the current date and time') and then enumerates exactly what comes back: IANA-zone local time plus Unix seconds/ms, ISO 8601, weekday and day-of-year. That precision distinguishes it from the conversion siblings (converters_unix_timestamp_converter, dev_natural_date) which operate on supplied values rather than producing 'now'.

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?

'Use it whenever an agent needs to know now' states a clear triggering condition, which is stronger than implied usage. It stops short of naming alternatives or stating when-not to use it versus the timestamp/natural-date converters in the sibling set, so it doesn't reach the explicit-routing level.

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

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

With no annotations, the description carries the full burden and it does disclose important behavior: the return artifacts (ready-to-embed SVG markup and a data URI) and, notably, the x402 payment/auth model ($0.002/call in USDC on eip155:8453). It stops short of describing failure modes, size limits, or how the payment is transacted, so not 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.