Skip to main content
Glama

Sporthotel IDEAL Hochgurgl

Fotos einer Zimmerkategorie

zimmer_bilder
Read-onlyIdempotent

Liefert echte Fotos einer Zimmerkategorie als Bilder, die dem Gast direkt angezeigt werden. Aufrufen, wenn nach dem Aussehen eines Zimmers gefragt wird ("wie sieht das aus", "zeig mir"). Die zimmertyp_id stammt aus hotel_info oder verfuegbarkeit_pruefen. Sparsam verwenden — Bilder sind gross; ohne ausdrückliche Nachfrage genügt die Beschreibung.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoSprachcode, z. B. de, en, it, fr
anzahlNoWie viele Bilder (1–3, Vorgabe 1)
zimmertyp_idYesid der Kategorie aus hotel_info

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
titelNo
anzahlYes
kategorieYes

Schema Changelog

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

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, open-world safety. The description adds useful behavioral context beyond this by warning that images are large and should be used sparingly, and by indicating that the returned images are meant for direct guest display. 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.

Conciseness5/5

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

Three sentences, all purposeful: purpose, trigger and source, and usage caution. Information is front-loaded and no words are wasted.

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?

For a simple read-only media tool with an output schema and full parameter documentation, the description covers purpose, when to call, where the ID comes from, and an important cost/performance warning. 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by stating that zimmertyp_id must come from hotel_info or verfuegbarkeit_pruefen, which helps the agent source the required parameter correctly. This extra context justifies a score above baseline.

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 states a specific verb and resource: it 'delivers real photos of a room category as images' that are shown directly to the guest. It clearly distinguishes itself from sibling tools that provide descriptions, rates, or availability by focusing on visual appearance and includes concrete trigger phrases ('wie sieht das aus', 'zeig mir').

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

Usage Guidelines4/5

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

It gives explicit when-to-us guidance (when the guest asks about the look of a room) and explicit when-not-to-us guidance (without an explicit request, the textual description suffices). It also tells where the required zimmertyp_id comes from. However, it does not name a specific sibling tool as the preferred alternative, so it falls slightly 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.

Try in Browser

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