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

With readOnlyHint, idempotentHint and destructiveHint already declared, the description still adds real behavioral detail: the result is capped at 50 and a `heeft_meer` flag signals truncation, plus the scope is limited to future appointments of the caller. That pagination/capping disclosure is exactly the kind of context annotations cannot express. Return shape of individual appointments is left unstated, keeping 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?

A single dense sentence front-loads the resource and scope, then the filtering option, then the cap and truncation flag, then the mutation exclusion. Nothing is redundant with the title or schema, and no wording could be dropped without losing information.

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?

Because there is no output schema, the description carries the burden of explaining the return envelope, and it does so by disclosing the 50-item cap and the `heeft_meer` indicator. Combined with the read-only annotations, an agent has enough to call and interpret this correctly. Per-appointment fields are not described, which is the only real gap.

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 both `limiet` and `bedrijf_id` are already documented, including the default and 50 maximum. The description reinforces the 50 cap and states that the company filter is optional, but adds no syntax or edge-case meaning beyond the schema. Baseline 3 is appropriate.

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 resource (je eigen komende afspraken) with a clear scope constraint (gepland en nog niet voorbij) and an ordering rule (vroegste eerst). An agent can immediately tell this is a read of the caller's own upcoming appointments. It stops short of explicitly naming how it differs from nearby siblings such as crm_reserveringen, so it is not a full 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 clear usage context: own appointments, upcoming only, optionally narrowed to one company, and it explicitly closes off the mutation path ("Plannen of wijzigen kan alleen in Ragently"). That is a genuine when-not pointer. It does not, however, offer a positive alternative for viewing past appointments or other people's appointments.

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