Hotel Mondschein, Stuben am Arlberg

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

Beyond the readOnly/idempotent annotations, the description discloses conditional behavior: mock-sourced prices are placeholders, the online_booking flag changes the response to include per-room booking_options, and the tool never performs a write. It also specifies the fields inside each booking option so the agent knows what to hand to start_booking.

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 capability is front-loaded in the first sentence and every subsequent clause carries behavioral information with no filler. The phrasing is terse and slightly telegraphic in places (quoted 'source' and 'online_booking' keys), but nothing is wasted.

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 read-only availability/pricing tool with an output schema, the description covers the full agent-relevant flow: what comes back, the placeholder-price caveat, the expanded booking_options mode, and the handoff to start_booking or request_offer. Nothing needed to call it or act on its result 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 coverage is 100%, so all seven parameters are already documented with types, ranges and enums, and the description adds no per-parameter detail beyond 'given dates and guests'. Its extra content concerns response fields (booking_options, total incl. city tax) and an output-only 'source' flag rather than input semantics. Baseline 3 applies when the schema does the heavy lifting.

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 resource and return set: rooms for given dates and guests with a from-price per night in EUR plus the booking URL. That clearly separates it from plain listing tools like list_rooms or get_room, which supply ids rather than dated pricing. It stops short of naming those siblings explicitly, so differentiation is implied rather than stated.

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 explicit branching conditions — 'source' equals mock means prices are placeholders and the guest must be sent to booking_url; online_booking true means options should be passed to start_booking. It also closes the loop with 'Never books anything', routing the user to the site, start_booking, or request_offer, which is a clear when-not/alternative statement.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description does not contradict it. Beyond that it only describes payload contents, which the output schema also covers, and says nothing about error behavior for an unknown slug or about rate/size 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?

One front-loaded sentence with no filler, and the routing hint is placed at the end where it is easy to find. The long field enumeration is somewhat redundant given an output schema exists, which keeps it from a 5.

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?

Return values are covered by the output schema and both parameters are fully specified, so the definition is close to self-sufficient for a simple read-by-slug tool. The only omission is any statement about behavior when the slug is invalid or unknown.

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 2 parameters and 100% schema description coverage, the schema documents the slug pattern and the de/nl/en enum with a default. The description's remaining contribution—provenance of the slug (list_areas)—is already stated in the schema, so it adds little, but its parameter coverage is complete.

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 resource (one area guide) and enumerates its contents: introduction, section headings, nearby places, FAQ with distances and travel times, a Maps route link, and the page URL. That enumeration lets an agent distinguish it from sibling list tools such as list_areas and get_faq without opening a 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?

It explicitly states the prerequisite source for the key input: 'Use the slug from list_areas', establishing the list-then-fetch workflow with a named sibling. It does not name a when-not case or an alternative retrieval path, so it falls short of a full 5.

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 a safe, idempotent, non-open-world read, so the description focuses on content behavior: it returns coming nights with date, DJ, DJ origin, short introduction, and special nights, and explicitly states that nights without a DJ say so. That edge-case disclosure is genuinely useful. It adds little about pagination or how many nights are returned, which keeps it below 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?

Dense but purposeful: venue and schedule context first, then return contents, then example user intents. It is one long sentence chain, so the usage examples are slightly buried at the end, but no sentence is filler.

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 read-only single-parameter lookup with an output schema and full annotation coverage, the description supplies everything needed: what it returns, what happens when data is missing, when the club operates, and which user questions it answers.

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?

There is a single optional enum parameter whose schema description already covers the allowed values (de, nl, en) and the default. The description never mentions the language parameter, so it adds no meaning beyond the schema; with 100% coverage the baseline of 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 resource and scope: the club line-up for Mondschein Club's Electronic Friday, with venue context. It clearly distinguishes itself from the generic list_events sibling by naming the club, the weekly cadence, and the exact fields returned.

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?

Gives explicit example intents ('what is on at the club', 'who plays on Friday', nightlife questions) and notes practical conditions: no reservation, usually free entry, winter Fridays 21:30–02:00. It does not explicitly contrast itself with list_events or list_offers, so the alternative-selection guidance is implied rather than stated.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the return shape (matching questions + answers + FAQ page URL), though an output schema exists, making that partly redundant. It does not discuss empty-result behavior when a search term matches nothing.

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?

