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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is fully consistent with them. The description adds genuine value beyond the annotations by disclosing execution characteristics — 'Pure kennisbank: geen retrieval, geen DB-call, <10ms' — plus the exact return structure in markdown. It also clarifies that returned legal deadlines are local-RvO specific and must be verified, which is important behavioral context. This exceeds what structured annotations convey.

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 description is long but well-organized into clear front-loaded sections: what it does, when to use, when not to use, and what it returns. Every major section adds value and the formatting makes it scannable. It loses a point for some redundancy — the doorlooptijd point is made in the intro, then repeated in the 'when to use' bullet about schriftelijke vragen — so not every sentence strictly earns its place, but overall this is efficient for the information load it carries.

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 and 0% parameter description coverage, the description carries a heavy burden and largely rises to it: it fully specifies the return structure (instrument, alternatives and goals, outcomes, legal basis, lead time, process, RvO template, disclaimer). The main gap is that two parameters ('urgentie' value options and 'op_agenda' semantics) are not explicitly described. But for advising a tool, the core use, outcome types, and verification warnings are all present — the only residual completeness of an agent's correct use.

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 carries the full burden for parameter meaning. It compensates well for the two core parameters: 'doel' is effectively enumerated via the goal examples (informatie, college ter verantwoording roepen, uitspraak/besluit, nieuw beleid) and 'urgentie' is given meaning through the discussion of lead times and fast vs. slow instruments. However, 'onderwerp' and 'op_agenda' receive virtually no semantic explanation, so the compensation is only partial.

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 opens with a specific verb+resource pair ('Adviseert welk raadsinstrument past bij wat het raadslid wil bereiken') that defines the tool's exact purpose: matching a council member's goal to the right legal instrument. It immediately distinguishes itself from the listed siblings (text generation, context gathering) and even names alternatives for excluded cases (zoek_raadshistorie / zoek_moties). The purpose is unmistakable even without opening the 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?

The description gives an explicit 'Gebruik deze tool wanneer' list (four concrete situations) and a 'Gebruik deze tool NIET wanneer' list that names alternative tools (zoek_raadshistorie, zoek_moties) and the conditions that select them. It even includes a specific trigger — when about to advise 'stel schriftelijke vragen', check here first — which is exactly the kind of routing guidance that helps an agent pick correctly.

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