Compare official EU document versions

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

The description adds real value beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false): it discloses determinism, whitespace/markup normalization behavior, and the explicit limitation that it does not characterize legal effect. No contradiction with annotations — returning computed differences is fully consistent with a read-only idempotent operation.

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 well-constructed sentence with the main action front-loaded and the legal caveat appended. Every phrase earns its place — determinism, normalization, and scope — with zero filler or redundancy.

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 5-parameter tool with zero schema coverage, the description is under-equipped: annotations cover the safety profile and the description covers determinism/normalization, but parameter semantics are left undocumented. The presence of an output schema lightens the return-value burden, yet the description still leaves an agent guessing about input meaning.

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 0%, so the description must compensate, but it only clarifies the output ('structural provision differences') and says nothing about what document, version_a, version_b, article, or language mean. The article and language parameters remain especially ambiguous (is article a filter? what language scope applies?), so the burden is unmet.

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 uses a specific verb ('Return') with a clear resource ('structural provision differences' between document versions) and adds a distinguishing qualifier about normalization and the legal-effect caveat. It clearly conveys what the tool does, but it does not explicitly name or differentiate from siblings such as list_document_versions or get_provision_at_date, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus alternatives like get_provision_at_date, list_document_versions, or get_document_timeline. The 'does not characterize legal effect' clause is a behavioral limitation rather than usage routing. An agent gets no help deciding between this and related version-facing tools.

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