Three tight sentences with the topic enumeration front-loaded and no filler. The parenthetical topic list is dense but earns its place by revealing content scope; the return-value sentence is the only mild redundancy given the output schema.

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-only lookup with full schema coverage and an output schema, the description supplies the missing conceptual layer: what topics exist and what comes back. The remaining gap is sibling disambiguation against search_site and get_topic, which matters in a 17-tool surface.

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 100%, with the query parameter documented including examples ('Parken', 'hond') and the leave-out-for-all behavior, plus the language enum with its default. The description repeats only the optional-filter idea and adds nothing about query matching semantics or language affecting the returned URL.

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 resource (FAQ page Q&A) and enumerates the covered topics — check-in/out, seasonal house openings, slope distance, half board, dogs, parking, extra beds, cancellation, arrival — so an agent knows exactly what content lives here. It stops short of naming a sibling it is not, so the boundary with search_site or get_topic must be inferred.

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 only usage cue is 'Optionally filter with a search term,' which implies this is a browse-all-by-default lookup. There is no guidance on when to prefer this over search_site for free-text queries or get_topic/hotel_info for structured property facts, and no stated prerequisites.

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 read-only, open-world, idempotent, non-destructive behavior. The description adds the important failure mode (UNAVAILABLE) and a fallback to the Arlberg live page, though it does not detail rate limits or auth.

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?

Front-loads the resource and return contents, then gives usage and fallback in compact sentences. No wasted wording.

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 simple read-only status tool with an output schema and full parameter documentation, the description covers purpose, usage, and failure behavior. Nothing essential 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 coverage is 100% and the single language enum is fully documented in the schema. The description adds no parameter meaning beyond that, so 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 resource (lifts and slopes of Ski Arlberg around Stuben) and what is returned (open counts, per-lift status, fetch time). The 'are the lifts open' phrasing makes its purpose immediately distinguishable from hotel/weather siblings.

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 says to use it for 'are the lifts open' questions and gives a fallback when the live source is unavailable. It does not name alternatives, but no sibling covers lift status, so the guidance is clear.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds a genuine behavioral qualifier beyond that: only 'published' details are returned, and the word 'all' signals a complete, non-truncated record. It does not describe behavior for an unknown room_id, which keeps it short of 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?

Two sentences, front-loaded with the payload contents, then the identifier source and the sibling hand-off. Every clause carries information; no filler.

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?

The tool is a simple two-parameter read with an output schema, and the description already previews the returned sections and language handling. Nothing an agent needs in order to select or invoke it 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 coverage is 100%: room_id carries its source and example pattern, and language carries its enum and default. The description only echoes the room_id sourcing already present in the schema and says nothing about the language parameter, so it adds little beyond structured data.

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 resource (one room type) and enumerates exactly what comes back: description, size, guests, features, facts, photos with alt text, FAQ and page URL. This makes it trivially distinguishable from list_rooms (many rooms) and check_availability (prices on dates), both of which are named.

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?

Gives an explicit prerequisite ('Use the room_id from list_rooms') and an explicit alternative for the most likely confusion ('For prices on dates use check_availability'). The agent knows both where the identifier comes from and when to route elsewhere.

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?

