declaration_form_versions

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is 'Public, no account' (auth requirements), describes the exact returned fields and their meanings (changedRecently: forms changed in the last 30 days; localOutdated: this Storno installation's validators lag behind ANAF), and clarifies the data source (DUKIntegrator's manifest). This goes beyond a simple list and provides actionable context.

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 sentences with all necessary context. The first sentence is dense but front-loads the core information, and the second gives usage and access requirements. No filler, though the first sentence could be slightly more streamlined.

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 that there are no parameters and no output schema, the description effectively covers what the tool returns, the meaning of each field, when to use it, and access requirements. It could be slightly clearer about the overall response structure (e.g., an array of form entries), but the field explanations suffice for correct invocation.

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?

The input schema is empty with 0 parameters, so the baseline is 4. The description adds no parameter information because none exist; this is appropriate and complete.

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 identifies the tool as returning ANAF's current version of every declaration form, including specific fields like changedRecently and localOutdated. This distinguishes it from siblings such as declaration_forms (which likely lists forms) and declaration_form_spec (which likely provides schemas). The resource and scope are specific, and the purpose is immediately understandable.

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?

Provides a concrete usage condition: 'Check it before building or filing when a rejection mentions the form version.' This tells the agent exactly when this tool is appropriate. However, it does not explicitly name alternative tools or exclusion criteria, so it falls just short of a perfect score.

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