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

With no annotations provided, the description carries the full burden of behavioral disclosure. It comprehensively reveals that the tool is paid ($0.02), handles country-specific weekends, applies statutory holidays, caps the range at 366 days, requires an api_key or explains payment via x402, and optionally returns an Ed25519 answer receipt. It also clarifies that the receipt is not a certified extract and not legal advice, and that verification is possible via verify_answer_receipt. This is exceptionally transparent.

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 dense but each sentence earns its place, front-loading the paid status and core purpose. It covers payment, range limits, receipt details, and caveats without fluff. While it could be broken into paragraphs for readability, it is not overly verbose and is well-structured for an agent to parse.

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 the tool's complexity (paid, receipt, subdivision, country-specific weekends), the description covers the essential behaviors, output (holidays hit and next working day), payment mechanism, and verification. It doesn't explicitly state the return format, but that's minor. It also handles edge cases like unpaid 402 and free refusals. The description is sufficiently complete for an agent to use 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the 366-day range limit for from/to, detailing the receipt parameter's behavior and verification path, and connecting the subdivision parameter to get_public_holidays. It also clarifies the country-specific weekend handling. This goes beyond what the schema provides.

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 clearly states the tool counts working days in a date range for a country, applying weekends (with special handling for Egypt's Fri-Sat) and statutory public holidays. It also specifies the output: holidays hit by name and the next working day after the range. This is a specific verb+resource that distinguishes it from siblings like get_public_holidays and settlement_date.

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 provides no explicit guidance on when to use this tool versus alternative siblings. It does not mention when not to use it, or how it compares to settlement_date or get_public_holidays. The only reference to an alternative is the note about the certified extract, which is not an MCP tool and is about the receipt, not the tool's usage context.

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