Landhaus Apartments Prägant

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns a group_note for groups >5, explains that Kärnten Card does NOT cover Römerbad Thermal Spa, and notes the HPP partnership for Greenfee. It does not describe pagination or exact response structure, but for a read-only availability check the added context is solid.

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 a clear opening, a return summary, a routing note, and a parameter list. It is longer than average, but every sentence earns its place by adding operational detail. The only minor issue is that the Kärnten Card / Greenfee / Römerbad notes, while useful context, are somewhat tangential to the core call and could be trimmed or moved to a notes section.

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 tool with no output schema, the description is complete: it states what is returned, how to handle groups, how to pass children, and how to choose language. It also names the sibling render_availability_card for the visual follow-up. An agent has everything needed to call this tool correctly and interpret 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 0%, so the description carries the full burden for parameter semantics. It does this thoroughly: check_in/check_out get format examples, adults gets a detailed explanation of total vs per-apartment semantics with group-size examples, children gets age semantics ('under 17') and format guidance, and language gets a clear default and a rule for when to use 'en'. This far exceeds what the schema provides.

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 ('Check real-time availability'), a specific resource ('holiday apartments at Landhaus Prägant, Bad Kleinkirchheim, Austria'), and the return content (apartments with nightly rates, cleaning fees, tourist tax, total price). It also explicitly distinguishes itself from render_availability_card, so an agent can tell it apart from siblings without opening schemas.

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: it is the data-only version, and the agent should call render_availability_card with the same arguments after reviewing this result. It also provides parameter-level usage rules (e.g., adults is the total group size, not per-apartment limit; language should match the conversation language). This is strong routing and usage context.

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. The description adds meaningful behavioral context: 'Data is live from the property management system' and clarifies this is the data-only variant, including what the caller should do before rendering. These add value beyond the annotations without contradicting them.

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 and front-loaded: purpose and return fields first, then live-data context, then alternative routing, then Args. Every sentence adds necessary information; there is no filler or 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 lookup with no output schema, the description is complete: it states the return fields, data source, parameter semantics, and the relationship to the gallery-rendering sibling. An agent has enough information to invoke this tool correctly and decide next steps.

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 0% description coverage and only lists default values, so the description carries full responsibility. It compensates thoroughly: explains each parameter, gives concrete examples ('11', '15', '#12', 'all'), documents the empty-as-all behavior, and enumerates language values with default and usage guidance.

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 ('Get details') and resource ('apartments at Landhaus Prägant, Bad Kleinkirchheim, Austria'), and explicitly lists returned fields (size, bedrooms, amenities, highlights, cleaning fees). It also distinguishes itself from the sibling render_apartment_gallery by calling itself the 'data-only version'.

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 this for data, then call render_apartment_gallery() with the same arguments for a visual card. Also instructs to match the language parameter to the conversation language, which is a clear usage rule.

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 the tool as read-only and non-destructive, so the security profile is covered. The description adds valuable behavioral context beyond that: it does NOT create a booking, requires no credit card, and provides both the link and contact details. It does not contradict the 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 operational purpose and parameter list are clear and reasonably front-loaded. However, promotional lines such as 'best price guaranteed' and 'Family-run since 1982' add little for an AI agent selecting or invoking the tool. These phrases dilute the description without improving call correctness.

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 an output schema exists and all parameters are explained with formats, examples, and defaults, the description is sufficient for a correct invocation. The main gap is that it does not state whether availability should be checked first via check_availability, or how the generated link behaves when the requested dates are unavailable.

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 0%, so the description carries the full burden for parameters. It compensates well by documenting every parameter: date format for check_in/check_out, example for apartment, comma-separated ages for children, adult default, and allowed language values. This is exactly what the schema itself fails to provide.

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: 'Get a direct booking link for Landhaus Prägant'. It also explicitly clarifies 'This does NOT create a booking — it provides the link and contact details,' which distinguishes it from booking-execution tools and helps it stand apart from sibling tools like check_availability and get_offers.

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 helpful context, such as direct booking without commission and no credit card required, and instructs the language parameter to match the conversation language. However, it never explicitly says when to use this tool instead of a sibling such as check_availability or get_offers; the intended routing is only implied by the tool name and purpose.

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 readOnlyHint=true and destructiveHint=false. The description adds valuable context: 'Data is live from the property management system' indicates real-time data, and 'data-only version' clarifies that it returns raw data rather than a visual presentation. This goes beyond the annotations without contradicting them.

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 efficient: three sentences plus a structured Args block. It front-loads the primary purpose, then provides usage and parameter details. No redundant or filler content; every sentence earns its 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?

