validate_fa2_invoice

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

With no annotations provided, the description carries full burden. It discloses that XSD validation runs conditionally ('when the official schema is present') and that business-rule checks are performed, returning a DocumentValidationResult. This is transparent and accurate.

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 efficiently convey purpose and behavior. No redundant or empty phrases. Every sentence contributes meaning.

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 validation tool with an output schema, the description explains key behaviors (XSD and business-rule validation) and the return type. It misses only minor details like error handling or prerequisites (e.g., schema availability), but overall it is sufficiently complete.

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 only parameter (xml_content) lacks any schema description (0% coverage) and the description does not add details about its format, encoding, or constraints. It merely implies content type by context. Minimal value added.

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 clearly states 'Validate a KSeF FA(2) XML invoice' with specific actions (XSD validation and business-rule checks), distinguishing it from siblings that parse or generate invoices or validate different entities (NIP, REGON).

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?

Usage is implied by the verb 'Validate', but no explicit guidance is given on when to use versus siblings like parse_fa2_invoice or other validation tools. No exclusions or alternatives are mentioned.

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