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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. Beyond that, the description discloses genuinely new traits: answers must be explicitly user-confirmed, consent is required before transmitting choices to Successiekompas, and no case is stored. That is meaningful data-handling context that annotations do not 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 core instruction (advance one step with confirmed answers, reuse returned state) is front-loaded, and the remaining sentences each carry a distinct rule or constraint. Dense but with no filler; a small amount of sentence-parsing effort is required to separate rules from scope notes.

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?

There is no output schema, but the description compensates by describing the loop (ask missing question, reuse returned state, show deterministic result) and by defining scope limits and privacy behavior. For a nested-object, three-parameter step tool, this is close to complete; only explicit return-shape hints and cross-tool routing are 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 67%, and the schema already documents intent's split by flow and the answers object (including the {} start case). The description reinforces that answers must be user-confirmed but adds no syntax, format, or defaulting detail for flow/intent beyond the schema. This is the expected baseline when the schema carries most of the load.

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 concrete verb+resource: advancing exactly one step of a Belgian (inheritance) scan, driven by user-confirmed answers. It is clearly distinct from erfkompas_flows (which presumably enumerates scans) and from the tax/lookup siblings. It stops short of naming a sibling to differentiate against, so a 4 rather than a 5.

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 real operating conditions: ask each missing question, reuse the returned state between calls, never infer answers, and get consent before sending choices. It also excludes out-of-scope behavior (inheritance-tax calculations and AI follow-up require the secure website). No explicit alternative-tool routing is given, which keeps it from a 5.

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