Refnusa

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

No annotations, so the description carries the full burden, and it does well: it discloses that this is an estimate bounded by the payslip, the tax regimes applied (PP 58/2023 TER vs December annual recalculation), and that output is itemized per line with its decree. It does not discuss determinism, precision, or rounding, which leaves a modest gap 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?

Three compact sentences, purpose front-loaded, then input mode, then the caveat. No redundancy and every clause carries information (deduction types, decree basis, UMK option).

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

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

For a 9-parameter calculation tool with no output schema, the description correctly conveys what is computed and hints at the itemized return ('each line with its decree'). It is close to complete; only the exact return shape and which statutory constants are assumed by default 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 already 100%, so the baseline is 3, but the description adds real value: it clarifies the mutual exclusivity of gross and regency_code (the latter substituting the kabupaten/kota UMK as gross) and explains that the month parameter selects the TER table versus December recalculation. These clarify intent beyond the field-level docs.

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), resource (net/take-home pay), and precise scope: worker BPJS deductions (JHT, JP, JKN), PPh 21 via PP 58/2023 TER or December recalculation, plus employer contributions. This cleanly distinguishes it from the data-lookup siblings (get_bpjs_rates, get_pph21_ter, get_ptkp), which fetch rates rather than compose them into a salary computation.

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 input-mode context ('Give gross, or regency_code to use that kabupaten/kota UMK') and a caveat ('An estimate; the employer payslip decides'), but never states when to pick this tool over the sibling getters, nor any when-not condition. Usage is implied rather than 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 behavioral burden. It does add genuine context beyond the schema: the result includes the decree the date was checked against, and weekends only count when the decree names them. Coverage limits, error behavior, and year ranges remain undisclosed.

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 no filler, and the core purpose is front-loaded ahead of the edge-case clarification about weekends.

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, so the description usefully characterizes the return content (holiday status plus the decree used) and clarifies the weekend rule. For a one-parameter lookup this is nearly sufficient, though coverage years and behavior for invalid/non-decree dates are omitted.

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

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

Schema description coverage is 100% (the single date parameter documents YYYY-MM-DD format and type), so the schema already handles parameter semantics. The description adds no further format, timezone, or range detail, 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 and resource: determines whether a single date is a public holiday or cuti bersama. The phrase 'one date' implicitly separates it from the sibling get_holidays, but the sibling is never named, so the contrast must be inferred.

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 'whether one date is...' — you call it with a single date to test that date. There is no explicit statement of when to prefer this over get_holidays or any exclusion/precondition, leaving the agent to infer the single-date vs. list distinction.

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 meaningful context: the authoritative source (OJK head-office list), the version date (June 2026), and the unfiltered-call behavior (all 105 rows). It does not describe the return shape or whether name matching is case-insensitive.

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

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

A single dense sentence that front-loads the resource, then the filters, then the no-argument default. No filler, though the semicolon-packed phrasing is slightly heavy for the amount of 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?

There is no output schema, so the description should ideally sketch the return values; it implies code/name pairs and a count but doesn't state the format. Given the simple read-only lookup and fully documented parameters, it is otherwise complete for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds some value by framing `code` as an exact three-digit Sandi Bank identifier and `name` as a partial-name match, but it does not elaborate on matching rules beyond what the schema 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 names a specific resource (three-digit Sandi Bank codes), a precise scope (commercial and sharia banks on the OJK head-office list of June 2026), and the two lookup modes. It is unmistakably distinct from siblings like get_postal_code, get_wilayah, or get_kbli.

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 the two selection conditions ('by code or by part of the bank name') and the default ('no argument lists all 105'), which tells the agent exactly how to invoke it. It does not name an alternative sibling, though none is an obvious substitute here.

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

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

With no annotations the description carries the full burden, and it discloses useful behavioral context: each rate ships with its underlying decree, JKK maps to PP 6/2025 bands, and it flags a source discrepancy (article 18913 says Rp10.547.000 vs the Rp10.547.400 cap, pointing to the row note). That is genuine data-quirk transparency; only return format/pagination detail is absent, which is minor for a static reference table.

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 what the tool returns, then the caveats. The second sentence is dense but each clause (JKK bands, wage cap, cross-source note) carries information an agent would otherwise get wrong.

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 explains what comes back (percent rates per program with the governing decree) and warns about the wage-cap discrepancy. For a two-enum reference lookup this covers the essentials; only an explicit note on return shape is missing.

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

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

Schema description coverage is 100% with both enums fully documented, so the schema already explains status and program. The description's program list merely echoes the enum rather than adding syntax or default nuance, 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 (BPJS contribution rates as percent of monthly wage) and enumerates the exact programs covered (JHT, JP, JKK, JKM, JKP, JKN) plus the decree provenance. The resource is distinct enough from siblings like get_tax_rates or get_pph21_ter that an agent can disambiguate, though it never names an alternative explicitly.

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

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

Contains no when-to-use, when-not, or alternative-selection guidance. The detail about JKK bands and the JP wage cap is data content, not invocation guidance, so the agent must infer that this is the reference lookup for BPJS rate questions.

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 meaningful work: it discloses the data source (PIHPS Nasional / Bank Indonesia), units (Rp/kg), the monthly granularity, the start boundary (May 2017), and the key quirk that each point is the price on the first day of the month with data (observed_on). It is weaker on what the response shape or missing-month behavior looks like, but the semantic quirks are well covered.

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

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