The annotations already declare read-only, idempotent, non-destructive, and non-open-world behavior. The description adds useful context about scope and return contents, including facts, sections, FAQ, and URL, but does not go much beyond that.

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 compact and front-loads the covered categories, with the list behavior and return contents placed afterward. The first sentence is dense and the phrase 'no other tool covers' is slightly awkward, but most content earns its place given the large topic enum.

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 read-only content getter with an output schema, annotations, and fully described parameters, the description covers scope, list mode, and return shape adequately. The phrase 'the list' is slightly ambiguous about whether it means topics or something else, which keeps it from being fully complete.

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 100%, so the schema already documents both parameters and the enum values. The description adds some meaning by grouping topics into categories and translating halbpension as half board, but otherwise largely repeats the enum and the schema note to omit topic for the list.

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 that this retrieves facts from a single hotel page and enumerates the covered categories: dining, wellness, services, activities, dates, arrival, history, and company stays. It distinguishes the tool from siblings with the claim that no other tool covers these topics, though the core action is implied rather than stated with a clean verb.

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 a clear operational rule: omit the topic parameter to get the list. The statement that no other tool covers these topics provides implicit routing guidance, but no sibling alternatives are named and there is no explicit when-not guidance.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the upstream source (Open-Meteo) and a ~15-minute refresh cadence, which tells the agent how fresh the data is. It stops short of noting that forecast data is conditional/can be absent for some days.

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 sentence, front-loaded with the location and altitude, then the returned fields, then provenance and freshness. Nothing is padded or repeated from the annotations.

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 one fully documented optional parameter, the description does the remaining work well: it pins the location so the agent never asks for one, and covers source and freshness. Minor omissions (units, that forecast days may be empty) keep 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 coverage is 100% and the single optional 'language' enum (de/nl/en, default de) is fully documented in the schema. The description adds nothing about the parameter, so the baseline 3 for schema-covered parameters 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+resource ('Current weather in Stuben am Arlberg (1409 m) at the Ski Hotel') and enumerates exactly what is returned: temperature, snowfall, snow depth, weather code with label, and coming days. No sibling tool covers weather, and the fixed location makes the scope unambiguous.

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 rather than stated: the agent can infer this is the tool for weather questions, and 'when available, the coming days' hints at a limited forecast horizon. There is no explicit when-to-use/when-not guidance or pointer to an alternative (e.g. lift status for ski conditions), which is a real gap in a 17-tool sibling set.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating here. The description adds a genuine behavioral detail — that the address/coordinate data mirrors the house's Google profile, and that returned texts and links follow the language parameter. It says nothing about response shape, but an output schema exists, so that omission is acceptable.

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 subject and property are front-loaded and the closing routing sentences are efficient. However the middle is a long run-on inventory, and specific award counts ("Gault&Millau 4 toques, Falstaff 4 forks") and marketing content ("the Longboard Classic with its legends, and Glen Plake's quote") consume space without helping an agent decide or invoke.

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 zero-required-parameter, read-only fact lookup with full schema coverage and an output schema, the description covers the necessary ground: what content is returned, which house and language axes exist, and where to go for rooms or pricing. Nothing essential to correct invocation is missing, though the overlap with other informational siblings remains unaddressed.

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 are enums with defaults, so the schema already fully documents them. The phrase "of each house" in the description hints at the per-house granularity of the returned facts but adds no syntax, default, or interaction detail beyond the schema. 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 the specific resource (facts about Hotel Mondschein in Stuben am Arlberg) and enumerates the content families it returns: address/coordinates, contact channels, check-in/out, restaurant awards, opening hours, season. It also explicitly separates itself from list_rooms and check_availability, so an agent can place it among siblings. It stops short of a single crisp verb+resource statement because the opening is a content inventory rather than a summary of the operation.

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?

"Use for contact, address, directions and awards" gives an explicit use case, and two siblings are named with the conditions that select them (rooms, prices/dates). What is missing is routing against the other fact-like siblings such as get_faq, get_area, get_topic and list_houses, so the agent must still infer the boundary for general informational queries.

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=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about what content the guides cover (resorts, valleys, arrival routes from Zürich/München) and what fields come back, but says nothing about pagination, ordering, or result volume.

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 tight sentences, front-loaded with the verb and resource, with the sibling routing at the end. The long parenthetical listing resorts and cities is informative but slightly padded relative to the core statement.

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 the description needn't explain returns, yet it helpfully names the key fields. Scope, sibling routing and content coverage are all present; only ordering/pagination and language behavior are unaddressed, which are minor for a simple read-only list tool.

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?

There is a single optional parameter with 100% schema description coverage and an enum (de/nl/en) plus a default, so the schema fully documents it. The description never mentions the language parameter, adding no meaning beyond the schema; 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 (lists) and resource (area guides) and enumerates the returned fields (slug, name, title, page URL) plus the geographic scope of coverage. It also explicitly contrasts itself with the get_area sibling, so an agent can distinguish the two without opening either 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?

"Use get_area for travel times, routes and FAQ of one area" names the alternative and the condition that selects it, implying this tool is the browse/discovery step. It stops short of stating the complementary rule explicitly (e.g. 'call this first to get slugs before get_area'), so it is clear but not fully exhaustive.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: package rows use date as arrival and end_date as departure, and results carry flags like guests-only and sold-out plus a page URL. It does not discuss ordering or result volume, which keeps it short of 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?