For a tool with no output schema and one parameter, the description covers what the tool returns (special deals, packages, seasonal promotions), notes the live data source, and routes the agent to the visual card tool. There is enough information to correctly invoke the tool and interpret the high-level 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?

The schema provides no description for the language parameter (coverage 0%), so the description fully compensates by specifying the allowed values ('de' default, 'en') and the intended usage ('match the conversation language'). This is complete for a single-parameter tool.

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 verb 'Get', the resource 'active seasonal offers', and identifies the specific property and location. It also distinguishes itself from siblings by explicitly calling out the data-only nature and referencing the render_offers_card alternative. No ambiguity about what this 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?

The description explicitly states when to use this tool versus the alternative: 'This is the data-only version — for a visual offers card, call render_offers_card() with the same arguments after reviewing this result.' It also advises matching the conversation language for the language parameter, giving clear operational 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 the tool read-only and non-destructive. The description adds meaningful behavioral context: pricing is per apartment per night rather than per person, fees are itemized, and data is live from the PMS. This goes beyond the annotations and clarifies how to interpret the returned rates.

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-loaded with the core purpose, followed by critical pricing semantics, the sibling alternative, and then a clearly delineated Args section. Each sentence contributes unique information with no filler or repetition.

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?

Despite having no output schema, the description provides enough context for an agent to call the tool correctly: what data it returns, how to interpret cost semantics, which arguments to pass, and what to do next. 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 description coverage is 0%, so the description carries full responsibility for explaining parameters. It does so thoroughly: month shows example formats and empty default, guests explains range and default, and language lists allowed values with a matching heuristic. This fully compensates for the schema's lack of descriptions.

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 begins with a concrete verb and resource: 'Get current rates for apartments' at a specific property and location. It also explicitly contrasts itself with render_rates_card as the 'data-only version,' clearly differentiating it from a key sibling tool.

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 provides explicit usage direction: use this for data-only rates, then call render_rates_card() with the same arguments if a visual card is needed. It also gives per-argument usage hints such as month formats, default behavior, guest count limits, and language matching to the conversation.

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, so the safety profile is clear. The description adds useful behavioral context: it mentions live partner events and knowledge from the database, and explains that the topic parameter filters results. This goes beyond the annotations without contradicting them.

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 and appropriately sized. It front-loads the core purpose, then provides usage context, data source info, and parameter details in a clear, scannable format. Every sentence earns its 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?

