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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses that the tool fetches structured meeting data itself, that it returns explicit validation errors for unknown IDs or missing agendas (never a plausible empty note), and that email delivery and cron are separate infrastructure. This adds significant behavioral context not present in structured fields.

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 detailed but every sentence delivers value: purpose, behavior, integration chain, validation, and return value. The structure is logical and front-loaded with the main outcome. It is longer than typical but appropriate for a complex hero-feature; the 'Positie in de keten' section is procedural and earns its place.

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 the complexity (4 parameters, integration with two other tools, no output schema), the description covers all necessary context: what it returns (markdown with legend + overview + detail blocks), how it behaves on errors, and exactly which inputs to derive from prior tools. The absence of an output schema is mitigated by the explicit return description.

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?

With 0% schema description coverage, the description compensates well: it explains that meeting_ids come from lijst_vergaderingen, instructs to fill covered_topics and followed_committees with confirmed values or empty lists, and implies horizon via '~2 weken' and 'horizon_dagen'. However, the exact semantics of 'vandaag' (default null) and 'horizon_dagen' (default 14) are not fully specified, only implied, so a small gap remains.

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 'Stelt de fractienotitie samen', clearly stating the verb (compose) and resource (fractienotitie). It further specifies the output as an agenda-overview with color-coded bullets and per-agenda detail blocks, making it distinct from sibling tools like genereer_raadsstuk or adviseer_raadsinstrument.

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?

Explicitly states 'Gebruik wanneer: de gebruiker een fractienotitie/voorbereiding voor de komende vergaderingen wil' and provides a full integration chain: first call mijn_fractie_context, then lijst_vergaderingen, then pass meeting_ids. It also clarifies that the host only supplies meeting_ids, not markdown, which serves as a boundary for when to invoke this tool.

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