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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description adds real context beyond them: results are cached and re-queried at ANAF when the stored answer is older than a day, which tells the agent how fresh the data is. It omits any mention of failure modes (invalid CUI, company not found) or latency.

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, front-loaded with the use case and then the enumerated checks; nothing is padding. The trailing caching clause is terse to the point of awkwardness ('Asked again at ANAF...') but still earns its place and survives compression.

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 well-documented parameter and rich annotations, the main gap would be return values, and the description effectively lists them by enumerating the flags checked, compensating for the absent output schema. Only error/edge-case behavior is left unaddressed.

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 coverage is 100%, so the CUI format (with or without RO prefix, example values) is already fully documented in the schema. The description adds only the framing that the target is a Romanian company, not new syntax or constraints. 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?

A specific verb ('check') plus a resource (Romanian company), and the description enumerates exactly what is verified: existence, VAT registration, TVA la încasare, fiscal inactivity, struck-off status, and RO e-Factura. This is far more informative than sibling names like lookup_company or find_company, though it never explicitly says how it differs from them.

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 pre-invoicing context is stated up front ('The check before issuing an invoice to a Romanian company'), which is a clear when-to-use signal. It offers no explicit exclusions or named alternatives among the sibling tools, so the agent must infer when find_company or lookup_company would be preferable.

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