The calendar scope is front-loaded in the first clause, followed by the package caveat, filters, and return fields in a logical order. The single dense sentence-with-parentheticals reads compactly but would scan faster as separate lines.

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 read-only filtered-list tool with four optional params and a full schema, the description covers content types, filtering options, package date semantics and the sibling hand-off. An output schema exists, so the brief return-field summary is a bonus rather than a necessity.

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 from/to, category and language are already documented with patterns, enums and defaults; the description mostly restates them. The only added meaning is that category values map onto the listed event types and that package dates mean arrival/departure, which is helpful but limited. 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 resource (the Hotel Mondschein event calendar: club nights, culinary evenings, festivals, sport and culture) plus date-fixed packages, and names the sibling get_club_lineup for club DJs. An agent can distinguish this from get_club_lineup and from list_offers without opening a 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?

Explicitly says the call can be narrowed 'optionally between two dates or one category' and routes club-lineup queries to a named alternative. It lacks guidance on when to prefer this over nearby tools such as list_offers or check_availability, but the core use context is clear.

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, destructiveHint=false and openWorldHint=false, so the description's job is to add context beyond that. It does so by disclosing the fixed cardinality (exactly three houses, so no pagination or filtering concerns) and the returned fields, though the field list partly duplicates the existing output schema.

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?

Front-loaded with the purpose and result set, followed by return fields and the next-step pointer, with no wasted sentences. Minor deduction for decorative detail ('4 stars, since 1739', 'private spa suites, open all year') that does not help an agent select or invoke the tool.

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 single-optional-parameter read tool with strong annotations and an output schema, the description covers what it does, what it returns in outline, and the correct next call. The only omission is the effect of the language parameter on returned text and links, which the schema already documents.

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?

The single 'language' parameter is fully documented in the schema (100% coverage with enum values and default), so the schema carries the semantics. The description never mentions that output text and URLs vary by language, adding nothing beyond the schema; baseline 3 applies under high coverage.

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 (Lists) and resource (the three houses), then enumerates them by name so the agent knows the exact, bounded result set. It is clearly distinguishable from sibling list_rooms, which is named as the follow-up.

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?

Provides explicit workflow sequencing: call this first to get house ids, then 'Use list_rooms with the house id next.' It does not state exclusions or a when-not condition, but since the tool has no filters and returns a fixed set, there is little alternative-selection ambiguity to resolve.

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 readOnly=true, idempotent=true, destructive=false and closed-world, so the safety profile is covered. The description adds a genuinely non-obvious behavioral caveat: prices are not authoritative here because they vary by date, and it tells the agent what to do about it. It does not discuss freshness of the offer list or pagination, but those are minor given the annotation coverage.

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 compact sentences, front-loaded with the action and followed by the pricing caveat. The enumeration of return fields is slightly redundant since an output schema exists, but it is short enough not to waste space.

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 does not need to document return values in detail, and it still covers the one trap an agent would hit — treating listed offers as priced. For a simple two-param read tool this is close to complete, missing only guidance on the offer-to-booking handoff.

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% with two fully enumerated, defaulted parameters (season, language), so the schema carries the parameter burden. The description never mentions either filter, meaning it adds no meaning beyond the schema; 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 and resource ("Lists the current offers and packages") and concretizes it with examples (ski packages, summer escapes), then names the exact fields returned. An agent can distinguish this catalogue-listing tool from booking or availability siblings without opening a 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?

Gives an explicit routing rule for the main ambiguity: prices are date-dependent, so use check_availability or send the guest to the offer page instead of relying on this list. It does not say when to move from browsing here to request_offer or start_booking, which leaves part of the sibling 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 establish a safe idempotent read with no open-world access, so the bar is lower. The description still adds real behavioral value by disclosing that from_price_per_night_eur is mostly low-season and is not the actual stay price, pointing to price_terms and check_availability — a caveat an agent could not get from the annotations or schema.

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, front-loaded with the purpose before the field enumeration, and every clause carries information an agent needs (returned fields, price caveat, routing). The long comma-separated field list is dense but earns its place; it could have been tightened slightly.

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-only listing tool with a full schema and an output schema, this covers purpose, scope, key caveats, and hand-offs to siblings. Nothing critical is missing, though pagination/volume behavior on the unfiltered 'all houses' case is unmentioned.

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 enum parameters are documented there, so the baseline is 3. The description only restates the optional house filter and says nothing extra about language defaults or how house values map to results, adding no meaning 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?

Opens with a specific verb and resource ("Lists the room types") plus the scope modifier ("optionally for one house"), then enumerates exactly what comes back (id, name, house, size, guests, features, booking mode, from-price, URL). It explicitly distinguishes itself from get_room (details) and check_availability (real stay price), so an agent can route without opening another 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?

