zusatzleistungenListet die Leistungen, die sich bei der Online-Buchung dazubuchen lassen, mit Preis und Abrechnungsart. "pro_nacht" wird bei der Buchung automatisch mit den Nächten multipliziert — nicht selbst hochrechnen.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Sprachcode, z. B. de, en, it, fr |
| Name | Required | Description | Default |
|---|---|---|---|
| waehrung | No | ||
| zusatzleistungen | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: 'pro_nacht' is automatically multiplied by the number of nights during booking, so the agent should not manually calculate it. This directly prevents a likely misuse.
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 short, purposeful sentences: the first states the tool's main output, and the second warns about the `pro_nacht` calculation. There is no redundant or filler content.
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 list tool with an output schema, optional language parameter, and clear annotations, the description is complete. It covers what is returned, the booking context, and the one non-obvious behavioral pitfall.
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 already fully documents the single optional `lang` parameter, so the description does not need to repeat it. The baseline of 3 applies because schema_description_coverage is 100% and the description adds no extra parameter-specific 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?
The description clearly states what the tool does: it lists additional services that can be booked online, including price and billing type. This is a specific verb and resource, and it distinguishes itself from sibling tools about rates, availability, or hotel information.
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 a clear usage context: use this tool when the agent needs bookable add-on services for an online booking. It does not explicitly name alternatives or exclusions, but the scenario is unambiguous enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.