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

With readOnlyHint=true already conveying the safety profile, the description adds meaningful behavioral detail: the comparison result includes added, removed, and changed paragraphs with wording, and defaults to every article unless an eid scopes it. This tells the agent what kind of output to expect without relying solely on the annotation.

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?

The main content is a compact, front-loaded sentence that states the action, scope, and result format. The final 'norm.' appears to be a stray token or typo and is the only real distraction. Overall, the description is efficient and readable.

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?

With no output schema, the phrase 'added, removed, changed paragraphs with wording' gives a minimal but sufficient expectation of the return. The description, together with the fully covered schema, covers the important choices: optional element scope, older/newer version parameters, and language default. It could say more about output structure or version resolution, but the tool is safely invocable from this definition alone.

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 100%, so the schema already documents all five parameters. The description reinforces that eid is optional and that default behavior is 'every article', but it adds little beyond what the schema property descriptions already state. A baseline 3 is appropriate here.

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 names a specific operation (compare), a specific resource (two Fassungen of an act), and a clear scope (an element or every article). It also states the expected outcome — added, removed, and changed paragraphs with wording — which makes it easy to distinguish from reading or listing tools. The trailing 'norm.' is cryptic, but it does not obscure the core purpose.

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 description gives an explicit trigger intent: use for «was hat sich geändert?», meaning 'what changed?'. This is practical guidance for an agent deciding when to invoke this tool. It stops short of naming alternatives or stating when not to use it, so it does not reach the full 5.

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