Names both relevant alternatives with the condition that selects them: use get_room for details and check_availability for the real price of a stay, implying this tool is the overview/catalog step. The scoping rule ("optionally for one house", omit house for all) is also stated, leaving little 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 only declare it is a non-read-only, non-idempotent, non-destructive open-world call; the description adds what actually happens (an e-mail goes to the reservation team, nothing is booked or charged, the team replies by e-mail). It further discloses the guard behavior and named error outcomes, which annotations cannot express.

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?

Front-loaded with the action, then the safety preconditions and error semantics; nearly every clause carries operational meaning. It is semicolon-dense and reads as one long run-on, which costs a little scannability but not substance.

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 values need not be spelled out, yet the description still covers the decision-relevant outcomes (CONFIRMATION_REQUIRED, NOT_DELIVERED) and the confirmation gate. For a 12-parameter open-world submission tool, an agent has everything needed to call it safely.

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 100%, so the baseline is 3, but the description adds consequences the schema does not: confirm=false yields CONFIRMATION_REQUIRED with nothing sent, and privacy_consent ties to a policy URL surfaced in that answer. The company-stay hint (company in name, employees count) also clarifies two optional fields beyond their schema text.

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 and resource ("sends a non-binding offer request to the reservation team") and anchors it to a familiar analogue ("like the form on the website"). It also distinguishes the action from booking by stating "Books and charges nothing", which separates it from the sibling start_booking.

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?

Explicit preconditions are given: call only after the guest saw the exact content and agreed (confirm: true) and agreed to the privacy policy (privacy_consent: true). It also names the when-not path — otherwise CONFIRMATION_REQUIRED and nothing is sent — and gives a fallback for NOT_DELIVERED (hand out phone and e-mail).

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 readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds real behavior beyond them: results are capped at 8 pages and include title, kind, URL and a short snippet, and it tells the agent what to do next (fetch details or hand the guest the URL). Minor gap: nothing about ranking or what to do when nothing matches.

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?

Three sentences, front-loaded with what the tool searches, then when to reach for it, then what comes back. Every clause carries information; the example query terms and the result shape are the only elaboration and both earn their 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?

With an output schema, rich annotations and fully described parameters, the description needs only to cover selection guidance and result behavior, which it does. The one soft spot is the unexplained "kind" field and no note on empty-result behavior, but neither is required for correct invocation.

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 (query with min/max length, language enum with default) are documented in the schema. The description only adds a light gloss — that the search runs in a single language and that short single-word queries like "dogs" or "sauna" are the intended input — which is a marginal supplement to the schema, 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?

The description gives a specific verb and resource ("Full-text search over the pages of mondschein.com") plus the scope constraint ("in one language") and enumerates the content types covered (houses, rooms, dining, wellness, blog articles). An agent can immediately tell this apart from structured siblings like list_rooms or get_weather.

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 states a clear routing rule: use it "when no other tool fits or to find the right page for a question," with concrete example queries ("dogs", "sauna", "Lech", "parking"), and points onward to the matching detail tool. The when-not side is expressed only as the generic "no other tool fits" rather than naming which sibling covers which content domain, so it stops just short of fully explicit alternatives.

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 declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with a crucial disclosure that a tool named 'start_booking' otherwise obscures: 'Does not book, hold or charge'. It adds process rules (never ask for card details) and documented error outcomes with alternatives, which go well beyond the structured hints.

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 prerequisite is front-loaded, followed by what is returned, what the agent must do with it, the safety boundaries, and error codes. Each clause carries distinct information with no filler.

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, yet the description still names the key returned fields and the guest-facing next step, and it covers failure modes for a 9-parameter tool. An agent has everything needed to invoke it correctly and act on the result.

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 every parameter is already documented including the house/room_id/room_type combination and rate_id provenance. The description's parameter sentence largely restates that, though 'as returned' mildly reinforces that values must be passed through unmodified.

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 verb and output: it 'Checks again and returns a summary (room, dates, guests, total EUR) and checkout_url'. It is clearly distinguished from its prerequisite sibling check_availability by framing itself as the step 'After check_availability and the guest's choice'.

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 an explicit prerequisite (check_availability plus the guest's choice), tells the agent what to pass and where those values come from ('as returned'), and prescribes the follow-up flow: 'Show the summary, then give the guest checkout_url'. It also names when the tool cannot proceed, via the NOT_AVAILABLE and BOOKING_NOT_YET_ONLINE error cases.

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