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

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description carries real weight by disclosing the paywall: $0.002 USDC on Base per call via x402, the PaymentRequired failure mode for unpaid calls, and the exact retry mechanism (_meta["x402/payment"]). That is exactly the kind of auth/cost context an agent needs and cannot get from the schema.

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

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

Two dense sentences, front-loaded with the resource and scope before the payment mechanics. Nothing is padded and no sentence is wasted.

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

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

No output schema exists, so the description would ideally hint at the return shape (holiday names/dates). It also leaves the zero-required-parameter behavior unexplained — whether omitting year returns all years or a default year is unclear. Adequate but with clear gaps for a tool whose result format is undocumented.

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%, though the schema entries are thin ('e.g. 2026', 'e.g. auckland'). The description's example args reinforce the expected format (lowercase region slug) but add no meaning beyond what the schema already conveys, 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 (NZ public holidays) with an explicit scope (2022-2030), naming the distinguishing coverage (Matariki, Mondayisation, optional regional anniversary day). This clearly separates it from siblings like nz_working_days and nz_working_days_add, which compute workday counts rather than list holidays.

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 year/region example args, and the payment retry instruction is genuinely actionable operational guidance. However, it never states when to pick this over nz_working_days or nz_working_days_add, and there are no exclusions or prerequisites beyond payment.

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