A single dense sentence front-loads the source, units, and scope, followed by a short note on optional range bounds. Nearly every clause earns its place; the trailing 'Optional from and to months' fragment is slightly clipped but useful.

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

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

For a 4-parameter read tool with no annotations and no output schema, the description covers source, units, granularity, observation-date semantics, and the temporal start point. It stops short of stating whether from/to are inclusive and how out-of-range or empty periods behave, which are the remaining gaps for an agent planning queries.

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, including the pattern for from/to and the enum for commodity. The description adds only marginal context ('optional from and to months', the May 2017 lower bound, units), which does not go far beyond the structured fields. 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: a monthly PIHPS Nasional price series in Rp/kg for one province and one commodity. The 'series ... from May 2017' framing implicitly separates it from the sibling get_food_prices_latest, but no sibling is named explicitly, which keeps it just short of a 5.

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

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

Usage is only implied: the historical, monthly nature of the series suggests analysis over time, and 'Optional from and to months' hints that ranges are the normal call pattern. There is no explicit statement of when to prefer this over get_food_prices_latest or get_het_prices, nor any exclusions or 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?

With no annotations, the description carries the full burden and does disclose genuinely non-obvious behavior: the tradisional-first fallback when a traditional price exists, the caveat that traditional markets cover fewer provinces, and the one-row-per-province-and-commodity shape. It omits auth requirements, rate limits, and result-size/pagination behavior, so it is strong 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 core purpose is front-loaded and the sentences are dense but purposeful, moving from what it returns to default behavior to parameter effects. Some redundancy with the schema descriptions (market precedence, month restrictions) costs a point, but there is no filler.

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

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

There is no output schema, so the description must explain return values, and it does: price in Rp/kg, province-and-commodity rows, each row naming its market and day. The remaining gap is the missing pointer to the sibling series tool for the monthly 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 baseline is 3; the schema already documents month, market, and commodity, including the "with month, groups only" restriction. The description largely restates those semantics ("Filter by commodity, province and market") rather than adding format or edge-case detail beyond them.

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

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

The first sentence names a specific verb (get), resource (PIHPS Nasional staple-food price), unit (Rp/kg), and granularity (per province, newest observation day), plus stated coverage of 10 groups and 21 items. An agent can distinguish this from get_food_price_series and get_het_prices without opening any schema, and the later clause about the monthly series further separates the two modes.

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

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

It gives conditional guidance for parameters ("Pass market for one market only", "With month ... traditional markets only"), which implies usage but never states when to prefer this tool over get_food_price_series or get_het_prices. The monthly-series mode in particular overlaps with a sibling and is not routed explicitly, leaving the agent to infer the boundary.

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

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

With no annotations, the description carries the full burden. It usefully discloses the data source (Kepmen ESDM 218.K/MG.01/MEM.M/2022) and the unit ('per litre'), but says nothing about whether this is a single current price or a time series, nor about read-only/public-access characteristics. Adequate but incomplete for a zero-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 tight sentences with zero filler; the scope limitation that most affects agent selection is front-loaded in the first clause. 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 lookup with no output schema and no annotations, the description covers unit, source regulation and inclusion scope. It leaves a meaningful ambiguity unresolved though: whether the returned price is a single latest value or a series, especially given sibling tools that split 'latest' from 'series' for food prices.

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 enum parameter is already fully documented in the schema, so the baseline is 3. The description contributes the local-language mapping (Solar, minyak tanah, RON 90), which partially bridges to the enum values kerosene/gas_oil/ron90, but the schema already labels gas_oil as 'Solar'.

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 exact resource (retail price per litre of subsidised/special-assignment fuels) and enumerates the covered fuels, so an agent can tell it apart from neighbours like get_het_prices or get_ojol_tariffs. It omits an explicit verb and never names a sibling it should be preferred over, 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?

Scope is defined negatively ('Non-subsidised fuels are not included'), which implies when the tool applies, but there is no explicit when-to-use statement, no prerequisites, and no named alternative for non-subsidised fuel queries. Usage must be inferred from the scope clause rather than read directly.

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 meaningful behavioral traits: the legal provenance of each row set (Perbadan Bapanas 5/2024, Kepgub 801/2024) and a data-currency warning that a later decision (299/2025) may have superseded the underlying regulation and that the change is unverified. That staleness/provenance disclosure is high-value. It still omits return shape, ordering, and error behavior, 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.

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

