kWhmate Calculators

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond that by disclosing data provenance and vintage (fares in effect since 1 June 2023, checked September 2026) and by stating that the response includes the source and page URL, which tells the agent the result is a cited estimate rather than a live quoted fare.

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

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

It is short and front-loads the purpose, then the source and vintage. Minor waste in the awkward fragment 'Same code as <url>.' and the doubled label 'Reference: Source:', which could be trimmed without losing information.

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

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

With no output schema, the description usefully covers the return shape (estimate plus source and page URL) and the data vintage, which is important for a regulated fare table. What is missing is any explanation of the four inputs, so the definition is only partially complete for a parameterized calculator.

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

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

Schema description coverage is 0% across all four parameters, and the description compensates with nothing: it never explains that km is distance, hour drives a late-night surcharge, slow_traffic_minutes affects the time-based meter, or what outside_busan changes. Only the parameter names themselves and the schema's ranges/defaults carry any meaning.

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

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

The description states a specific resource and scope: a Busan regular mid-size taxi meter fare estimate, and it names the exact source (Busan Metropolitan City, fares effective 1 June 2023). It does not, however, distinguish itself from the sibling seoul_taxi beyond the city name, so an agent must infer the split from the tool name alone.

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

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

Usage is only implied: the 'regular mid-size taxi' qualifier scopes it away from other taxi classes, and the URL points to the authoritative calculator. There is no explicit when-to-use statement, no mention of seoul_taxi or other fare tools as alternatives, and no note on prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context that annotations don't provide: it returns an estimate along with the source and page URL, and cites the legal basis (소득세법 제59조의4, 2025 tax amendment). This is valuable given there is no output schema.

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

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

Three short sentences that are front-loaded with the tool's identity. The Korean title duplicates the tool name slightly, but otherwise every sentence (source URL, legal reference, return behavior) carries information. 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?

For a two-parameter read-only calculator with no output schema, the description covers the essentials: what it computes, the legal basis, and a note on the return value (estimate plus source/page URL). It could say more about how items kinds map to credit rates, but the schema already enumerates the kinds.

Complex tools with many parameters or behaviors need more documentation. 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 'items' (including the kind:spend format) and 'decided_tax' (the credit cap). The description adds no parameter-level meaning 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?

The description names the specific resource (Korean education expense tax credit, 2026 spending) and states that it returns an estimate, so an agent can tell it computes a value. However, it never distinguishes itself from the closely related korea_tax_refund sibling, so the purpose is clear but not sibling-differentiated.

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

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

There is no when-to-use or when-not-to-use guidance. The description does not mention the overlapping korea_tax_refund tool, nor does it explain when a user should route here versus that sibling. The only contextual hint is the '2026 spending' qualifier.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully discloses that the result is an estimate ('Returns an estimate') and that it carries a source and page URL, but says nothing about what is presumed, rate tables used, or how the legal citation affects 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?

Reasonably short and front-loaded with the title, but a large share of the text is Korean legal citation and source boilerplate (지방세법 제13조의2...) that carries little selection value for an agent. Not wasteful enough to be penalized heavily, but not tight.

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

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

For an 8-parameter financial calculator with 13% schema coverage and no output schema, the description omits parameter meaning, output shape beyond 'an estimate', and any assumptions. The agent lacks the information needed to call it confidently.

Complex tools with many parameters or behaviors need more documentation. 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 only 13% — just 'houses' is documented — leaving price, jeonse, years, over_85m2, other_costs, adjusted_area and growth_percent unexplained in both schema and description. The description mentions acquisition tax and brokerage but never maps them to inputs, so it fails to compensate for the coverage gap.

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

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

The parenthetical '(Korean gap investment: acquisition tax, brokerage, cash needed)' gives a specific verb-like outcome set, and '실투자금' names the resource. An agent can tell it computes a gap-investment cash estimate. No sibling differentiation is needed because none of the listed siblings do this.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The '투자 권유 아님' line is a legal disclaimer, not usage guidance. The agent is left to infer that this applies to Korean property gap investment.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the result is an estimate carrying a source and page URL, which is useful behavioral context, but says nothing about precision, rounding, or how the two scale parameters interact.

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

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

It is short and front-loads the conversion scope, which is good, but a repetition of the title plus an external URL and a trailing return-value sentence dilute it. No sentence is harmful, but the title restatement earns little.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 0% schema description coverage and no output schema, the description leaves the parameter semantics and return format largely unexplained. The one caveat about formula variation is the only substantive content beyond the title.

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

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

