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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower, yet the description still adds real behavioural context: results are capped at ten articles, each carries number, title, excerpt, the edition in force today, and a PlanElec reader link, and the full text is withheld. It does not explain ranking or what happens on zero results, which keeps it from a 5.

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 core purpose and the sibling routing are front-loaded, and each sentence carries information (language handling, return shape, alternative tool, query forms, disclaimer). The language clause is densely packed but not wasteful, so it reads efficiently despite its length.

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 four-parameter read-only search with full schema coverage and an output schema, an agent has everything needed: which corpus, which languages, result cap, what fields come back, where to go for full text, and the non-official status of results. Nothing required to invoke it correctly is missing.

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%, which sets a baseline of 3, and the description goes beyond it by clarifying the query parameter accepts either keywords or a dotted article number and by disclosing that locale 'en' resolves to the German source text. It adds no guidance on limit or version semantics beyond what the schema descriptions already state.

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 states a specific verb and resource (searches Book 1 of the Belgian AREI/RGIE electrical regulations) and constrains scope to a named corpus and language behaviour. It also distinguishes itself from the sibling get_regelwerk_article by noting the full article text is not returned, so an agent can pick the right tool without opening either schema.

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?

It explicitly names the alternative (get_regelwerk_article) and the condition that selects it (when the full article text is needed), and it explains the two query modes (keywords vs. article number such as 4.2.4.3). The added caveat that results are planning aids rather than an official inspection further frames appropriate use.

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