resort

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

Annotations already cover readOnly/idempotent/openWorld safety, so the bar is lower, but the description adds genuinely useful context: it produces a link rather than completing a booking, and it routes around OTA commission. This clarifies that no reservation is created, which is exactly the kind of side-effect disclosure that matters.

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?

Two sentences, zero filler, and the core action is front-loaded ahead of the optional-parameter note. Every clause earns its place by adding either scope or usage context.

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?

An output schema exists, so return-value detail is unnecessary, and the annotations plus 100% schema coverage handle safety and parameters. The only thin spot is the absence of explicit routing guidance versus the availability/detail siblings, which keeps it from a 5.

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% and each parameter already documents its flow restriction and format, so the schema carries the load. The description only reiterates that dates/type/persons are optional, adding no syntax or constraint detail beyond the schema — the baseline 3 applies.

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 names a specific verb (genereren) and resource (directe boekingslink naar de booking engine op la-truite.com), so the agent knows exactly what comes back: a URL. It does not explicitly name the sibling tools, but the sibling set (availability/details lookups) is functionally distinct enough that confusion is unlikely.

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 implies the usage context — prefilled values are optional and the guest finalizes the booking themselves — which tells the agent this is a hand-off tool, not a booking tool. However, it never states when to prefer this over getAvailability or getAccommodationDetails, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, and an output schema exists, so the safety and return-shape burden is largely carried elsewhere. The description adds useful substance by naming the returned fields (description, features, photo URLs, price-from), but says nothing about missing-slug behavior or language fallback.

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, front-loaded sentence that packs the verb, the target resource and the returned content with zero filler. Nothing in it is redundant.

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?

For a two-parameter read tool with full schema coverage, an output schema and safety annotations, the description covers what the tool does and what it returns. It is essentially complete, with only minor omissions around slug acquisition and language fallback behavior.

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% and both parameters (slug, lang enum) are documented there, so the baseline is 3. The description touches the slug indirectly via 'één accommodatietype' but adds no semantics about slug format or the lang default beyond the schema.

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 gives a specific verb (ophalen) tied to a specific resource (één accommodatietype) and enumerates the payload: volledige beschrijving, kenmerken, foto-URLs en prijs-vanaf. This clearly separates it from the sibling availability and booking-link tools, though it never explicitly contrasts itself with them.

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?

Usage is only implied: an agent can infer you call this to fetch detail for a single accommodation type, while siblings handle availability and booking links. There is no explicit when-to-use statement, no stated prerequisite (e.g. that a valid slug must be obtained first), and no named alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral payload detail: unavailable types carry reason_code + suggestion_code, and results include price, waarborg and booking_url. It does not, however, note anything about the deposit semantics or rate limits.

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 front-loaded sentence with the scope constraint first and the return highlights second. Every clause carries information; nothing is padding.

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 enumerate return fields, yet it still flags the reason_code/suggestion_code convention for unavailable types, which is the kind of non-obvious detail an agent benefits from knowing before parsing results. Only the absence of explicit alternative-routing leaves a minor 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 aankomst, vertrek, personen and lang are all documented in the schema. The description adds no parameter-level meaning (no note on the personen max of 6 or the lang default), so the baseline 3 applies.

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?

States a specific verb (controleer) and resource (accommodaties beschikbaarheid) for a period, and explicitly scopes out Camp & Dinner, which cleanly distinguishes it from getCamperAvailability and getRestaurantAvailability. An agent can route to it without opening any 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 parenthetical exclusion (exclusief Camp & Dinner) implicitly routes the agent to the camper/restaurant siblings, and 'voor een periode' signals the date-range context. However, it never explicitly states when to prefer this over getAccommodationDetails or buildBookingLink, leaving some routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so the safety profile is covered. The description adds the meaningful product constraint that the weekend dinner is mandatory, but says nothing about auth, limits, or how the availability result behaves. Adequate but not rich.

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 front-loaded sentence with the verb first and zero filler. The parenthetical is dense but earns its place by defining the product. Efficient overall.

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 and full parameter coverage, the description need not explain return values, and the annotations cover the safety profile. For a read-only date-range availability check it is sufficiently complete; only the sibling routing is 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 description coverage is 100%, including patterns and the language enum, so the schema already carries full parameter meaning. The description adds no format or default detail beyond it, making 3 the correct baseline.

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?

Specific verb ('Controleer') plus a well-defined resource: Camp & Dinner, explained as 'camperplaats + verplicht weekenddiner', and the returned items (vrije plaatsen, prijs, dineravonden, ontbijtdagen) are named. This implicitly separates it from getAccommodationDetails and getRestaurantAvailability, but no sibling is named explicitly, so it falls short of 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?

The description states only that it checks a period; there is no guidance on when to choose this over getAvailability, getRestaurantAvailability, or getAccommodationDetails, nor any prerequisite or exclusion. An agent must infer the selection rule from the name alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, not open-world), and the description adds real context beyond them: the restaurant only operates Fri/Sat/Sun, and the response conveys both open status and free-table count. It does not mention auth, rate limits, or closed-day edge cases, but for a trivial read that is minor.

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?

One dense sentence that front-loads the resource (weekend restaurant), the day-scope constraint, and the return semantics with zero filler. Nothing is wasted and nothing important is buried.

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?

For a one-parameter read tool with an output schema, the description tells the agent what it gets back (open/closed plus table count) and the Fri/Sat/Sun constraint that governs validity. Only the sibling-routing guidance is missing, which is a small gap for this complexity level.

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?

Single parameter with 100% schema coverage, including the YYYY-MM-DD pattern and description, so the schema does the heavy lifting. The phrase 'op een datum' adds nothing beyond the schema's format spec; 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?

States a specific verb (controleer) and resource (restaurant open status + free tables) plus a scoping constraint (weekendrestaurant, vr/za/zo). It clearly differentiates from getCamperAvailability and getAccommodationDetails by domain, but never names an alternative tool explicitly.

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?

Usage is implied: call it with a date to learn whether the weekend restaurant is open and how many tables are free. There is no statement of when not to use it or which sibling to prefer for other availability domains, so the agent must infer routing from the names alone.

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