Information is front-loaded: the resource and scope come first, followed by the caveat. It is a single dense sentence with no filler, though the two-part regulatory citation makes it slightly run-on and harder to scan than it needs to be.

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 filter-only read lookup with full schema coverage and no output schema, the description supplies the two things the structured fields cannot: the jurisdictional limits (LPG 3 kg only for Jawa Timur, rice by wilayah) and the currency caveat. It is complete enough to call safely, with only return-format details absent, which the lack of an output schema would normally warrant mentioning.

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 commodity is self-explanatory, so the baseline is 3. The phrase 'by wilayah' loosely echoes the region filter but adds no matching syntax or granularity (e.g. exact region strings) 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 names the concrete resource (HET / price ceilings) and the exact commodities and jurisdictions it covers (beras medium & premium by wilayah, LPG 3 kg in Jawa Timur), which is enough to distinguish it from market-price siblings like get_food_prices_latest or get_fuel_prices. It is essentially a noun phrase without a verb, so the action is implied rather than stated, but the resource and scope are unmistakable.

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 'use this when...' statement and no alternative sibling is named for comparison, so the agent must infer usage from the commodity/region scope. The one genuine piece of routing guidance is a negative one: 'do not treat these rows as current', which tells the agent when the output should not be relied on, partially compensating for the missing positive 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 full disclosure burden. It does add useful provenance (data derives from that year's SKB 3 Menteri decree), which implies read-only, authoritative, decree-bounded data, but it says nothing about behavior for years whose decree is not yet published or any error/edge conditions.

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

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

One front-loaded sentence with no filler; the resource and the temporal scope come first, and the provenance clause is a compact trailing modifier. Nothing needs trimming.

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

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

For a simple single-parameter read tool with no output schema and no annotations, the description conveys resource, scope, and source adequately. The main residual gap is that the shape of returned records (date, name, whether joint leave is flagged separately) is never hinted at.

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 'year' parameter is already documented in the schema with bounds and an example. The phrase 'for one year' reinforces that year selects the decree, but 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?

The description names a specific resource (public holidays / libur nasional plus joint leave / cuti bersama) and a clear scope (one year). It implicitly distinguishes itself from check_holiday by returning the whole year rather than a single date, but it never names that sibling or any other, so differentiation must be inferred.

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 year-scoped framing suggests 'use this to enumerate a full year of holidays', with check_holiday as the obvious per-date alternative. There is no explicit when-to-use, when-not-to-use, or named 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 must carry the behavioral burden, and it does disclose the response shape (entry description, ancestor chain up to kategori, children) — genuinely useful for an agent planning the call. It says nothing, however, about behavior on an invalid or non-existent code, whether matches are case-sensitive, or whether the hierarchy is complete or truncated.

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 with zero filler, front-loading the exact-match lookup and then the return contents. Nothing 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?

For a single-parameter read lookup with no output schema and no annotations, the description covers the essentials: what the input code looks like and what comes back. The remaining gap is the absence of any error/empty-result behavior or routing against search_kbli.

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 parameter is documented, so the schema already carries the parameter load. The description restates the accepted code forms (a letter A to U, or 2-5 digits) but adds no semantics beyond the schema's pattern, so the baseline of 3 applies.

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

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

States a specific verb and resource: retrieving 'One KBLI 2020 entry by code', and enumerates the returned payload (description, ancestors up to kategori, children). It reads clearly as an exact single-record lookup, but never names or contrasts with the sibling search_kbli, which is the tool's closest look-alike.

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

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

There is no explicit when-to-use statement, no prerequisites, and no mention of the alternative search_kbli for when the code is unknown or only a keyword is available. Only the phrase 'by code' weakly implies exact-match usage, leaving the agent to infer the 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?

No annotations are provided, so the description carries the full burden, and it does more than most: it discloses the legal provenance (KP 667/2022) and an explicit staleness/supersession risk, which is exactly the kind of trust signal an agent needs before citing the numbers. It omits return-format details (units, currency, whether bounds are inclusive), but the read-only nature of a fare-lookup tool is self-evident.

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

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

Two sentences, with the substantive content front-loaded and the caveat trailing, which is the right ordering. The closing 'see the dataset note' is a dangling reference that consumes words without giving the agent an actionable path, a small deduction from an otherwise tight entry.

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 optional-parameter read tool with no output schema, the description compensates well by stating what the returned record contains (per-km bounds, first-4-km minimum fare), its regulatory source, and its possible obsolescence. The missing pieces are minor: no units/currency and no indication of whether historical versions of the tariff are available.

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

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

Schema description coverage is 100%: the single zone_code enum is fully documented in the schema ('zona_1, zona_2 or zona_3; omit for all'). The description's phrase 'per zone' confirms the dimension being filtered but adds no format or default information 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?

The description names the specific resource (ride-hailing motorbike fare limits per zone) and even enumerates the shape of the data: per-km lower and upper bound plus the minimum fare for the first 4 km. That is far more specific than a restatement of the name. It does not route against a sibling, but the sibling list contains no other fare/tariff tool, so differentiation was not required.

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 alternative tool is named. The only adjacent statement ('A 2026 decision may supersede it; see the dataset note') is a data-validity caveat, not usage routing, and the referenced 'dataset note' is not resolvable from the definition itself.

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, so the description carries the full behavioral burden. It does add genuine context beyond structured fields: the regulatory provenance (PP 45/2024) and the critical caveat that only the government fee is returned, not service charges. It still says nothing about auth needs, whether results are static/cached, currency, or per-person assumptions.

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 front-loaded sentence naming the resource first, then scope detail. Dense but every clause is informative; the only mild cost is the parenthetical enumeration making it a long single sentence.

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

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

With no annotations and no output schema, the description should do more of the return-value work. It discloses scope and source, but omits currency (IDR), the shape of the response, and whether fees are per-person or per-document – acceptable gaps, but real ones for a lookup with zero structured behavioral support.

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 goes further by spelling out what the 'passport' and 'visa' categories actually contain (biasa 5/10 years, electronic vs non-electronic, SPLP, same-day; single vs multiple trip), which meaningfully enriches the enum. The fee_code parameter is left to the schema.

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

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

Specific verb+resource: 'Imigrasi PNBP fees' for passport and visa kunjungan, with PP 45/2024 as the legal source. The enumerated coverage (biasa 5/10 years, electronic/non-electronic, SPLP, same-day, single/multiple-trip visa) makes it unmistakable against siblings like get_tax_rates, get_bpjs_rates or get_pph21_ter, which cover entirely different fee domains.

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 enumerating exactly which fee types are covered, and 'Government fee only' signals a scope boundary (excluding agent/service surcharges). However it never states when to reach for this tool versus any alternative, nor any prerequisite; usage must be inferred from the coverage 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 supplied, so the description carries the full behavioral burden. The plural 'Postal codes' usefully signals that a single kelurahan/desa may map to more than one code, and the operation is clearly a read. But it says nothing about permissions, empty results for an unmatched code, or whether the code must be resolved via get_wilayah first.

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

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

A single tight sentence with no filler and the key scoping information ('one kelurahan or desa') front-loaded. It is a noun fragment rather than a full statement of action, which is a minor stylistic weakness but costs no clarity.

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

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

For a one-parameter, annotation-free lookup with no output schema this is minimally adequate: the agent can call it. It is incomplete on the two things that actually matter here — the relationship to reverse_postal_code and get_wilayah, and the shape of the result set.

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

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

Schema coverage is 100%: the single wilayah_code parameter is documented in the schema as a 'Kemendagri wilayah code' with a regex pattern. The description only restates that the input is a wilayah code, adding no format, prefix, or hierarchy 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?

The description names the resource (postal codes) and the exact granularity (one kelurahan or desa) plus the input selector (wilayah code), so the agent knows precisely what comes back. It does not name or contrast with the obvious sibling reverse_postal_code, which is the only thing keeping it from a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the reverse_postal_code alternative for going the other direction (postal code -> area). Usage is only weakly implied by 'by its wilayah code'.

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 names the legal basis (PP 58/2023) but says nothing about what is returned (a rate percentage? a bracket label? a range?), how out-of-range or zero incomes are handled, or whether results are cached/static. For a lookup tool with zero annotation coverage this is a meaningful 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?

A single front-loaded sentence with no filler; it packs resource, inputs, and citation efficiently. Slightly dense but nothing 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 two simple required params and no nested objects the schema covers inputs well, but there is no output schema and no annotations, so the description should ideally describe the returned value's nature and units. It stops short of that, leaving the agent to guess what 'bracket' yields.

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 in the schema (category enum A/B/C, income_idr as monthly gross in rupiah). The description only restates the same semantics, adding no new meaning, so the baseline of 3 applies.

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

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

The description states a specific resource (PPh 21 effective average rate / TER bracket), the inputs it maps (monthly gross income + category), and the governing regulation (PP 58/2023), which an agent can distinguish from generic tax lookups. It does not, however, differentiate itself from plausible siblings like get_tax_rates or calculate_net_salary.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no routing to alternative tools such as calculate_net_salary (which likely consumes a TER) or get_tax_rates. The agent must infer the usage context entirely from the purpose statement.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful provenance trait ('computed by a documented hisab method; not an official Kemenag feed'), but says nothing about return shape, timezone handling, or whether results are cached/computed live.

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

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

A single front-loaded sentence with no filler; the scope comes first and the provenance caveat follows as a qualifying clause.

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 lookup with no output schema or annotations, the description covers purpose, scope, computation method, and the key trust caveat. It would be fully complete if it hinted at what the response contains (the five daily times), but nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%: both date format and the kecamatan/kelurahan fallback behavior for city_code are already documented in the schema. The description restates 'one kabupaten/kota and date' without adding format or constraint detail, 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 resource (prayer times) with explicit scope: one kabupaten/kota and one date. No sibling tool covers this domain, so the agent can route to it unambiguously from the name plus description.

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 scope phrase 'for one kabupaten/kota and date', and the Kemenag caveat hints at when to prefer an official source, but there is no explicit guidance on obtaining a valid city_code (e.g., via get_wilayah) or on when-not to use it.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the semantic nature of the returned value (annual, non-taxable, tied to a status code), which is useful context, but says nothing about read-only behavior, error handling for an out-of-pattern status, or currency/units of the 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?

A single front-loaded sentence with no filler; the resource is named first and the qualifying status examples follow immediately.

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

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

For a one-parameter lookup with no output schema and no annotations, the definition covers the essentials but omits the currency/units of the returned amount and any indication of response shape. Adequate for invocation, thin on context.

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

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

Schema coverage is 100% and the single parameter already carries a description and a regex pattern. The description goes beyond that by giving concrete example values (TK/0, K/1), which makes the otherwise cryptic pattern easier to apply 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?

States a specific resource and scope: annual non-taxable income (PTKP) keyed by taxpayer status, with concrete examples (TK/0, K/1). The verb is only implied by the name, and it does not distinguish itself from other tax-related siblings like get_pph21_ter or get_tax_rates, but the 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_tax_rates or get_pph21_ter, which an agent could plausibly confuse with this tax lookup. The example status codes hint at valid input but not at when this tool is the right 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 behavioral burden, yet it says nothing about the return shape (period granularity, frequency, coverage), whether results are paginated, or any rate limits. The only behavioral clue is the region-level restriction for kabupaten/kota, which is more parameter semantics than 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?

A single front-loaded sentence with no filler; the region-code detail is packed efficiently. It is a verbless fragment rather than a full sentence, but nothing is wasted and the key scoping information leads.

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 context. It adequately covers the region_code semantics but leaves the return structure of a time series (period fields, frequency) unspecified, which is a meaningful gap for a data-retrieval 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 adds genuine meaning beyond the schema: it explains the three region_code forms (2-digit province, 5-char kabupaten/kota like 32.73, 00 for Indonesia) and, critically, that the kabupaten/kota level applies only to hdi_regency — a constraint the permissive schema pattern does not encode.

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: the time series of one BPS indicator for one region, which distinguishes it in spirit from the sibling get_stat_values (latest values). However, it never names a sibling or explicitly contrasts with get_stat_values or list_stat_indicators, so an agent must infer the difference.

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

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

There is no explicit when-to-use guidance, no conditions for choosing this over get_stat_values, and no mention of prerequisites such as resolving an indicator id via list_stat_indicators. Usage is only implied by the resource-level detail in the sentence.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real behavioral detail the schema lacks: the omit-for-latest default and the rule that a bare year on a semester indicator resolves to the latest period in that year. It says nothing about read-only safety, error behavior for unknown indicators/periods, or result shape beyond the national figure.

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

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

Three sentences, front-loaded with what the call returns and why, followed by the period rules and the edge case. Dense but every clause 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?

With no output schema and no annotations, the description should do more to describe the returned payload (region set, units, how the national figure is represented) and failure modes. It covers input semantics well and hints at return contents, which is adequate but leaves the response contract underspecified for a two-param data 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 schema already documents both params and the baseline is 3. The description adds meaning beyond it: period accepts YYYY or YYYY-MM, omission means latest, the format source is list_stat_indicators, and year-only input resolves against semester indicators.

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 plus the exact scope: one indicator, one period, all regions, plus the national figure, with '(for a map)' clarifying the use case. It never names the sibling get_stat_series, so the distinction between a cross-region snapshot and a time series is left for the agent to infer from the scope wording.

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 operating context: use for a map, period is YYYY or YYYY-MM as listed by list_stat_indicators, omit it for the latest. It does not explicitly say when to prefer it over get_stat_series or point at list_stat_indicators as the source of valid indicator ids.

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 context: each rate is tied to its legal basis (PMK 131/2024, UU 10/2020, PMK 97/2024 Lampiran I), which tells the agent the data is authoritative and static. However, it says nothing about the shape of the response, whether the dataset is exhaustive or versioned, or how a single rate is addressed.

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 naming the resource first, then the three categories with their decrees. Dense with legal references but each clause earns its place by tying a rate family to its regulation. No wasted preamble.

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 lookup with no annotations and no output schema, the description usefully previews what each category returns (rate level plus legal decree), which partly substitutes for the missing output schema. The gaps — result shape, how rate_code identifiers are formed — are minor and largely covered by the schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, including the enum values and the 'omit for all' behavior. The description restates the category names and enriches them by explaining what each contains, but it says nothing about rate_code, so it adds partial value over the schema. Baseline 3 is appropriate.

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

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

The description states a specific resource — Indonesian tax and duty rates — and enumerates the three scopes it covers (PPN, Bea Meterai, cukai hasil tembakau), which implicitly draws a boundary against income-tax siblings like get_pph21_ter and get_ptkp. It never names a verb ('returns'/'lists'), and it does not explicitly tell the agent how it differs from those siblings, 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 sibling is named as an alternative. The only usage signal is the implicit 'look here for statutory tax rates', which the agent must infer from the content list rather than from any stated condition.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful traits the schema cannot express — default year resolution, that the no-code mode returns every kabupaten/kota in a single response, and that only entries with a 'confirmed figure' are included. It says nothing about error behavior for unknown codes or what a returned record contains.

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

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

Purpose is front-loaded in the first clause, and the two-sentence structure is dense with no filler. The second sentence is overloaded with three conditional clauses, which slightly hurts scanability.

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

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

With no annotations and no output schema, the description reasonably covers scoping, defaults, and result cardinality, but leaves the shape of a result (which fields, units, any name alongside the wage) entirely unstated. Adequate to make the call, incomplete for interpreting the response.

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

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

Schema description coverage is 100%, so the schema already documents year defaults, the code pattern, and the province_code dependency. The description largely restates those defaults rather than adding syntax, format, or edge-case meaning, so baseline 3 is appropriate.

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

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

The description states a specific resource — 'Regency or city minimum wage (UMK) for one year' — with the time scope explicit, which implicitly separates it from the history-flavored sibling get_umk_history and from the province-level get_ump. It does not, however, name any sibling directly, so an agent gets no explicit disambiguation.

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 branches on the controlling parameter: supply regency_code for a single kabupaten/kota, omit it to enumerate all, with province_code as an optional filter and 'used only when regency_code is omitted'. That is real when-to-use guidance for the two main modes, but there is no guidance on when to prefer this tool over get_ump or get_umk_history.

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 add real context beyond the schema: it explains that some rows come from an open-data portal with source_instrument prefixed 'Portal' and no decree number. It does not say what happens for an unknown regency_code, an uncovered region, or an empty history, nor does it confirm the return shape. Partial behavioral 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?

The opening clause is well front-loaded, but the bulk of the description is a single run-on sentence enumerating a long province/region/year list. That content is genuinely useful for knowing what data exists, but its unstructured prose form makes it hard to scan and crowds out tool-selection 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?

There is no output schema and no annotations, so the description must fully specify behavior and returns. It names source instrument and URL but never states whether the actual UMK amount and the year are among the returned fields, which is the single most important thing an agent needs to know. The coverage inventory is thorough, but the return contract is 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?

The single parameter is already fully documented in the schema (Kemendagri kabupaten/kota code, with a two-segment numeric pattern), giving a baseline of 3. The description adds no extra meaning about the parameter itself, such as what to do with codes outside the covered regions.

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 precise verb+resource: every loaded year of the UMK for one kabupaten/kota, returned oldest first, with source instrument and URL. It clearly delimits the tool to historical UMK series. It never names or contrasts with the obvious siblings get_umk or get_ump_history, so an agent must infer the relationship from the 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?

No explicit when-to-use or when-not-to-use statement, and no alternative tool is named. However, the exhaustive coverage list doubles as an implicit constraint: it tells the agent that regions/years outside the enumerated set have no data, which helps avoid futile calls. That is useful but inferred, 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?

No annotations are supplied, so the description carries the full burden. It usefully discloses data provenance and source coverage per period (governor decree vs BPS table, year ranges), which is genuine lineage information, but it omits return shape, units/currency, and any auth or rate-limit behavior for a read operation.

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

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

The first sentence is tight, front-loaded and does the real work. The second sentence is a dense footnote about per-year citation sources that most invocations do not need, which dilutes an otherwise efficient 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?

With no annotations and no output schema, the description should say more about what a result row contains (province code, name, value, currency) and how multi-province results are returned. As written it is adequate for a simple two-optional-param lookup but leaves the return contract entirely 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 coverage is 100%, so both parameters are already documented, but the description adds the consequence of omission ('all provinces or one province') beyond the schema's terse 'optional' for province_code. That extra semantics justifies a step above the 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?

Names a specific resource (Provincial minimum wage / UMP), the scope (one year, all provinces or one province) and the default (newest loaded). However, it never differentiates itself from the closely related siblings get_umk, get_umk_history and get_ump_history, so an agent must infer that 'provincial' means this is the province-level series rather than the city-level one.

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?

States the default behavior (omit year for the newest loaded) and the all-vs-one-province scope, which implies usage. But it gives no explicit guidance on when to pick this over get_ump_history or get_umk, and no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the year range (1997–2026), row contents (source type and URL), ordering (oldest first; by province then year when all provinces), and fallback behavior when province_code is omitted. It omits details on data completeness, error handling, or freshness, keeping it from a perfect score.

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, front-loaded with the core purpose and then the parameter-omission behavior. Every clause earns its place by conveying scope, ordering, row contents, date range, and fallback usage.

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

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

Given one optional parameter, no annotations, and no output schema, the description is largely complete: it explains what the tool returns, how rows are ordered, and what happens without a province_code. It could say more about data freshness, missing years, or error behavior, but it is sufficient for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already defines province_code as a Kemendagri code and says to omit for all provinces. The description adds meaning beyond the schema by specifying the ordering and use case (charts and bulk analysis) when the parameter is omitted, and implying single-province filtering when it is provided.

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: every loaded year of provincial minimum wage (UMP) for one province, oldest first. It distinguishes this historical series from siblings like get_ump (current) and get_umk_history (city-level UMK) through its explicit focus on UMP and years.

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 use cases: with province_code for a single province, and without province_code for all provinces ordered by province then year, explicitly noting the latter is for charts and bulk analysis. It does not name alternative tools or exclusions, but provides clear context for when to use each parameter state.

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 reveals the scope of the default listing ('the 38 provinces'), which is useful, but says nothing about read-only safety, output shape, hierarchy depth, or how large a child listing might be. For a tool with zero annotation coverage this is thin.

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

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

A single sentence, front-loaded with the resource and then the three selectable modes. No filler, no redundancy with the schema, nothing that could be cut.

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

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

The description covers the three retrieval paths but leaves gaps for a no-annotation, no-output-schema tool: it does not confirm what a bare call returns, describe the returned hierarchy/fields, or state that the operation is a safe read. Adequate minimum viable coverage, but not complete.

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

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

Schema description coverage is 100%: the schema already explains 'Return this one region', 'List the children of this code', and the enum plus the parent_code prerequisite for sub-provinsi levels. The description adds no format, pattern, or default 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 the resource precisely (administrative regions) and enumerates the three retrieval modes: all 38 provinces, children of a parent code, or a single region by code. This is distinguishable from every sibling in the list, none of which deal with regions. It lacks an explicit verb, but 'get_wilayah' plus the enumerated modes make the purpose 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 three modes map implicitly onto parameter combinations (level vs. parent_code vs. code), giving the agent a usable sketch of when each result shape applies. However, it never states prerequisites (e.g., that anything below provinsi requires parent_code, which lives only in the schema), defaults for a no-argument call, or exclusions. Usage is implied rather than prescribed.

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 provenance (BAZNAS RI, 2026, SK 14/2026 and SK 15/2026), which tells the agent the figures are officially sourced and year-stamped. It does not state that this is a static read-only lookup or describe the shape of the returned data, leaving gaps 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?

A single dense sentence with the source and year front-loaded, followed by the two covered data sets. No filler, no repetition of the tool name, and every clause carries information.

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

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

For a small optional-filter reference lookup with no output schema, the description covers the content, issuer, and legal basis of the figures adequately. It stops short of hinting at the response structure (e.g., per-code figures versus aggregate), which is the only notable omission.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents category (fitrah/penghasilan, omit for all) and zakat_code. The description reinforces what each category contains (fitrah vs nisab/rate for penghasilan), adding modest meaning about the semantics of the enum values but no syntax guidance for zakat_code.

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 resource (BAZNAS RI 2026 zakat figures) and enumerates the two data sets it returns: fitrah and the nisab/rate of zakat penghasilan dan jasa. It is clearly distinguishable in domain from sibling rate tools like get_tax_rates or get_bpjs_rates, though it never explicitly names or contrasts 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?

The description says what data exists but gives no when-to-use guidance, prerequisites, or alternatives among the many get_* reference tools in the sibling list. An agent must infer that this is the zakat lookup simply from the resource name.

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

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

With no annotations, the description carries the full burden, and it does disclose the shape of each returned record plus a useful language note that licence, caveat and fallback fields are Indonesian text. But it says nothing about access requirements, result size/ordering, caching, or refresh semantics, which are the remaining behavioral gaps for an unannotated catalogue 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?

A single dense sentence with zero filler, front-loaded on the core purpose with the field inventory following. The long comma-separated field list is slightly unwieldy to scan but every item is substantive, and the separate language caveat 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?

There is no output schema, so the field enumeration is doing real work in telling the agent what comes back, and 'every dataset' answers the completeness question. The main shortfall is the missing usage/routing context, which for a simple no-arg catalogue tool is a modest rather than critical 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?

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly does not invent parameters and instead spends its words on output content.

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 (datasets) and enumerates the exact fields each entry carries (status, row count, source instrument, effective date, publisher, URL, cadence, next expected update, catalogue page), which is far more specific than a bare 'list' tautology. However, it never states the verb ('list all datasets') explicitly and doesn't differentiate itself from siblings like list_stat_indicators or list_food_commodities, so an agent must infer the scope boundary.

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

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

There is no when-to-use guidance at all: nothing says this is a discovery/catalogue tool to consult before calling get_stat_series or get_kbli, nor any exclusion against sibling list_* tools. The agent is left to guess whether this is a prerequisite step or an end in itself.

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 data source (PIHPS Nasional / Bank Indonesia), per-province scope, price freshness ('newest day'), and series extent, which are real behavioral facts. However it never states that this is a side-effect-free read, says nothing about caching, rate limits, or error modes, and the final clause is grammatically truncated, so the safety profile is left entirely to inference.

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

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

It is a single sentence, so size is appropriate and the resource identity is front-loaded. But the sentence is densely packed and the trailing clause ('and for the groups the first and last month of the monthly series') is awkward and partly garbled, reducing readability without shortening meaningfully.

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

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

There is no output schema, so the description must describe the payload, and it does so field by field (codes, Indonesian/English names, Rp/kg unit, traditional/modern markets, series month range). For a zero-parameter reference tool this is nearly sufficient; the only real gap is the absent routing guidance relative to the price siblings.

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

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

The tool takes zero parameters, which per the rubric sets a baseline of 4. The description does not invent parameters, and the field-level detail it provides (code, names, unit, markets, month range) is about returned data rather than inputs, so there is nothing further to document here.

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

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

The description states concretely what the tool returns — the 10 staple food groups and 21 items reported by PIHPS Nasional per province, with code, bilingual names, unit, market coverage, and series range. That is a specific resource with real content detail, though no verb is used ('list' is only implied by the tool name) and it does not distinguish itself from price-fetching 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?

There is no when-to-use guidance and no mention of alternatives. An agent is not told that this should be called first to discover commodity codes before invoking get_food_price_series or get_food_prices_latest, nor under what circumstances the catalog is preferable to those 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?

No annotations are provided, so the description carries the full burden of disclosure. It does well: it describes the shape and content of each returned entry (id, unit, level of province vs kabupaten/kota, all periods, source table, caveats), which is the key behavioral fact for a zero-parameter listing tool. It does not mention whether results are cached, paginated, or require any auth, 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?

Three sentences, front-loaded with what the tool returns and back-loaded with the follow-up tools. The indicator-category list (TPT, poverty, IPM, wages, population, GRDP, life expectancy) is dense but each item aids discovery, so nothing is 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?

There is no output schema, so the description must act as the return-value documentation, and it does: it lists every field an agent will receive. Combined with the explicit next-step routing, an agent has everything needed 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The enumeration of indicator families is useful orientation but is not parameter 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 (list) and resource (stat indicators from BPS tables) and enumerates exactly what each entry contains: indicator ids, unit, level, periods, source table, caveats. It also names the sibling tools (get_stat_values, get_stat_series) it feeds into, so an agent can distinguish it from them 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?

'Start here, then call get_stat_values or get_stat_series' gives explicit sequencing and names both alternatives, with the condition (discovery first, then values/series) stated rather than 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?

With no annotations, the description carries the full behavioral burden, yet it only hints at return content (region types kelurahan/desa). It says nothing about cardinality (one postal code mapping to multiple regions), error behavior for unknown codes, or whether results are paginated.

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

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

It is a single short sentence with no waste, which is good, but its terseness is the problem: a fragment lacking a verb leaves the operation under-specified rather than efficiently explained.

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 annotations and no output schema, so the description must convey the return shape. It partially does (regions typed as kelurahan/desa) but omits cardinality and result structure, leaving an agent unable to predict the response for a given code.

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 the single postal_code parameter (including a 5-digit pattern), so the schema does the heavy lifting. The description adds no syntax or format detail beyond implying the input is a postal code.

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 is a bare noun phrase stating what the tool returns ('Regions (kelurahan or desa) that carry one postal code') rather than a verb+resource. Combined with the name reverse_postal_code, an agent can infer a reverse lookup, but the description itself never states the action or contrasts it with the sibling get_postal_code.

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 is given, and the obvious alternative get_postal_code (the forward lookup) is never named. The agent must infer the direction of the lookup from the tool 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return shape (code, level, parent, title) despite there being no output schema, but says nothing about read-only nature, pagination behavior, or result ordering beyond the schema's limit parameter.

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 search scope front-loaded and no filler; the routing hint is tucked at the end where it belongs. Slightly compressed phrasing ('by part of the title or a code prefix') costs a little readability but wastes 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?

With no annotations and no output schema, the description compensates by naming the returned fields and the authoritative regulation and the level vocabulary. An agent could call this correctly from the description alone; only edge behavior (ordering, empty results, rate limits) is unspecified.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description restates the q and level semantics and enumerates the five levels, adding emphasis but no syntax or format detail beyond the structured fields.

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

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

States a specific verb (Search) and resource (KBLI 2020 business-field classification, citing Peraturan BPS 2/2020), plus the two matching modes (title fragment or code prefix) and the five hierarchy levels. It is cleanly distinguishable from get_kbli, which retrieves a single code.

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 explains the search modes and routes single-code lookups elsewhere ('fetch one code for its description'), giving clear usage context. It stops short of naming the sibling tool get_kbli or stating exclusions, so the agent must infer the exact 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 full behavioral burden. It usefully discloses the internal dependency (wilayah table lookup) and a privacy trait ('it is never logged'), which is real value beyond the schema. However it omits error behavior for malformed NIKs and whether the call is purely 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?

Two tight sentences with the core purpose front-loaded and the privacy note placed second where it belongs. The 'Send the NIK in the JSON body' clause is mildly redundant with a required, 100%-documented parameter, but it is not wasteful enough to hurt.

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 annotations and no output schema, the definition is only partially complete: it never indicates what comes back (a validity verdict? the resolved region name?), which is exactly the gap an absent output schema leaves for the description to fill.

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 single parameter is already documented. The description repeats the 16-digit framing and adds that it goes in the JSON body, but adds no format detail — and the schema's maxLength of 32 is left unexplained against the stated 16-digit requirement.

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 ('Checks the structure of a 16-digit NIK') plus the secondary behavior (region-digit lookup in the wilayah table). That is enough to separate it from generic getters, but it never contrasts itself with the closest sibling get_wilayah, which also touches region data.

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

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

Usage is only implied by the stated purpose — an agent can infer 'use this to validate a NIK' but there is no explicit when-to-use, no note on when to prefer get_wilayah or reverse_postal_code, and no mention of what an invalid NIK produces.

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 a conditional behavior — the region is only named 'when the prefix table is loaded' — but says nothing about what happens for an invalid plate, whether the check raises or returns a boolean, or how prefix/region lookup failures surface.

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

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

A single sentence with no filler; the primary action (checking plate format) is front-loaded and the secondary behavior (region naming) follows it.

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 must cover return semantics. It partially does (region name, conditionally), but omits what the validity result looks like and how failure is reported — a real gap for a validation 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% and the schema already supplies the format example 'B 1234 XYZ' and a maxLength. The description adds no additional semantics about the plate string, 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?

The description gives a specific verb ('Checks the format') and a specific resource ('Indonesian vehicle plate'), plus the bonus behavior of naming the region from the prefix. It is clearly distinguishable from the nearest sibling validate_nik by resource, but it never names a sibling or scope boundary explicitly, so it stops short of a 5.

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

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

There is no statement of when to use this tool, when not to, or which alternative (e.g. validate_nik) covers a different case. Usage is only inferable from the domain wording, not guided.

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