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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely useful non-schema context: the source is BULI2, a supplier with a commercial relationship (FiLot's sister company), it has not been reviewed by a tax consultant, and the output is general information rather than tax advice. Those provenance and reliability caveats materially change how an agent should present the answer.

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 delivers the topic inventory, then appends source and disclaimer. It is front-loaded with the subject matter and every clause carries information. Slightly list-heavy, but no filler sentences.

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

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

For a read-only, closed-world knowledge tool with no output schema and no query parameter, the description covers the domain, the topics returned, and the trust caveats. The one residual ambiguity is whether the tool returns a fixed fact sheet or answers targeted questions, which an agent might want clarified given the absence of a question parameter.

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

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

Only one parameter (lang) exists and schema description coverage is 100%, with the enum values id/en already documented in the schema. The description adds nothing about language selection, so this sits at the baseline where the schema does all the work.

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

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

The description names a specific resource (Indonesian tax facts for physical gold bars) and enumerates the exact topics covered: PPN, PPh 22, individual buyers, selling back, the Rp 10 million limit, stamp duty, Antam buyback deduction. This clearly separates it from siblings like gold_buyback_prices and verify_gold_bar_record. It stops short of an explicit verb (e.g. 'returns' or 'answers questions about'), so it is clear rather than crisp.

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 topic list — an agent asking about Indonesian gold taxation would pick this tool, and the sibling domains (prices, sources, verification) are plainly disjoint. However, there is no explicit when-to-use statement, no guidance on whether it answers a specific question or dumps the full fact set, and no stated exclusions beyond 'not tax advice'.

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