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

With no annotations, the description carries the full burden and does so well: it discloses the validation basis (CEN EN 16931 plus KoSIT XRechnung 3.0), the shape of the result (valid plus each error's rule ID, message, XPath, fix hint), and an explicit known gap ('Peppol-specific rules are not checked yet'). Those caveats are exactly the behavioral context an agent needs to trust or discount the output.

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?

Dense but front-loaded: the core purpose and rule scope come first, then return shape, then regional extensions and the Peppol caveat, with the REST redirection last. Slightly overloaded with regional detail, but every clause conveys selection-relevant 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 read-only validator with no annotations and no output schema, the description covers inputs, rulesets, return contents and known limitations. Minor gaps remain around input size limits, whether validation is purely local/stateless, and no explicit guidance for the other einvoice siblings, but nothing essential 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 coverage is 0% and neither parameter is described in the schema, so the description must compensate. It explains the xml parameter's accepted formats and spells out the allowed rules values (auto | en16931 | xrechnung), which the schema does not expose as an enum. Both parameters are effectively documented.

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 a specific verb and resource (validate an EU e-invoice XML) and enumerates the accepted syntaxes (UBL 2.1 Invoice/CreditNote, UN/CEFACT CII, XRechnung, Factur-X/ZUGFeRD), which clearly separates it from create_einvoice and send_einvoice_sandbox. The agent can identify the tool without opening the 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 which rulesets apply and when extended checks kick in (Slovak sellers get eFaktúra checks, Norwegian sellers get NO-LAW checks), and routes PDFs to the REST endpoint POST /einvoice/validate. It does not phrase usage relative to the sibling MCP tools (e.g. create_einvoice), but the context is otherwise unambiguous.

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