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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavior: a hard 500-character cap on the returned passage, the response language default, and the fact that URL, version and date accompany the quote. What it does not disclose is what happens when the bronId or anchor is unknown or the passage exceeds the cap (truncation? error?), which is the main behavioral unknown for a lookup tool.

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 sentences, front-loaded with the resource, size cap and language, then the provenance instruction, then the informational-not-advice framing. Little waste, though the closing disclaimer is longer than it needs to be for the operational guidance it conveys.

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 an output schema present, the description needn't describe the return shape, and the annotations cover the safety profile, so the remaining burden is modest. It discharges that burden well by specifying the character cap, quoting language and provenance of identifiers. Only error conditions and the taal-vs-'in Dutch' interaction are left unaddressed.

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 100%, so each parameter is already documented, including the anchor example 'p.14' and the taal enum. The description's only added semantic is that bronId and anchor come from another tool's bronnen list, which closely restates the schema text for bronId. It also says the passage is 'in Dutch' while the schema exposes an en option, a small imprecision that could confuse an agent about whether taal actually changes the output.

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 pairs a specific verb with a specific resource: it returns a short quoted passage (capped at 500 characters) from an official source document, and enumerates the document types (modelovereenkomst, vergoedingenwijzer, premium overview, government publication). It also states what accompanies the quote (URL, version, date). It never names a sibling such as get_polis or get_wettelijke_parameters, so the boundary with those tools is left to inference.

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 gives a clear triggering condition: quote and cite exact wording, using a bronId and anchor taken from the bronnen list of another tool response. That establishes the upstream workflow step precisely. It stops short of an explicit when-not or a named alternative for retrieving whole documents rather than a passage.

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