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

Annotations already cover read-only, idempotent, closed-world safety, so the description correctly spends its space elsewhere: it discloses the two underlying data sources, the statutory deadline formula (year end + 6 months + 15 days), and the null-when-never-filed behavior. That is real behavioral context an agent could not get from annotations or 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?

Front-loaded with the resource and scope, and every clause earns its place (sources, returned fields, deadline formula, edge-case fields, null behavior). It is a single dense run-on sentence rather than structured bullets, which costs a point on readability but not on information density.

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?

There is no output schema, so the description must enumerate return values and it does so thoroughly, including the null case and the two aggregate fields. Coverage is strong for a data-lookup tool; only the resolution behavior across the three optional identifiers is left unexplained.

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 three parameters are already documented. The description adds only one semantic detail, that results are 'keyed by KRS', and says nothing about the nip/name fallback ranking or what happens if multiple identifiers are supplied. Baseline 3 applies when the schema carries the parameter burden.

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 (financial statement filing timeliness) and enumerates exactly what each record contains: period end, filing date, statutory deadline, days late, and auditor's report presence. It also declares derived scope (overdue_year, late_last_5y) which separates it conceptually from get_financials, though it never names a sibling explicitly.

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 only implied: an agent can infer this is the tool for filing-deadline questions and that get_financials covers figures instead. There is no explicit when-to-use, when-not, or guidance on picking among the krs/nip/name inputs beyond the schema's short note. It meets the minimum viable bar without routing help.

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