Landhaus Apartments Prägant

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

Annotations already cover the read-only/no-destruction profile, but the description adds substantial behavior beyond them: applied booking rules, recommendation logic, output composition, fallback to nearest bookable dates, multi-apartment grouping for large parties, latency (~1-2 s), 90 s caching, and isError on invalid input. These are exactly the traits an agent needs to plan calls and handle edge cases.

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 core purpose, then organizes detail under 'Not for:' and 'Behaviour:' headers, which is easy to scan. It is fairly long and slightly redundant (return-shape described despite an output schema), but nearly every sentence carries actionable 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?

Given a true output schema and full annotation coverage, the description need not restate return values yet still summarizes the text plus structuredContent shape. Combined with usage routing, prerequisites, and behavioral traits, an agent has everything needed to call it correctly and route follow-ups.

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 the schema already documents all five parameters including the adults-total and children-ages semantics. The description reinforces party/date framing and constraint context (max 60 nights, closures, arrival days) but adds little parameter dictionary detail beyond what the schema provides, so 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 ('Check live availability and exact prices') scoped to a named property and input shape ('concrete dates and a party'). It clearly distinguishes itself from siblings by labeling itself 'the main tool' and naming what it is not (get_rates, get_apartment_details).

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 trigger ('Use this whenever a guest names dates'), explicit exclusions with named alternatives ('Not for: ... (get_rates) ... (get_apartment_details)'), a prerequisite ('ask for dates, number of adults and ages of all children first — never assume them'), and a routing rule for the visual sibling (render_availability_card with same arguments). Nothing is left 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the data source (praegant.net), sync frequency (hourly), response speed, and the fallback behavior for unknown numbers (returns list of existing apartment numbers). These are meaningful behavioral traits not present in the structured annotations.

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 dense but every sentence serves a purpose: function, usage examples, exclusions/alternatives, special case, behavior, and return format. It is front-loaded with the main purpose and flows logically to edge cases, with no filler or tautology.

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 tool with two optional parameters, an output schema, and safety annotations, the description covers all necessary context: what it does, when to use it, behavior, output structure, and edge cases (unknown number, Studio #17). There are no significant gaps that would prevent an agent from using it correctly.

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?

Both parameters are fully documented in the schema (100% coverage), including the special value '17' and the language guidance. The description restates some of this but adds little new param-level meaning; it mainly reinforces what the schema already says. The return-shape info belongs to output, not parameter semantics, 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?

The description opens with a specific verb and resource ('Describe one or all apartments') and enumerates the exact fields returned (size, bedrooms, max guests, description, page link). It clearly differentiates from siblings by explicitly stating it contains no prices/availability and pointing to check_availability, get_rates, and render_apartment_gallery.

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 guidance is explicit: it gives example questions, states what the tool does NOT cover (prices/availability), and names the correct alternatives for those cases. It also covers the special case of Studio #17 and the visual gallery variant, leaving no ambiguity about when to choose this tool.

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 description adds significant behavioral context beyond the readOnlyHint and destructiveHint annotations: it states the tool is read-only, performs no availability check, is instant, and never books/reserves/takes payment by design. It also specifies the return structure (text plus structuredContent with fields). This exceeds what annotations alone 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 description is well-structured with purpose, usage, behavior, and return info clearly front-loaded. It is somewhat verbose but every sentence earns its place, explaining the non-commission model and the alternative tool. Minor redundancy exists (e.g., 'no commission' repeated), so it is not perfectly concise but is appropriately sized for the tool's complexity.

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 tool's complexity (6 params, 0 required, 100% schema coverage, output schema present), the description covers all necessary context: purpose, when to use, behavior, and return format. No critical information is missing for an agent to correctly select and invoke the 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?

The input schema has 100% parameter description coverage, so the baseline is 3. The description itself does not add new meaning to parameters beyond reiterating that dates are optional and prefilled; it doesn't expand on the detailed schema descriptions (e.g., adults total for groups, children age handling). Thus it adds minimal value over 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 clearly states the tool builds a direct booking link on praegant.net with optional pre-fill, and distinguishes it from check_availability which already returns booking links. It is specific about the resource and action, leaving no ambiguity about what the tool does.

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 when-to-use guidance is given: use when the guest has decided or wants to book without a price check. It also states when not to use it (when an availability result is at hand) and names the alternative (check_availability). This fully covers selection logic.

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 and destructiveHint=false, and the description reinforces read-only behavior while adding genuinely useful context: offers are synced hourly, expired ones are removed, and the response includes text plus structuredContent.offers with specific fields. This goes beyond what annotations alone provide.

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 well-structured: purpose first, then usage guidance, then behavior and return shape. Every sentence contributes useful information, and the sibling routing is packed into a few clear lines without redundancy.

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 tool with one optional parameter, an output schema, and strong annotations, the description is complete. It covers when to use it, when not to, what it returns, and how it behaves in terms of freshness and filtering. Nothing an agent needs to invoke it correctly 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% and the single optional language parameter is fully documented in the schema, including the instruction to match the conversation language. The tool description adds no additional parameter-level meaning, so 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?

The description opens with a specific verb and resource: 'List all current seasonal offers and packages published on praegant.net.' It clearly distinguishes this tool from siblings by framing it as the date-independent offers listing, while check_availability and render_offers_card are explicitly named as alternatives.

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 gives explicit when-to-use guidance: use when the guest asks about deals, packages, or seasonal specials independent of dates. It also gives a when-not-to-use rule: if the guest already has dates, check_availability covers valid offers and there is no need to call both. It even names the visual alternative render_offers_card.

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 mark it read-only and non-destructive, and the description adds valuable behavior: live from the booking system, 1-2 seconds latency, 5-minute cache, and returns text plus structuredContent. This goes beyond the annotations and gives the agent realistic operational expectations.

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 yet complete: purpose, usage context, exclusion, alternative, behavior, and return format are all covered in a few sentences. Every sentence earns its place and the most important purpose is front-loaded.

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 lookup tool with zero required parameters and an output schema, this description fully covers what the tool does, when to use it, what it returns, and how it behaves operationally. Nothing critical 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%, so the schema already documents all five parameters. The description does not need to add parameter-level meaning, though it does helpfully clarify that the returned price is for a reference stay with final cleaning and tourist tax.

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 resource: get the price level of each apartment for a whole month plus booking rules. It also clearly distinguishes itself from check_availability and render_rates_card, so an agent can differentiate it from 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 when to use it ('when the guest has no exact dates yet'), when not to use it ('Not for exact prices on specific dates'), which sibling to use instead (check_availability), and that render_rates_card is the visual version with the same arguments.

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/openWorldHint=false, but the description adds genuinely non-structured context: static curated content from the property, no web search, instant response. Slightly redundant given an output schema exists, but the 'no web search' guarantee is behavior an agent cannot infer from annotations.

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 core purpose and routing exclusions, but the long inline enumeration of house services and domains is verbose and partially duplicates the schema's topic list. Efficient in intent, mildly over-long in execution.

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?

Output schema exists, so the return-format sentence is bonus rather than necessity; annotations cover safety; both parameters are fully documented in the schema. Nothing an agent needs to call this correctly 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% and the schema already lists allowed topics, aliases, empty=overview, and the language default/behavior. The description's topic enumeration largely repeats the schema, so it adds little beyond what is already structured. 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 and resource ('Return curated information about Bad Kleinkirchheim and the house for a topic') and immediately scopes it against siblings by name. An agent can distinguish this from check_availability and get_apartment_details 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 lists when to use it ('what can we do there?' and house questions, with enumerated topic domains) and when not to ('Not for prices or availability (check_availability) and not for apartment facts (get_apartment_details)'). Both the alternative tools and the selecting condition are named.

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 and destructiveHint=false, and the description reinforces this with 'read-only, no prices.' It adds useful behavioral context beyond annotations: the swipeable photo counts, buttons for availability/page access, and the fact that the result matches get_apartment_details plus photos.

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?

Compact and front-loaded: the first sentence says what the tool does, and the second sentence provides the selection rule. Every sentence earns its place with no redundant detail.

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 a full input schema, an output schema, and safety annotations present, the description adds the missing decision context: when to use it, what the gallery shows, and how it differs from get_apartment_details. Nothing needed for correct invocation 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%, so the schema already fully documents both parameters. The description adds only broad context ('Same arguments') and the one/all semantics, which are already reflected in the schema. This meets the baseline but does not substantially enrich parameter meaning.

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 ('Show') plus resource ('one or all apartments with photos') and the output format ('interactive gallery card'). The description explicitly contrasts with get_apartment_details by adding photos, so the tool is clearly differentiated from its 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?

Gives explicit routing guidance: 'Use instead of get_apartment_details when the guest wants to see the apartments' and clarifies the one-apartment vs all-apartments photo behavior. This leaves no ambiguity about when to choose this tool over the nearest 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/destructiveHint/openWorldHint, and the description adds real value on top: it confirms 'live, nothing booked', states that behaviour and arguments are identical to check_availability, and discloses the extra output (small photos, Google rating) plus the fact that text and structuredContent are the same. That is exactly the kind of context annotations cannot carry.

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: what it is, when to use it vs the alternative, then behavioural/output equivalence. The routing decision is front-loaded and no sentence 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?

Output schema exists and the description need not explain return values, yet it still usefully notes the card's extra content and the parity with check_availability's text/structuredContent. For a read-only rendering tool with full annotations and full schema coverage, nothing an agent needs 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% and the schema itself explains adults-vs-children counting, date formats, night limits and language defaults in detail. The description only says arguments are 'identical to check_availability', adding no semantics beyond the schema, so the baseline of 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 ('Show the availability result ... as an interactive card in the chat') and immediately distinguishes itself from the near-identical sibling check_availability by naming the rendering difference. An agent can pick between 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?

Gives explicit when-to-use ('when the guest wants to SEE the options'), when-not ('only reasoning over the data or when the client cannot display cards'), and names the alternative tool (check_availability) by name. Nothing is left 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=true and destructiveHint=false, and the description reinforces this by stating the tool is read-only. It adds useful behavioral context by explaining the result is identical to get_offers plus a photo per offer, and that the output is an interactive card, which goes beyond the structured annotation 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 two concise sentences with no filler. The first sentence states the core purpose, and the second immediately provides usage guidance and sibling differentiation, making it easy to scan.

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 single optional parameter, full schema coverage, read-only annotations, and explicit comparison to get_offers, the description covers everything needed to select and invoke the tool correctly. The presence of an output schema also means the description does not need to explain return values.

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 schema has 100% coverage for its single optional parameter, with a clear description of the 'language' field and its default. The description adds no parameter-level details beyond the schema, but the schema already carries the full burden, so a baseline score 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?

The description names a specific verb ('Show'), a concrete resource ('current website offers'), and the output form ('interactive card with photos and links'). It explicitly distinguishes itself from the sibling tool get_offers by the visual presentation, so an agent can tell them apart without opening the 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 description explicitly says 'Use instead of get_offers when the guest wants to browse the offers visually' and clarifies that behavior and result match get_offers plus a photo. This gives clear selection criteria against the main sibling and leaves no ambiguity about when to invoke it.

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 and destructiveHint, and the description adds useful behavioral context: the tool is 'live', returns the same result as get_rates, and renders an interactive card with tappable apartment lines. It does not repeat the annotation data verbatim, adding value beyond the structured fields, though it does not discuss output details because the output schema covers 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 three sentences with no filler. It front-loads the core purpose, immediately gives usage guidance with an explicit alternative, and closes with a concise reference to shared arguments/behavior.

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 100% schema coverage, existing output schema, and annotations that already communicate the read-only safe behavior, the description is complete enough for an agent to select and invoke the tool correctly. It even clarifies the relationship to get_rates, which is the key sibling in this context.

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 every parameter has detailed documentation with defaults, ranges, and examples. The description only says 'same arguments as get_rates', which adds no new parameter meaning beyond what the schema already provides, so 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?

The description clearly states the tool's function: showing a month's prices and booking rules as an interactive card in chat. It explicitly distinguishes itself from get_rates by noting when one should be preferred over the other, so an agent can tell the tools apart.

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 usage direction: use this tool when the guest wants the overview, use get_rates when only data is needed. This directly addresses selection between the two most similar tools and leaves no ambiguity about the primary alternative.

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