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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds meaningful behavior beyond that: deadlines roll to the next working day on weekends/holidays, output is general rather than regime-specific ('confirm special regimes with ANAF'), and the cost hint ('Free'). Return shape is unspecified but not required.

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?

One dense sentence that front-loads the use case, then the deadline set, then the rollover rule, then the caveat. No filler; every clause adds information.

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?

For a zero-required-param, read-only lookup with rich annotations and no output schema, the description covers purpose, scope, behavioral rule, and caveat. Minor gap: it doesn't hint at what the response contains (e.g., per-form due dates), which would help an agent plan output use.

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% — the single 'period' parameter already carries format (YYYY-MM), example (2026-10), and default (last month). The description's 'for a reporting month' echoes but does not extend that. Baseline 3 is correct when the schema fully documents the parameter.

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?

States a specific verb+resource ('know when Romanian returns are due') and enumerates the exact form codes covered (D112, D300, D100, D390, D394, D406). This clearly separates it from siblings like ro_business_day or ro_holidays, which handle date primitives rather than filing obligations.

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?

'Use to know when Romanian returns are due' gives a clear trigger context, and the scope note about special regimes tells the agent when the answer may not apply. It does not explicitly route to ro_business_day for arbitrary working-day questions, so no exclusion clause is present.

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