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.