e-Factura Validator (Romania)

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

Annotations already establish that this is a read-only, idempotent, closed-world, non-destructive operation. The description adds useful behavioral context by saying it returns official English and Romanian text, a plain-English fix, and UBL field location, and that it is free, though it does not discuss unknown rule IDs or limits.

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 a single front-loaded sentence that leads with the usage trigger and then enumerates the useful return content. There is no filler or repetition.

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 one-parameter lookup tool with no output schema, the description sufficiently explains what the tool returns and why an agent would call it. Annotations cover safety traits and the schema fully documents the only parameter.

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% and the schema already explains that rule_id comes from findings[].rule or an ANAF error message. The description adds value by showing several concrete rule ID formats across ANAF, Romanian, and Peppol families, which helps an agent recognize valid input beyond the single schema example.

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 states a specific verb and resource: explaining a named e-invoice rule, including official text, a plain-English fix, and the UBL field location. It clearly distinguishes this lookup/explanation tool from sibling validation and fixing tools such as validate_invoice and fix_invoice.

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?

It gives a clear trigger condition: use when ANAF SPV, a Peppol access point, or a validation report names a rule and you need to understand or fix it. It does not explicitly state when not to use it or name a specific alternative, so it falls short of a full 5.

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

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

The description adds substantial behavior beyond the annotations: it lists changes as field/old/new, re-validates the result, charges $0.05 USDC via x402 only if something was fixed, and advises reviewing changes before sending. These details are not inferable from readOnlyHint/destructiveHint/idempotentHint/openWorldHint alone.

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 front-loaded with the usage condition and then efficiently covers what is fixed, what is returned, payment terms, and a review caution. Every sentence earns its place and there is no redundant restatement of the title or schema.

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 two-parameter tool with full schema coverage and no output schema, the description provides enough context to call it correctly: when to invoke it, what it fixes, that it returns a change list and corrected XML, that it re-validates, and that it is paid. Nothing critical is missing.

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%, and both parameters already have clear schema descriptions. The tool description does not add syntax or format guidance for the xml or profile parameters beyond what the schema provides, so the baseline of 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?

The description states a specific verb and resource ('fixes invoice XML') and lists exactly what it corrects: county/sector/country/currency/unit codes, date formats, VAT-id prefixes, decimals, totals, and VAT. It distinguishes itself from sibling validators by returning corrected XML and listing every change, rather than only reporting validation results.

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?

It gives a clear triggering condition: use when a validation report lists 'autofix' rules or when ANAF rejected an invoice for codes, dates, or totals. It implies the alternative of manual editing, but does not explicitly name sibling tools or state when not to use this tool.

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

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

Annotations only say read-only/idempotent/open-world; the description adds substantive behavior the annotations do not: weekend and holiday dates return the last publication, the date defaults to today, omitting the currency returns all rates, and the source is the official BNR feed at no cost. These are exactly the operational facts an agent needs before calling.

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 use case followed by the rate semantics, defaults, and edge cases; no filler sentences. It is a single dense run-on with stacked parentheticals, which costs a little readability but not accuracy.

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 no output schema, the description still conveys the return shape implicitly ('RON per 1 unit', omitting currency yields all rates) and covers defaults and publication-day fallback. Only the exact response envelope (list vs. object, rate field naming) is left unstated, a minor gap for a two-parameter lookup.

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 already documents both params at 100% coverage (date as YYYY-MM-DD, currency as ISO 4217), so the baseline is 3. The description goes beyond it by stating the date default (today), the fallback rule for non-publication days, and the special semantics of omitting currency — meaningful additions rather than repetition.

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 pair (official BNR exchange rate) and pins down the direction, 'RON per 1 unit of the currency,' which is the ambiguity that matters most here. It is clearly distinguishable from every sibling (validate_invoice, ro_business_day, etc.), none of which deal with FX.

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?

Gives a concrete triggering scenario — a foreign-currency invoice needing VAT in RON for e-Factura — plus a general catch-all ('any RON conversion'). There is no explicit when-not or named alternative, but no sibling competes for this job, so the guidance is effectively complete.

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

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