The description is complete for a read-only information tool with a single optional parameter. It covers what the tool does, what data it includes, and how to use the parameter. The output schema exists, so return values don't need to be described. Minor gap: it doesn't mention whether the topic filter is case-sensitive or how it matches keywords, but this is not critical.

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 0%, so the description must compensate. It does: it explains the topic parameter's purpose, lists valid values ('winter', 'summer', 'wellness', 'golf', 'family', 'hiking', 'biking', 'workation', or any keyword), and clarifies that leaving it empty returns a general overview. This is meaningful guidance beyond the bare 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's purpose: getting information about Bad Kleinkirchheim and the surrounding region in Carinthia, Austria. It lists specific content areas (activities, attractions, weather, dining, transport) and provides example user queries, making it easy for an agent to understand what this tool does and when it applies.

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 provides clear usage context with example guest questions ('What can we do there?' or 'What's the area like?') and explains the optional topic filter. It doesn't explicitly exclude alternatives or name sibling tools, but the context is sufficient for an agent to select this tool for region-related 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 and destructiveHint=false. The description adds behavioral context beyond that: it performs the same lookup as get_apartment_details, produces identical text output, and renders an interactive visual card. No contradiction with 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 compact and front-loaded: purpose first, then usage guidance, then a short pointer for parameters. Every sentence earns its place and avoids duplicating what get_apartment_details already documents.

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 2 optional parameters, read-only annotations, and no output schema, the description provides enough to call the tool correctly: when to use it, its relationship to get_apartment_details, and its visual nature. It is slightly reliant on get_apartment_details for parameter details, but that reference covers the 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?

The input schema has 0% description coverage and only name/language with defaults. The description compensates by stating args are identical to get_apartment_details and pointing there for full docs, but it does not actually explain the parameters, leaving the definition dependent on another tool.

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: 'Render the interactive apartment gallery card' for a named property. It clearly differentiates from get_apartment_details by emphasizing visual presentation and from sibling render_* tools by specifying the gallery card and its visual contents.

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 says 'call this one when the user wants to SEE the apartment(s) visually' and places it after get_apartment_details confirms something worth showing. This gives a clear selection rule and names get_apartment_details as the text-output 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=true and destructiveHint=false, covering the safety profile. The description adds that it is 'interactive' and produces a visual card with photos and a 'Book now' button, which is behavioral context beyond annotations. No contradiction.

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 concise: two short paragraphs. The purpose and usage guidance are front-loaded, and every sentence earns its place. The pointer to check_availability avoids 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?

Given the tool has no output schema and is a visual renderer, the description sufficiently covers what the agent needs to know: it renders a card with photos, prices, and a button. It defers parameter details to check_availability, which is fine in this sibling context. No critical information is missing 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 0%, so the description must compensate. It explicitly says parameters are identical to check_availability and directs the agent there for full docs. This is a clear pointer, but it does not add any direct parameter meaning itself. It relies on the sibling tool, which is acceptable but not fully self-contained.

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 renders an interactive availability card for a specific property, and explicitly contrasts it with check_availability by noting it produces identical text output but adds visual elements. This directly differentiates it from sibling tools like render_apartment_gallery and render_rates_card.

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 guidance: use this when the user wants to see apartments visually, typically after check_availability confirms availability. It even names the sibling and the sequence, so an agent knows exactly when to invoke it versus 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it produces identical text output to get_offers() and is intended for visual display. It doesn't describe the exact rendering format or any side effects, but for a read-only render tool with annotations, this is sufficient.

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-loaded: it states the purpose in the first sentence, then gives usage guidance and parameter delegation in two more sentences. Every sentence earns its place, and the reference to get_offers() avoids redundant parameter documentation.

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 render tool with one optional parameter and no output schema, the description covers the essential context: what it renders, when to use it, and how it relates to get_offers(). The only minor gap is that it doesn't describe the visual card's content or behavior beyond 'interactive', but the reference to get_offers() implies the same data is displayed.

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 0%, but there is only one parameter (language) with a default of 'de'. The description says args are identical to get_offers() and defers to that tool for full parameter docs, which is a reasonable delegation. However, it doesn't explicitly state what language values are accepted or how the language parameter affects the output, so the agent must look up get_offers() to understand it fully.

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 renders an interactive offers card for a specific property and location, and explicitly distinguishes it from get_offers() by noting it is for visual display. The verb 'render' plus the resource 'offers card' makes the purpose 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?

The description explicitly says to call this tool when the user wants to SEE the offers visually, typically after get_offers() has confirmed there is something worth showing. It also names the sibling get_offers() as the alternative for non-visual text output, providing clear when-to-use 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 readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: this is the same lookup and same text result as get_rates(), only rendered visually. It does not describe detailed interaction mechanics, but the read-only nature and rendering purpose are adequately disclosed.

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 short sentences with no filler. The purpose and usage trigger are front-loaded, and the cross-reference to get_rates() minimizes duplication without losing necessary guidance.

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 low-complexity, read-only render tool, the description covers what the tool does, when to use it, and where full parameter docs live. It is slightly dependent on the get_rates() documentation to be fully self-contained, which prevents a perfect score.

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 0%, and the tool description does not define month, guests, or language semantics. Saying 'Args: identical to get_rates()' is a helpful pointer, but it defers all meaning to another tool rather than providing the compensating detail needed when schema coverage is low.

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: it renders the interactive rates card for a named property. It also explicitly distinguishes itself from get_rates by noting the difference between textual lookup output and a visual rates table, so an agent can tell them apart immediately.

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 when-to-use instruction: call when the user wants to SEE a visual rates table, typically after get_rates() has confirmed data exists. Naming get_rates() as the alternative and the trigger condition removes ambiguity.

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