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

The annotations already declare a safe, read-only, closed-world lookup, and an output schema exists, so the description's job is to add operational context. It does: it discloses the required input and where to obtain it, plus the exact outputs computed. It does not describe how the return schedule is derived (e.g., anniversary-based cadence) or what happens for very recent or lapsed registrations.

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 short sentences, front-loaded with the outcome the caller gets, followed by the input requirement and the fallback. The fastcac.com reference is somewhat promotional but carries real fallback value, so it 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?

With one fully documented parameter, an output schema, and clear read-only annotations, the definition covers everything needed to invoke the tool correctly. The only residual gap is how the schedule is computed, which an agent does not strictly need in order to call it.

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?

There is a single parameter with 100% schema description coverage, and the schema already states 'YYYY-MM-DD, from the CAC certificate.' The description restates that the date is on the certificate without adding new format or validation 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 names a specific verb chain and resource: it computes which annual returns are due, which are overdue, CAC's estimated charge, and the next due date, for a CAC business name. It is clearly distinct from siblings like calculate_cac_fees and check_business_name_compliance because it is scoped to annual-return obligations derived from a registration 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 establishes the precondition for use (a registration date from the certificate) and offers a fallback path when that date is unavailable (the fastcac.com checker looks it up by BN number). It does not name any sibling tool as an alternative or state an explicit when-not, so it stops short of a 5.

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