compliance_check

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

With no annotations, the description carries the full burden and does notable work: it declares the call is non-mutating (nothing stored, no PDF produced, no render consumed) and explains the two-tier mandatory-field plus Schematron execution at a pinned ruleset version. It also names output keys (`valid`, `fully_checked`, `rulesets`), which matters since there is no output schema. It stops short of error behavior, latency/cost characteristics, or what an incomplete run looks like.

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?

Three short paragraphs, each front-loaded and each doing distinct work: what it does and costs, what actually runs, and how to read the result. No sentence is redundant, and the most decision-relevant fact (no render consumed, nothing stored) leads.

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 complex invoice-shaped input with no annotations and no output schema, the description covers the behavioral essentials and substitutes for the missing output schema by explaining how to combine `valid` with `fully_checked`. The remaining hole is input completeness: nothing tells the agent which profile strings are acceptable or that e-invoice checking imposes extra requirements (VAT tax scheme, delivery date, buyer reference) that the schema documents only field by field.

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 only 33% and the description adds almost nothing for the three top-level parameters. `data`, `profile` and `document_type` are never discussed; notably `profile` is a free string with only one example, and the description says rulesets differ but does not say where valid profile values come from. The one indirect hint ('names a field of the request you can go and change') is too vague to guide input construction.

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 scope: check a document against an e-invoicing ruleset, explicitly without rendering. The 'without rendering it / costs no renders' framing separates it from the render and calculate siblings, but it never mentions the two closest siblings by name (document_validate and compliance_xml), so an agent must still guess which check path it wants.

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 clear operating context: run it on every invoice before sending rather than learning about the problem from a rejection. That is genuine when-to-use guidance. What is missing is any exclusion or alternative — nothing says when to prefer document_validate or compliance_xml instead.

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