Goes well beyond the annotations: discloses external ANAF lookups that fill company names, addresses, county codes and VAT status, that totals and VAT are computed, and that the XML is validated before return. Also surfaces the commercial behavior — $0.05 USDC via x402, charged only on a valid invoice — which no annotation conveys.

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 when-to-use condition and the output, with the example last where it belongs. It is one dense block, however, mixing input shape, enrichment behavior, validation, and pricing; splitting the payment note out would improve scanability.

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?

Covers the noteworthy complexity — nested invoice object with only an example in the schema, plus external ANAF lookups and pre-return validation. With no output schema, it should still say what comes back (raw XML string, file, or base64) and whether the ANAF enrichment can fail or return partial data.

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 schema's coverage figure is nominal: the only description is 'see the tool description for the shape' with additionalProperties=true, so the description carries the real burden. It enumerates required fields (number, issue/due dates, seller/buyer CUI, line name, quantity, unit, price ex-VAT, VAT rate), flags IBAN as optional, gives concrete VAT rates, and supplies a full example payload.

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 and artifact: builds UBL 2.1 CIUS-RO e-Factura XML accepted by ANAF. The opening condition ('you have invoice data but no XML') implicitly separates it from validate_invoice/fix_invoice, which take existing XML. An agent can tell exactly what this produces.

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 when you have invoice data but no XML' gives a clear trigger condition, and the currency note tells you what to add for non-RON cases. No sibling is named explicitly (e.g. 'to check or repair an existing file, use validate_invoice / fix_invoice'), so the alternative routing is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds materially more: it is free, rate-limited to 100 lookups per day per IP, and it spells out conditional return semantics (VAT id only for VAT payers, county as ISO code, Bucharest as SECTOR1..6, plus inactive/VAT-on-collection/e-Factura flags). That is exactly the context an agent needs before committing to a call.

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?

It is front-loaded with 'Use when...' and every clause carries information, though the returned-field enumeration is dense and could be split for readability. No filler sentences.

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 no output schema, the description carries the burden of explaining returns and does so field by field, including conditional quirks like RO-prefix and sector encoding. An agent can call it and interpret the result without further documentation.

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 single parameter has 100% schema coverage and the schema already says 'CUI, with or without RO'. The description only reinforces that it is a Romanian CUI, adding no format or edge-case detail beyond the schema, so the baseline of 3 applies.

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 verb and resource (lookup a Romanian company by CUI) and states the exact data returned (ANAF legal name, VAT id, trade register, address, flags). It is immediately distinguishable from the invoice-generation and validation siblings in the same namespace.

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?

It gives two concrete trigger scenarios: building/checking an invoice when only the CUI is known, and vetting a partner before invoicing. There is no explicit exclusion or named alternative, but the context for use is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds a useful non-schema fact ('Free') and enumerates the three questions it can answer, but it never explains how the two parameters select among those three modes (e.g. what add_days=0 yields vs. the is-a-working-day check), which is the key behavioral ambiguity.

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 front-loaded sentence opens with the use case and packs the three operations into a compact clause, with zero filler. Slightly dense parenthetical phrasing keeps it from being maximally scannable.

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 no output schema, the description does list the three answerable questions, which implicitly covers the return shape (a judgment, a date, a computed date). It is nearly complete for a two-param read-only tool, though it could state explicitly what is returned for each mode.

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% and both parameters carry descriptions plus examples, so the baseline is 3. The description's phrase 'the date N working days later' loosely maps to add_days, but it does not clarify the mode selection (default add_days=0) or date-format expectations beyond what the schema already says.

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: computing due dates in Romanian working days, with three concrete capabilities (is-it-a-working-day, next working day, date N days later) and a real example (e-Factura upload deadline). It is distinguishable from siblings like ro_holidays or ro_tax_deadlines by emphasizing working-day arithmetic, though it never names those neighbors.

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 e-Factura example implies the use case well, and 'Free' signals no cost barrier. However there is no explicit when-to-use/when-not guidance and no reference to the closely related siblings (ro_holidays, ro_tax_deadlines), so the agent must infer which tool fits which question.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing cost ('Free') and the content scope (legal holidays, Orthodox Easter, Rusalii), which annotations do not convey.

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?

