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

Annotations declare readOnlyHint=false and idempotent=true, and the description usefully adds that a side effect is produced (viewer_url in the web editor, pdf_url of the drawn document), which explains the non-read-only hint. It also discloses an important limitation — 'automatic checks of the document data, not a conformity certificate' — though it says nothing about permissions, cost, or whether the viewer document is persisted.

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 verb and resource are front-loaded, and the synonym list (single-line diagram, panel, schéma unifilaire, tableau électrique) aids retrieval rather than padding. The return-value enumeration is somewhat long and partly redundant with the output schema, keeping it just below the top score.

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?

Given an output schema exists, the description did not need to enumerate the finding fields, but it goes beyond by characterizing the findings' severity levels and the 'scope' caveat that results are not a conformity certificate. The only gap is the absence of any guidance on choosing between this and the sibling `validate`.

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 both parameters are already documented in the schema, including the enum-like profile names and the 'core' always-applies note. The description largely repeats that and adds only marginal value (naming 'enedis' as the French grid connection profile, mentioning 'PLC' without giving its identifier), so the baseline 3 applies.

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 gives a specific verb+resource ('check an electrical installation') and enumerates what is validated (breaker ratings vs cable sections, RCDs, circuits per protection, selectivity). It also implicitly distinguishes itself from the sibling `validate` by saying it 'validates the document, then applies the rule profiles', but it never names that sibling explicitly, so the boundary is inferred rather than stated.

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 two-step pipeline (validate then apply profiles) and the default-profile rule is spelled out, but there is no explicit 'use this instead of X' guidance against siblings like `validate`, `render`, or `normalize`. An agent must infer when a full rule-based check is warranted versus a plain validation pass.

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