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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the returned payload: official text, English translation for German-only rules, plain-language meaning, severity, involved BT/BG fields, and a reference link. It does not say what happens for an unrecognized code, which is the main residual gap.

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 with no filler; every clause (code families, translation behavior, returned fields) carries information. It is dense with nested parentheses, so a slightly more scannable structure would help, but nothing is redundant.

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 lookup with no output schema, the description covers the input scope and the return contents thoroughly enough to call the tool correctly. Only the unknown-code behavior and any coverage limits across rule sets are left unstated.

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?

With one required parameter at 100% schema coverage, the schema already documents the argument and its format. The description still adds meaning the schema does not: the accepted namespace families (EN 16931, XRechnung, Peppol), which tells an agent which code forms are valid input rather than any arbitrary string.

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 (Explain) and a precise resource (e-invoice business rule code), then enumerates the exact code families covered (BR-*, BR-CO-*, BR-DE-*, PEPPOL-EN16931-*). This clearly separates it from siblings like validate_einvoice or check_leitweg_id, which act on data rather than explaining rule semantics.

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 purpose implies the usage context (looking up what a rule means), and listing the supported code prefixes helps an agent decide whether a given code is in scope. However, there is no explicit when-to-use statement, no exclusion, and no pointer to validate_einvoice as the sibling that produces these codes in the first place.

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