Skip to main content
Glama

get_tourism_details

Read-only

Kuratiertes Detail zu EINEM Niedersachsen-Hub-Treffer per id — Beschreibung, Öffnungszeiten, ECHTER Preis, Adresse, Medien. Für „was kostet der Eintritt für X", „wann hat X geöffnet" ist dieses Werkzeug die Auskunft. Tool-Semantik-Abgrenzung: dieses Tool = Detail zu EINEM kuratierten NDS-Treffer (dessen id/global_id). NICHT get_poi_details (das ist die OSM-Detail-Bridge per OSM-ID). NICHT search_tourism (das ist die kuratierte Region-/Typ-SUCHE die die id erst liefert). When to use: nach search_tourism lieferte einen Treffer mit id und die Anfrage will Detail/Preis/Öffnungszeiten — DE: „was kostet der Eintritt für ", „Öffnungszeiten von ", „erzähl mir mehr zu ". EN: „opening hours / price of ". When NOT to use: ohne vorherigen search_tourism-Treffer mit id (KEIN raten/erfinden einer id); OSM-POI-Detail per OSM-ID → get_poi_details; Region-Suche → search_tourism. Required args: id (die id ODER global_id aus einem search_tourism-Treffer, z.B. "e_101102405"). Optional: query (Region/ Name-Hint — dieselbe Region wie bei der Suche; die kuratierte Quelle hat KEINEN Objekt-per-id-Endpunkt, daher re-sucht das Detail diesen Scope und matcht die id; ohne Hint ggf. honest-empty für ids außerhalb der Default-Seite). Typical chain: search_tourism(region=<R>, type=event) → get_tourism_details(id=<treffer.id>, query=<R>). Multi-call: ein Call pro id; nach search_tourism mit N Treffern pro Top-Treffer parallel rufbar. Anti-Fab note: Name, Beschreibung, Preis, Öffnungszeiten, Adresse kommen AUSSCHLIESSLICH aus sources[].subjects[].properties dieses Aufrufs. sources: [] heißt: zu diesem Treffer ist nichts abrufbar — so wiedergeben („Zu diesem Treffer konnte ich keine Detail-Informationen abrufen"). Returns {id, sources:[{source, license?, subjects:[{subject, properties:{name, type, description?, opening_hours?, price?, address?, date?, media?, coord?, url?, hub_detail_url?}}]}], facts?}. Die Felder sind die schema.org-Felder des kuratierten Datensatzes: price aus priceRange/offers, opening_hours aus openingHoursSpecification, coord aus geo, url = schema.org-Link — alle additiv, present nur wo die Quelle sie trägt. Bei einer Tour (t_…) zusätzlich: path_on_map — ihr Verlauf als [{lat,lon}], ausgedünnt auf die Punkte, die seine Form tragen; das ist die zeichenbare Strecke, und NUR das Detail trägt sie (die Suche nicht). Dazu die Achsen des Datensatzes: length_m, duration_min, ascent_m/descent_m, round_trip, activities (wörtlich, als was er die Tour führt). Alle aus ET2014A.json, alle nur present wo die Quelle sie führt — eine fehlende Achse ist unbekannt, keine Null. Dazu trail_shape — round (Rundweg), line (Strecke) oder ascent (Aufstieg), aus dem Verlauf gelesen und vor round_trip maßgeblich — und entries: wo man einsteigt, der empfohlene Einstieg zuerst, [{lat,lon,reason,name?,stop?:{name,distance_m,source,license}}]. reason: nearest_to_stop (Punkt des Wegs am nächsten an einer Haltestelle), course_end (das haltestellennähere Ende einer Strecke) oder official_start (der Startpunkt; bei einem Aufstieg immer). stop ist die nächste bediente Haltestelle aus OpenStreetMap, distance_m die Luftlinie bis dorthin — den Fußweg nennt erst die Verbindung. Die Anreise mit Bus und Bahn (Server MobilityMCP) führt zum ersten Eintrag, mit Auto oder eigenem Rad zum official_start. Fehlt entries, war die Haltestellenfrage nicht zu beantworten: dann gilt der Startpunkt (coord), so benannt. facts (additiv, top-level): normalisierte Öffnungszeiten + Preis mit Pro-Feld-Provenance — kuratiert hat Quellen-Priorität VOR der OSM-Bridge get_poi_details. price.free=true bei explizit kostenlos/Eintritt frei, false bei einem Betrag; price.raw trägt den kuratierten Preis-String wörtlich. Fehlen opening_hours UND price → facts ABWESEND (ehrlich, nie erfunden). hub_detail_url (additiv, in properties, nur bei source: 'niedersachsen-hub'): die kanonische Entitätsseite dieses Datensatzes beim Niedersachsen-Hub, dem Nutzer nennbar — NICHT die Betreiber-Website, die daneben in url steht. Jeder Datensatz dieser Quelle, dessen Art beim Hub eine Eintragsseite hat, trägt sie schon im ersten Aufruf: POI (p_…), Tour (t_…), Veranstaltung (e_…), Unterkunft (h_…), Gastronomie (g_…), Gebiet (r_…). Ein Medien-Datensatz (m_…) hat keine solche Seite und trägt sie nicht. Fehlt sie, keine konstruieren. license (additiv, NEBEN source im sources[]-Eintrag — nicht in properties): {id?, url?, notice?, holder?} = Lizenz-Kennung, Lizenz-Text-URL, der WÖRTLICH wiederzugebende Lizenzverweis (DZT-copyrightNotice, § 3 der DZT-Nutzerbedingungen) und der zu nennende Urheber (das author- bzw. copyrightHolder-Feld des Datensatzes). Gibt er nichts an, ist das Feld abwesend — nie eine geratene Vorgabe-Lizenz. Nennst du einen Datensatz mit license.holder, nenne den Urheber mit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe `id` or `global_id` of a curated record from a prior `search_tourism` result (e.g. "e_101102405").
queryNoRegion/name hint to scope the lookup — pass the same region you searched in `search_tourism`. The curated source has no object-by-id endpoint, so the details lookup re-searches that scope and matches the id; without the hint it may honest-empty for ids outside the broad default page.

Schema Changelog

Changes observed during successful MCP inspections.

  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 cover safety (readOnlyHint=true, openWorldHint=true, destructiveHint=false), but the description adds substantial operational context beyond them: honest-empty behavior when sources:[], the no-object-by-id re-search quirk, the license/attribution obligation (license.holder must be named), and the anti-fabrication rule for name/price/hours. It does not, however, discuss rate limits or failure modes beyond the empty case.

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

Conciseness3/5

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

Front-loaded and sectioned with bold labels, but heavily over-long (~700 words) for a two-parameter read tool. Much of the text is return-value documentation that repeats the same honesty rule several times ('nie erfunden', 'noch nie eine geratene Vorgabe-Lizenz'), diluting the selection-critical guidance.

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?

No output schema exists, so the description carries the full burden and does so exhaustively: it enumerates the return shape (sources[].subjects[].properties), the additive facts block, tour-only fields (path_on_map, trail_shape, entries), and hub_detail_url/license placement. An agent knows both what it gets back and how to present it.

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 baseline is 3; the description earns extra by explaining provenance of `id` (id or global_id from a search_tourism hit, e.g. 'e_101102405') and the real role of `query` (the source has no object-by-id endpoint, so the detail re-searches that scope and matches the id). That rationale is more than the schema field descriptions give.

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?

States a specific verb and resource: 'Kuratiertes Detail zu EINEM Niedersachsen-Hub-Treffer per id', and immediately delimits against siblings: NOT get_poi_details (OSM bridge), NOT search_tourism (the curated search). An agent can distinguish the three tools without opening any schema.

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?

Explicit 'When to use' (after search_tourism returned a hit with an id, with quoted DE/EN example utterances) and 'When NOT to use' (no prior hit / no id guessing → search_tourism; OSM detail → get_poi_details). It also documents the typical call chain and parallel multi-call pattern.

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.

Resources