A single tight sentence that front-loads the usage condition and then the resource. Every clause (Orthodox Easter, Rusalii, Free) carries information an agent would otherwise have to discover.

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 one-parameter read-only lookup with full annotation coverage, the description supplies enough to call it correctly. The only gap is that with no output schema the agent doesn't learn the return shape (e.g., list of dated holiday names), which would have been a useful addition.

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% and the single optional 'year' parameter is documented with a default and example, so the schema carries the semantics. The description only implies year scoping ('for a year') without adding format or default behavior, which is the expected baseline.

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 resource (Romanian public/legal holidays for a year) with the notable inclusions (Orthodox Easter, Rusalii), which an agent can immediately distinguish from siblings like ro_business_day and ro_tax_deadlines. The verb is implicit ('get/list') but the scope is unambiguous.

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 when planning payment or filing dates in Romania' gives a clear triggering context rather than leaving usage implied. It stops short of naming alternatives (e.g., ro_business_day for single-date checks) or stating when not to use it, so it falls below a 5.

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

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.

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

Annotations already declare readOnly/idempotent/non-destructive/no open world, so the safety profile is covered. The description adds real value beyond that: the scope is Romanian banks (plus State Treasury), it discloses which checks are performed, and it signals a free tier. It stops short of saying what an invalid IBAN returns (error vs. negative result) and whether the account itself is verified.

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 sentence, front-loaded with the decision the agent is making, zero filler. 'Free' is the only compressed extra and it is still useful.

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 required param, no output schema and full annotation coverage, the description covers purpose, scope, checks performed and cost. The remaining gap — what the caller gets back on a bad IBAN — is modest but real given there is no output schema to fall back on.

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% and the single 'iban' parameter is documented with an example plus 'spaces allowed'. The description adds no format nuance (e.g., country prefix requirement, whitespace normalization) beyond what the schema already says, so baseline 3 applies.

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?

Specific verb+resource: it validates an IBAN, checks length and check digits, and returns the Romanian bank (or State Treasury) name. That is concrete and distinguishable from every sibling (invoice/Saft validators, fx_rate, lookup_company) without opening a schema.

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?

States the trigger context explicitly — 'before putting an IBAN on an invoice or paying to one' — which is a clear when-to-use. It does not name any exclusion or alternative, though no sibling obviously overlaps, so the gap is minor.

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

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

Goes well beyond readOnly/destructive annotations: discloses the paid model ($0.01 USDC via x402, eip155:8453, payment in request _meta), states that an unpaid call returns payment requirements instead of a report, and clarifies only real invoices are charged. It also describes report contents (rule violations, plain-English fixes, UBL paths, correct amount values) and the 'autofix' signal for repair.

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-loads the trigger condition and free-tier alternative, and every sentence carries practical information. It is somewhat dense and run-on in the middle (report contents and payment terms packed together), but nothing is truly wasted.

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 no output schema, the description does the necessary work of explaining the report's contents and the payment-failure return, which is enough to call the tool correctly. The exact report structure (beyond the 'autofix' key) is only sketched, leaving a minor gap for a validation tool whose whole output is the report.

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 xml and profile parameters are already fully documented, including the 'auto' CustomizationID behavior. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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?

Names the specific action (validate a UBL e-Factura/Peppol invoice) and the downstream use case (before upload to ANAF SPV or Peppol send). It explicitly distinguishes itself from the sibling validate_invoice_free by quota and by being the paid tier, so an agent can choose without opening either schema.

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?

Gives explicit when-to-use: after the free quota of validate_invoice_free is exhausted, before uploading to ANAF SPV or sending via Peppol. It also routes follow-up work to fix_invoice when the report contains 'autofix', naming the alternative and the condition that selects it.

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

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

