anaf_declaration_status

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

With no annotations provided, the description carries the full behavioral burden. It enumerates possible states, explains nok includes validation errors with reference to recipisa, and mentions the recipisa PDF URL when available. It does not explicitly state there are no side effects, but a status lookup is implicitly read-only.

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 slightly redundant with the parenthetical restatement of the index and CUI, but every sentence adds useful information about states, return value, and public access. It is longer than necessary but not padded.

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 there is no output schema, the description adequately explains the return behavior by listing states and the reciprocal PDF URL condition. It also places the tool in the submission workflow, which is important among the many declaration-related sibling tools.

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 descriptions already cover both parameters (cui and index) at 100%. The tool description adds useful context by explaining index is the upload index returned by the portal, which ties the parameters to the preceding submission workflow.

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?

Clearly states the tool retrieves the processing status of a declaration filed on the ANAF portal, keyed by upload index and CUI/CNP. It distinguishes itself from related submission tools by referencing the prior step that produces the index.

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 gives a concrete condition for use: after agent_submit_declaration_pdf or any upload returning an index. It also notes the endpoint is public and requires no account, but it does not explicitly name alternatives or state when another declaration-status tool should be preferred.

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