Schema description coverage is 0%, so the description should carry the burden, yet it says nothing about score, to_scale, from_scale, their defaults, or the conversion direction. The enum values (4.5/4.3/4.0) are self-documenting in the schema, but the description contributes no parameter meaning.

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

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

The description restates the title verbatim ('학점 비례 환산 (GPA scale conversion 4.5 / 4.3 / 4.0)') rather than describing the operation, but the title/name together do convey a GPA scale conversion across 4.5/4.3/4.0. It never states the direction of conversion or distinguishes itself from siblings like naesin_grade or suneung_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?

It offers a caveat ('단순 비례 환산(참고용)' and that schools/companies use different formulas so the target's criteria take priority), which hints this is an approximation tool, but gives no explicit when-to-use condition and names no alternative tool.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, self-contained calculation. The description adds that the result is an estimate and that it carries source and page URL, but says nothing about rate structure, tiered-pricing behavior, or what happens at the amperes/kWh boundaries — modest added value over annotations.

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

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

Short, front-loaded with the resource identity, and efficient overall. The inline Japanese source citation is dense but arguably earns its place by documenting provenance for a regulated-tariff estimate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 does briefly cover the return shape (an estimate plus source/page URL), which is appropriate. But with only a third of parameters documented anywhere and no usage context, it is thin for a tool whose correctness depends on picking the right kWh and ampere tier.

Complex tools with many parameters or behaviors need more documentation. 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 only 33% (just fuel_adjustment), so the description carries the burden for kwh and amperes — and it provides nothing. No hint that kwh is monthly consumption or that amperes selects the contract breaker tier, and no explanation of how the default fuel adjustment is derived beyond the schema's brief note.

Input schemas describe structure but not intent. Descriptions should explain 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/resource combination — computing a Japanese (TEPCO Juryo Dento B) electricity bill — and the country/utility qualifier implicitly separates it from siblings like kr_electricity, tw_electricity, and ph_meralco. However, the first sentence merely restates the title verbatim, and it never explicitly contrasts itself with the other electricity tools, so full differentiation is left to inference.

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

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

There is no statement of when to use this tool, when not to, or which alternative to pick (e.g., kr_electricity vs tw_electricity for other markets). The only directional content is a reference URL, which points at documentation rather than at tool-selection context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that a source attribution and page URL are returned, which is useful, but it discloses nothing about the assumptions behind the estimate, unit conventions, or rounding, which matters for a savings calculator.

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

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

It is short and front-loaded, leading with the resource and tariff. The 'Same code as <URL>' clause is promotional noise that does not help an agent invoke the tool, but the overall size is appropriate and not 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?

With no output schema present, the description does at least note that an estimate plus source URL is returned, which is more than nothing. But for a six-parameter financial calculator it omits the meaning of the estimate, the tariff assumptions, and the undescribed hours_per_day parameter, leaving real 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 83%, so the schema documents count, led_cost, new_watts, old_watts, and other_kwh on its own. The description adds no parameter-level meaning and leaves hours_per_day (undescribed in the schema) unaddressed, so it is a baseline case where structured fields do 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?

The description states the resource (Japan LED replacement savings) and adds tariff context (TEPCO Juryo Dento B, 30 A), so the domain is identifiable. However, it largely restates the title verbatim and never articulates the actual computation (cost/payback comparison between old and new wattage), so it stays at the vague-purpose tier rather than a specific verb+resource claim.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 its obvious siblings kr_led_savings, ph_led_savings, and tw_led_savings. The only differentiator is the implicit 'Japan/TEPCO' framing; nothing tells the agent to pick this one for Japanese tariffs and a different sibling elsewhere.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds one piece of genuinely useful behavior: the result is an estimate that carries its source and page URL, which matters because there is no output schema. It does not disclose how multiple receipt amounts are aggregated or what the estimate is denominated in.

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

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

Short and front-loaded, with the purpose in the first phrase. However, the citation block (sources, site URL, checked October 2026) occupies more space than the functional content, and the 'same code as' URL is provenance trivia rather than decision-relevant information.

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

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

With no output schema, the description does carry some return-value burden and does say the estimate comes with a source and page URL. But it leaves the interpretation of stay_days and the multi-receipt aggregation behavior unexplained, which an agent needs to call this 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 67%, and the description contributes no parameter information at all. stay_days has no schema description and is never explained in prose, and nothing clarifies whether the returned estimate is per-receipt or summed across the amounts array. The description does not compensate for the coverage gap.

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

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

States a specific verb+resource: estimating a Korea tourist VAT refund. It is clearly distinguishable from the sibling calculators (electricity, taxi, GPA, loans) by domain and currency. It does not explicitly differentiate itself from any one sibling, but the domain is narrow enough that selection 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?

No when-to-use, when-not-to-use, or alternative-tool guidance is given. The only contextual hint is the reference URL and citation trail, which says nothing about when an agent should call this versus, say, travel_budget. Usage must be inferred entirely from the name and title.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by disclosing that the result is an estimate, that it carries a source and page URL, and that the same code powers kwhmate.com. It omits whether taxes/levies are included in the estimate, which keeps it from a 5.

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

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

Front-loaded with the resource and tariff, then provenance and return shape in two short sentences. The Korean reference line and URL are somewhat noisy but do carry sourcing information, so nothing is plainly 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?

With no output schema, the description covers the essentials: it is an estimate, it cites source and page URL, and the tariff vintage (2026 Q4). Currency, whether VAT and environmental charges are included, and the exact shape of the returned estimate remain unspecified, leaving a minor gap.

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

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

Schema description coverage is 100%, so kwh and season are already fully documented with defaults, bounds and enum semantics. The description's mention of 'progressive tiers' hints at why usage matters but adds no format or edge-case 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 resource (Korea household electricity bill) and narrows it with the exact tariff (KEPCO residential low-voltage, progressive tiers), which implicitly separates it from jp_electricity, tw_electricity and ph_meralco. It never names a sibling or explicitly contrasts, so it stops short of a 5.

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

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

The scope (household, low-voltage, Korea) implies when the tool applies, but there is no explicit when-to-use statement, no exclusions (e.g. commercial/industrial tariffs or other countries unsupported), and no routing to alternatives. Usage must be inferred from the title.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds the tariff basis (2026 KEPCO residential low-voltage table, other season) and that the result is an estimate carrying its source and page URL, but says nothing about how the estimate is computed or what happens with default parameters.

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

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

Front-loads the purpose and modes, which is good, but the middle sentence mixes Korean reference text and a website URL that do little for an invoking agent, and the sizing is uneven for the amount of actionable information conveyed.

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

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

With no output schema, the description partially covers returns ('an estimate with the source and page URL'), and it grounds the calculation in a named tariff. It stops short of documenting units or the meaning of defaults, but is reasonably complete for a read-only calculator.

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

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

Schema coverage is only 38% across 8 parameters, so the description has to compensate. It clarifies the key mode-dependent semantics (home = progressive tiers using other_kwh, shop = unit_price x kWh), which maps mode/unit_price/other_kwh, but the remaining wattage, count, led_cost and hours parameters get no explanation beyond their names.

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

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

States a specific resource (Korea LED replacement savings) and the two calculation modes (household tiers vs shop unit price), which lets an agent distinguish it from the country siblings jp_led_savings, ph_led_savings and tw_led_savings. The verb is implicit (it is a calculator), but the scope is clear.

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

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

The description implies two usage paths via the mode parameter and the Korean reference note (household = KEPCO tariff, shop = enter your own unit price), but it never explicitly says when to pick this tool over kr_electricity or the other LED tools. Guidance is inferred rather than stated.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds useful behavioral context: it returns an *estimate* (not an authoritative grade) along with a source and page URL, which sets expectations about accuracy. It does not, however, explain rounding rules or edge cases in the relative-evaluation model.

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

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

The description is compact and front-loads the core purpose before the reference URL and return note. The external URL and Korean reference line are slightly noisy, but nothing is egregiously wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 return-value meaning, and it partially does ('Returns an estimate with the source and page URL'). For a 4-parameter tool with two undocumented required params, though, it is not fully complete: an agent lacks guidance on the rank/students semantics and on what the returned estimate's scale looks like.

Complex tools with many parameters or behaviors need more documentation. 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 only 50%: ties and system are documented in the schema, but rank and students have no description anywhere. The description mentions the 5-/9-grade system (mapping to the system param) but adds nothing about what rank or students mean, leaving the two required parameters semantically bare.

Input schemas describe structure but not intent. Descriptions should explain 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+resource: converting Korean high-school class rank (내신) into a 5- or 9-grade class rank. This clearly differentiates it from siblings like suneung_score (CSAT) and gpa_converter. However it does not explicitly name those siblings to sharpen the distinction.

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

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

There is no explicit statement of when to use this tool versus alternatives such as gpa_converter or suneung_score. The only routing signal is the parenthetical '(5- or 9-grade system)', which implies the domain but leaves the agent to infer when this conversion applies. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are established. The description adds useful behavioral context by pinning the fixed rate basis (Meralco residential rates, October 2026) and disclosing that the result carries a source and page URL, but it never says the rates are non-configurable or what happens to the optional payback 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?

Short and front-loaded, with the key scoping fact (Philippines/Meralco) first. However, the fragment 'Reference: Rates: Meralco residential rates, October 2026' is awkwardly stacked and the bare URL adds little for an agent.

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

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

There is no output schema, and the description fills that gap by saying the tool returns an estimate with the source and page URL. Rates basis and region are stated, so an agent can call it correctly without further research, though the absence of any usage routing keeps it short of 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 83%, so the schema already explains nearly every parameter (count, led_cost, old_watts, new_watts, other_kwh), and the description adds nothing beyond it. Baseline 3 applies; the only uncovered parameter, hours_per_day, is left to its self-evident name.

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

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

The description states the specific resource (LED replacement savings estimate for the Philippines) and the rate source (Meralco), which cleanly separates it from the jp/kr/tw_led_savings siblings. It is nearly a verbatim restatement of the title, but the added 'Returns an estimate with the source and page URL' clause pins down the output.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named. It provides a reference URL for the equivalent web calculator but does not tell an agent under which circumstances to prefer ph_led_savings over ph_meralco or the other regional savings tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the rate vintage (October 2026 announcement), the fact that lifeline discounts and local taxes are excluded, and that the response includes source and page URL — all consistent with a read-only, closed-world lookup.

Agents need to know what a tool does to the 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 and the whole thing is short, but it is a run-on with redundant fragments ('Same code as <url>. Reference: Source: ...') that repeat rather than add information. Trimming the URL and the duplicated 'Reference/Source' would lose 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 single-parameter, no-output-schema calculator, the description covers what the agent needs: what is computed, what is excluded, what the return contains, and the data vintage. Only the meaning/units of 'kwh' and the applicable region boundary 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?

There is only one parameter and schema description coverage is 0%, so the schema documents only type/default/min/max. The description never mentions 'kwh' at all, though the unit is self-evident from the name and the electricity-bill domain, so an agent can still call it correctly.

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

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

The description states the resource (Philippines Meralco residential bill for the current month) and implies the action (estimate a bill from usage), which distinguishes it from the regional siblings like jp_electricity and kr_electricity. However, the verb is never explicit ('calculates/estimates'), so the agent must infer it from the name and the kwh parameter.

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

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

Scope is implied by the title/region, and the exclusion note (lifeline discounts and local taxes not included) tells the agent when the result is not applicable. But there is no explicit when-to-use guidance and no mention of the sibling bill/rate tools (tw_electricity, jp_electricity, kr_electricity) to route between them.

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

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

Annotations already establish that this is a safe read (readOnlyHint=true) and closed-world (openWorldHint=false). Beyond that, the description discloses useful behavioral traits: it returns an estimate along with the source and page URL, cites the governing statutes, gives an effective reference date (확인일 2026-10-12), and explicitly labels the result as reference-only (참고용 추정치), which warns the agent not to treat it as an authoritative figure.

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

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

The body repeats the title verbatim as its first sentence, then piles on statutory references and a version date, which crowds out the more useful 'returns an estimate with source and page URL' note. Content is relevant but not front-loaded or tightly edited.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 calculator with no output schema, the description covers what matters: the domain, the legal basis, that the output is an estimate, and what accompanies it (source and page URL). The main gap is the absence of any when-to-use guidance relative to its many sibling calculators.

Complex tools with many parameters or behaviors need more documentation. 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 meanings (evasion=탈세 제보, hidden=은닉재산, card=카드 결제 거부, public=공익신고, corruption=부패신고) are fully documented in the schema itself. The description only echoes the category list from the title and adds no syntax, format, or interpretation guidance beyond that, so the baseline of 3 applies.

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

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

The description names a specific resource (Korean whistleblower reward / 신고 포상금·보상금) and enumerates the covered claim types (tax evasion, hidden assets, card refusal, public interest, corruption), which is enough to separate it from the sibling calculators (korea_tax_refund, education_tax_credit, etc.). It also states it 'Returns an estimate,' so the verb is inferable even though the leading text largely restates the title.

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

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

There is no statement about when to pick this tool over siblings or when it is inappropriate; the only routing signal is the domain (Korean whistleblower rewards) and the note that it mirrors gyesanmate.com/reward/calculator/. No prerequisites, exclusions, or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context: it returns an estimate along with source and page URL, and it pins the fare vintage (effective Feb 2023, checked Sept 2026). It does not explain what the estimate includes (tolls, surcharges) or how late-night rates are applied.

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

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

The core purpose is front-loaded, but 'Same code as <calculator URL>' is developer-facing metadata with little value to an agent, and the 'Reference: Source:' wording is redundant. The vintage sentence earns its place; the URL sentence largely does not.

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

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

For a read-only calculator with no output schema and no nested objects, the description covers the essentials of what comes back. However, with half the parameters undocumented and no explanation of the estimate's components, an agent cannot fully reason about the result's scope.

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

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

Schema description coverage is only 50%; only hour and slow_traffic_minutes are documented in the schema. The required km and the outside_seoul flag have no description anywhere, and the description adds no parameter meaning beyond naming the inputs indirectly.

Input schemas describe structure but not intent. Descriptions should explain 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 and scope: a Seoul regular mid-size taxi fare meter estimate, and differentiates the city implicitly via the name (vs the busan_taxi sibling). It is clear what it computes, though it does not explicitly contrast itself with busan_taxi in prose.

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

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

No when-to-use or when-not-to-use guidance is given. There is no mention of when to prefer this over busan_taxi or a generic travel_budget tool, and no prerequisites such as flagging that the fare table has a fixed vintage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context: it returns an estimate (not a definitive figure), cites a specific government notice (교육부고시 제2026-12호), and warns that rates must be confirmed against the latest announcement.

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

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

The purpose is front-loaded in two languages, which is effective. However, the trailing URL, citation code, and '상환율은 최신 공지 확인' clause are loosely attached and add clutter without organizing information for the caller.

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

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

For a seven-parameter financial calculator with no output schema and 14% parameter coverage, the description omits essential guidance on how the inputs drive the estimate. It states the return shape (estimate with source and page URL) but leaves the parameter surface largely unexplained.

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

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

Schema coverage is only 14% — just one of seven parameters (gross_salary) is documented in the schema. The description does nothing to compensate: it never explains type, degree, principal, defer_years, repay_years, or rate_percent, leaving most inputs semantically opaque.

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

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

The description names the resource (Korean student loan repayment) and the two supported modes (general/standard vs income-contingent ICL), which is enough to tell what the tool computes. It does not explicitly distinguish itself from the sibling calculators, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives, nor any preconditions. The only routing hint is the implicit general/ICL mode split, which is left to the caller to infer from the schema rather than the description.

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

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

With readOnlyHint=true and openWorldHint=false already declaring a safe, closed-world read, the description adds genuine behavioral context: the result is an estimate, it returns the source and page URL, it is based on the 2027 CSAT reference, and grade cutoffs vary yearly with actual scoring. These caveats go beyond the annotations, though it says nothing about how inputs affect or limit 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?

It is reasonably short and front-loads the operation, but mixes Korean/English, a URL, and reference notes in a somewhat jumbled run-on. Nothing is wasted, but the structure is not cleanly organized around what the tool does versus what it returns.

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

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

For a 6-parameter calculator with no output schema, the description explains neither the required inputs (mean, sd, raw, percentile) nor how they interact, which is the critical missing information. The output-side caveats ('estimate', source URL) are covered, but the input side — the actual burden here — is absent.

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

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

Schema description coverage is only 17% (just the subject enum); sd, raw, mean, percentile, and english_raw carry no descriptions in schema or prose. The description does not compensate at all, so an agent cannot tell what sd vs mean vs raw should hold or how they combine.

Input schemas describe structure but not intent. Descriptions should explain 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 and title name a specific computation+resource (수능 표준점수·등급 / Korean CSAT standard score and grade), so the agent knows this converts CSAT raw scores into standard scores and grades. It does not differentiate from education siblings like naesin_grade or gpa_converter, but the purpose itself is unambiguous.

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

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

There is no explicit when-to-use guidance and no mention of alternatives among the education siblings (naesin_grade, gpa_converter). The only hint is that it 'returns an estimate', which is about output, not usage. The agent must infer applicability from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: it flags the output as an estimate ('결과는 추정치'), names the data sources (국토교통부 KTX fares, KOBUS bus timetable) with reference dates, and promises a source plus page URL. It does not, however, explain default behavior, precision, or how partial inputs 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?

The purpose is front-loaded in the first clause, but the description then packs in a URL, reference dates, and source attributions in mixed Korean/English. The reference block ('확인일 KTX 2026-10-12·고속버스 2026-10-13·출처...') is dense and partially redundant, though it is not egregiously long.

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

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

For an 18-parameter tool with 0 required params, no output schema, and 11% schema coverage, the description is thin. It never explains how the optional inputs combine (e.g., built-in fares vs. supplied fare, or min/max range pairs) or what a caller must supply for a meaningful estimate.

Complex tools with many parameters or behaviors need more documentation. 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 only 11% (2 of 18 params), so the description must compensate and largely fails to. It names the categories 'transport, stay, food, admission' which loosely groups the stay_/food_/admission_/fare params, but the 16 undocumented parameters (toll, car_km, fuel_price, car_km_per_l, rooms, people, nights, mode enums, etc.) get no explanation of units, interaction, or defaults.

Input schemas describe structure but not intent. Descriptions should explain 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 (Korea domestic trip budget) and enumerates the cost categories it covers (transport, stay, food, admission ranges), which is more than a tautology. Sibling tools are all unrelated calculators (tax, electricity, GPA), so no differentiation is required. It is clear what the tool computes, though the reference metadata slightly muddies the opening.

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

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

There is no statement of when to use this tool, when not to, or what alternatives exist. The only usage-adjacent sentence is 'Returns an estimate with the source and page URL,' which describes output rather than selection criteria.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and offline-determinism are covered. The description adds useful behavioral context – it is an estimate, pinned to the 2025-10-01 rate schedule and the 2026 freeze, and it returns the source and page URL – but says nothing about rounding, currency/units, or error handling for out-of-range input.

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

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

Three short sentences, front-loaded with the purpose, with the reference line and return-value note after. No redundancy, though the Chinese-language citation is dead weight for an agent that cannot use it to select or invoke the tool.

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

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

With no output schema, the description correctly covers the return shape ('an estimate with the source and page URL'). Combined with annotations covering the read-only profile, an agent has enough to invoke it; the main residual gap is that units (NT$) and the estimate's precision are never stated.

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

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

Schema description coverage is 67%: summer and bimonthly are documented in the schema, while kwh carries only default/min/max with no prose. The description's mention of 'progressive rates' implicitly explains why kwh drives the bracket computation and why bimonthly doubles brackets, but it adds no parameter-level detail beyond the schema.

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

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

The description names the resource (Taiwan electricity bill) and the specific pricing model (Taipower residential progressive rates), which clearly separates it from sibling calculators like jp_electricity, kr_electricity, and ph_meralco. It is a calculator, so the verb is implicit rather than stated, but the scope is unambiguous.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative for adjacent cases (e.g. time-of-use vs progressive rates). The only contextual cue is the source URL, which the agent must infer is a companion web calculator.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds genuine value: it discloses the exact pricing model used (Taipower residential progressive pricing, non-summer, monthly brackets), the upstream code source, and that the result includes a source and page URL — meaningful context for trusting the output.

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

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

Three short sentences, front-loaded with scope and model, with no filler. The only waste is the first sentence duplicating the title verbatim instead of stating the action.

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

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

For a 6-parameter calculator with no output schema, the description covers the model, the provenance, and the return shape reasonably well. It leaves gaps on parameter behavior — what defaults do, whether led_cost drives a payback figure, and how the monthly bracket interacts with other_kwh — which an agent cannot resolve from the schema alone.

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

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

Schema description coverage is 83%, so the schema already documents nearly every parameter and the baseline is 3. The description adds no parameter-level meaning (no explanation of defaults, of what led_cost=0 implies, or of how other_kwh interacts with the bracket calculation).

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

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

The description identifies a specific computation (Taiwan LED replacement savings) with a named tariff basis (Taipower non-summer, monthly brackets) and states it returns an estimate. The region scope implicitly separates it from jp_led_savings/kr_led_savings/ph_led_savings, but no sibling is named and the opening sentence is a verbatim restatement of the title rather than a verb-led statement.

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

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

There is no when-to-use guidance and no routing to alternatives such as tw_electricity or the other regional LED savings tools. The tariff assumption is stated, which helps a knowledgeable agent judge applicability, but nothing tells the agent when this tool is the right choice versus a sibling.

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