Annotations only cover the read-only/non-destructive profile; the description adds the operational facts an agent actually needs: free, no wallet/account/key, a hard 3-calls-per-day-per-client-IP limit, and the exact shape of the return payload (errors with fixes in words, UBL field path, and corrected amount values). The quota and the escalation path to the paid sibling are behavior no annotation conveys.

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-loads the trigger and the resource, then packs quota, output shape, retry loop, and the escape hatch into three dense sentences with no filler. Length is justified by the amount of decision-relevant information delivered.

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 no output schema, the description carries the return-value burden and does so precisely: every error, a plain-language fix, the UBL path, and the correct value for amounts. Combined with the quota and sibling handoff, an agent has everything needed to call it, interpret results, and decide what to do next.

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% and both parameters are already documented in the schema, including the enum values and the 'auto' default. The description adds no syntax or format guidance for the xml/profile arguments beyond naming the accepted standards, so the baseline 3 applies.

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 (validates) and resource (UBL 2.1 Invoice/CreditNote) plus the exact rule sets (CIUS-RO 1.0.9, Peppol BIS 3.0, EN 16931), and names the sibling it defers to (validate_invoice) when quota runs out. An agent can distinguish it from validate_invoice, validate_saft_free, and fix_invoice without opening any schema.

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?

Gives explicit trigger conditions ('before uploading to ANAF SPV', 'after generating invoice XML', 'when ANAF rejected an invoice') and an explicit alternative with its condition ('When the quota is used up, switch to validate_invoice'). It also prescribes the follow-up loop: fix the XML from the report and call again.

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

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

Goes well beyond the annotations by disclosing the payment model ($0.50 USDC via x402 on eip155:8453, charged only if a D406 was actually checked, payment requirements returned otherwise) and the 25 MB inline size ceiling. It also describes the output contract: every finding carries a fix in Romanian and English plus the correct value where computable.

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-loads the trigger ('Use before filing...') and the core action before the payment caveat. The long parenthetical list of consistency checks is informative for tool selection but is the densest part and could be trimmed.

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 no output schema, the description still conveys the shape of results (findings with bilingual fixes and correct values) and the unpaid-path response. It leaves the concrete response format (JSON structure, per-finding severity fields) and the failure mode for invalid XML unstated, a minor gap for a single-parameter validation tool.

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?

Only one parameter (xml) and the schema already documents it at 100% coverage, including the 25 MB limit and the larger HTTP POST route. The description adds no syntax, encoding, or format guidance for the XML payload beyond what the schema provides, so baseline 3 applies.

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 (runs ANAF's official validator plus offline consistency checks) and a specific resource (Romanian SAF-T D406 XML). 'For the full report' hints that it is the paid/full counterpart of validate_saft_free, but the sibling is never named, so differentiation is left implicit.

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?

Gives a concrete trigger ('Use before filing a Romanian SAF-T (D406) with ANAF') and states what happens when payment is absent ('it returns the payment requirements'). It never explicitly says when to prefer the free sibling or when this tool is overkill, so no exclusion guidance.

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

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

Annotations already cover safety (readOnlyHint true, destructive false), so the description correctly spends its words on the non-obvious traits: a hard quota of one file per day per client IP and a report truncated to the first 10 findings with the total count still returned. Those are exactly the behaviors that change how an agent plans a call, and they are stated plainly.

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 front-loads the use case before the quota and output limits, and every clause carries information. Slightly run-on with its colons and parenthetical, but nothing is wasted.

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 single-parameter, read-only, quota-limited checker this covers the essentials: eligibility, frequency limit, and what the report contains. Output schema is absent, and the description adequately signals the return shape (findings plus total count) without needing to enumerate it.

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 single parameter is fully documented in the schema (content, 25 MB ceiling, and the HTTP POST endpoint for files up to 100 MB). The description adds no meaning beyond that, so the baseline 3 for high schema coverage applies.

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 resource (Romanian SAF-T / D406 XML) and a specific action (the same check as validate_saft), and explicitly positions itself relative to its sibling as the free tier. An agent can distinguish it from validate_saft without opening either schema.

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?

Gives explicit trigger conditions: 'Use before filing ... or when ANAF's DUKIntegrator reported errors'. The 1-file-per-day-per-IP quota and the reference to validate_saft imply when to fall back to the paid variant, but that hand-off (larger volume, more than 10 findings) is left to inference rather than stated.

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