Sporthotel IDEAL Hochgurgl

Freie Zimmer und Preise für einen Zeitraum

verfuegbarkeit_pruefen

Read-onlyIdempotent

Prüft live, welche Zimmerkategorien in einem Zeitraum frei sind, und liefert Endpreise in Euro für den gesamten Aufenthalt. Jedes Angebot enthält einen fertigen Buchungslink mit vorbefülltem Zeitraum und Kategorie — diesen Link unverändert weitergeben und niemals selbst eine Buchungs-URL zusammenbauen. Preise niemals schätzen oder aus älteren Antworten übernehmen. Ist nichts frei, danach alternative_termine aufrufen. WICHTIG: Ein Preis ist noch keine Buchbarkeit — nur Angebote mit sofort_buchbar=true können verbindlich online gebucht werden. Bei false (Grund im Feld grund) dem Gast offen sagen, dass online keine Sofortbuchung möglich ist, und die unverbindliche Anfrage über den Link anbieten, statt Verfügbarkeit zu versprechen. Jedes Angebot hat einen EIGENEN Link inklusive Verpflegungsvariante — immer den Link des Angebots weitergeben, das dem Gast genannt wurde, und ihn nie verändern.

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	Sprachcode, z. B. de, en, it, fr
`adults`	No	Anzahl Erwachsener (1–4)
`check_in`	Yes	Anreise JJJJ-MM-TT
`children`	No	Alter der Kinder in Jahren, kommagetrennt (z. B. "6,9"). Das Alter bestimmt den Preis — bitte immer erfragen.
`check_out`	Yes	Abreise JJJJ-MM-TT

Output Schema

TableJSON Schema

Name	Required	Description
`naechte`	No
`check_in`	No
`waehrung`	No
`abschluss`	No	direktbuchung oder anfrage
`check_out`	No
`kategorien`	Yes
`verfuegbar`	Yes
`vollstaendig`	No	false = Prüfung abgebrochen, NICHT als "nichts frei" deuten

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

While annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds substantial behavioral context: each offer contains a prefilled booking link, links must be passed unchanged, price does not imply bookability, and the sofort_buchbar/grund fields carry operational meaning. This goes far beyond what annotations reveal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is an excellent front-loaded summary, and every sentence carries operational value. However, the warning about passing links unchanged appears twice in slightly different forms, adding redundancy to an otherwise focused description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description covers purpose, live behavior, link handling, price reliability, booking-status semantics, fallback routing to alternative_termine, and guest-facing behavior for non-bookable offers. With an output schema present, return-value details do not need to be repeated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline of 3 applies. The description adds some semantic context like 'Endpreise für den gesamten Aufenthalt' and the link/meal-option behavior, but it does not meaningfully elaborate on individual parameters beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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: it live-checks which room categories are free for a time period and returns final prices in EUR for the whole stay. This clearly distinguishes the tool from availability-adjacent siblings like alternative_termine and raten_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use context ('Prüft live'), and explicitly instructs calling alternative_termine when nothing is available. It also provides strong negative guidance: never estimate prices, never reuse older answers, never construct booking URLs yourself.

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

All Sporthotel IDEAL Hochgurgl tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools target a distinct job (availability, alternative dates, rate terms, extras, photos, FAQ), and the descriptions give explicit routing cues. The only mild ambiguity is between search+fetch and frage_zum_haus, since both access hotel content, but their intended use is clearly separated.

Naming Consistency3/5

All names use lowercase with underscores, but the convention is mixed: English verbs (fetch, search) sit beside German noun phrases (zimmer_bilder, zusatzleistungen), two *_info labels, and a noun-verb compound (verfuegbarkeit_pruefen). This is readable but not a consistent verb_noun pattern.

Tool Count5/5

Nine tools is a well-scoped count for a hotel assistant covering information, availability, rates, extras, photos, and content retrieval. No redundant bulk; each tool has a clear role.

Completeness4/5

The surface covers the main guest journey: house info, FAQs, availability, alternative dates, rate conditions, extras, and photos. There is no direct booking-creation or contact-request tool, but the booking links in verfuegbarkeit_pruefen make the workflow usable.

Resources

Need Help?