lodging-intelligence
Server Details
Romanian lodging character intelligence: calm, nature, culture, stays, itinerary maps. Read-only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 7 of 7 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: introspection, zone exploration, accommodation search, accommodation detail, static map retrieval, interactive map display, and itinerary map display. No two tools overlap in functionality.
Most tools follow a verb_noun pattern (explore_areas, find_accommodations, get_accommodation, get_map, show_map, show_itinerary_map), but 'capabilities' is a standalone noun, breaking the pattern. This is a minor inconsistency.
With 7 tools, the server covers the essential operations for a lodging intelligence domain: metadata, zone exploration, accommodation search, detail retrieval, and multiple mapping functionalities. The count is well-scoped for its purpose.
The tool set covers the core workflows: discovering areas, finding accommodations, getting details, and visualizing on maps (both static and interactive, including itineraries). No obvious gaps for the intended use case of exploration and comparison.
Available Tools
7 toolscapabilitiesCapabilitiesARead-onlyIdempotentInspect
Versiunea serverului MCP tria.ro, tool-urile publicate și VOCABULARUL complet, structurat: tokeni (interfața standard pentru intenții/facilități/experiențe/stil), teme (filtre avansate pe 4 piloni) și criterii (semnale avansate de ranking). Toate cu slug+etichetă, ca să ceri exact fără să ghicești și fără să confunzi axele. Plus ce e rezervat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| tools | No | |
| server | No | |
| version | No | |
| rezervat | No | Parametri planificați, încă inactivi |
| resources | No | Resurse dereferențiabile prin resources/read (template-uri). Clienții care citesc template-uri (ex. Claude) le pot citi direct; pe ChatGPT folosește get_map (bytes inline) ca fallback. |
| rezolutie | No | Cum se citește câmpul `rezolutie` din rezultate |
| vocabular | No | |
| updated_at | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about what is returned (vocabulary structure, version, tools) but does not disclose any additional behavioral traits beyond annotations. It is sufficient given the annotation coverage.
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 moderately concise, front-loading the purpose and structure. It could be slightly shorter, but it provides necessary details without excessive verbosity.
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's simplicity (no parameters, output schema exists), the description is complete. It covers the server version, tool list, and vocabulary structure. The mention of 'plus ce e rezervat' adds a bit of extra context. No further details are needed.
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 tool has zero parameters, and the schema coverage is 100%. The description does not need to add parameter information, so the baseline score of 4 is appropriate.
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 that the tool returns the MCP server version, published tools, and a structured vocabulary (tokens, themes, criteria) with slugs and labels. This is a specific verb+resource, and it distinguishes itself from sibling action tools by being a meta/discovery 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?
Usage is implied: first use this tool to get the vocabulary for precise requests. However, there is no explicit when-to-use or when-not-to-use statement, nor are alternatives mentioned. The sibling tools are action-oriented, so the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_areasExplore AreasARead-onlyIdempotentInspect
Clasează ZONE (nu cazări) după caracter, ca să răspunzi „unde să merg". scope: "judet" (implicit), "localitate" (în interiorul unui județ — dă where), "statiune" (litoral). Ranking după un semnal (sort) sau compozit (criterii). Ex.: județele cele mai montane, stațiunile cele mai potrivite pentru familie. Sursă: tria.ro.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | O dimensiune de ranking: liniste, natura, munte, apa, family, gastro, vin_crame, crame, cultura_istorie, cultura, nightlife, business, relaxare, magnetism, turism, urbanitate (pentru statiune și plaja/farmec/anvergura/afluenta). | |
| limit | No | Top N (implicit 8, max 30) | |
| scope | No | Granularitatea ariei: judet (implicit) | localitate | statiune | |
| where | No | Doar scope=localitate — județul părinte, ex. "Brașov". | |
| criterii | No | Ranking compozit (media) — doar pentru statiune. |
Output Schema
| Name | Required | Description |
|---|---|---|
| areas | No | Zonele clasate |
| judet | No | Județul părinte (doar scope=localitate) |
| scope | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context (ranking algorithm, source tria.ro) but no contradictions. It does not expand on rate limits or side effects, which is acceptable given the annotations cover mutability.
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 extremely concise (2 sentences) yet packs essential information: purpose, scopes, parameters, and examples. Every sentence serves a purpose, and the structure front-loads the main action. No wasted words.
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 5 optional parameters and an output schema (not shown), the description covers the key aspects: ranking dimension, scopes, examples. It could explain the composite criteria more explicitly or detail when to use each scope, but the examples help. The annotations and schema describe safety and return types, so completeness is adequate.
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 coverage is 100%, with each parameter described. The description adds value by explaining the ranking logic ('sort' vs 'criterii') and providing examples that tie parameters to use cases (e.g., 'criterii' for composite ranking in 'statiune' scope). This goes beyond the basic schema 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 clearly states the tool classifies zones (not accommodations) by character to answer 'where to go', with specific examples like 'the most mountainous counties' or 'most family-friendly resorts'. It distinguishes itself from sibling tools like find_accommodations and get_map by explicitly saying 'nu cazări' (not accommodations).
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 examples of when to use (ranking counties by mountain character, resorts by family suitability) and hints at alternatives by excluding accommodations. It does not explicitly state when not to use, but the examples and scope options give good contextual guidance. Slight improvement could explicitly mention alternative tools for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_accommodationsFind AccommodationsARead-onlyIdempotentInspect
Găsește cazări ORIUNDE în România (tria.ro), pe litoral sau în țară, după LOC, CARACTER și (în viitor) PERIOADĂ. TOȚI parametrii sunt OPȚIONALI — fără niciunul întoarce TOPUL NAȚIONAL (toate cazările, clasate ca recomandate). where = locație structurată (rezolvată server-side); nume = doar nume de cazare/proprietate/brand, nu facilități sau experiențe. Pentru agenți AI, folosește tokeni pentru orice intenție de caracter, experiență, facilitate sau stil ("liniste", "animat", "retras", "accesibil", "munte", "mare", "apa", "natura", "podgorie", "gastronomie", "viata-de-seara", "liniste-seara", "cultura", "urban", "balnear", "vibrant", "activ-noaptea", "cu-piscina", "cu-spa", "cabane", "lux", "spa", "ciubar", "drumetii", "ciclism", "atv", "delta", "echitatie", "schi", "degustari-vin", "foc-tabara", "piscina", "copii", "evenimente"). Serverul mapează intern tokenii la filtre/ranking/experiențe. Întoarce o listă clasată cu semnalele de caracter tria; fiecare rezultat poartă rezolutie (adâncimea semnalului per rând, național=ambient). NB: lista implicită este recomandate/încredere; pentru „cea mai bună pentru mine" se exprimă tot prin tokeni; criterii/teme sunt parametri avansați/legacy. Fiecare card poate purta pret_de_la = preț ORIENTATIV „de la X" (live Agoda, weekendul următor, unde e disponibil — NU e disponibilitate garantată; rezervarea/verificarea finală pe get_accommodation → site-ul partener). La căutări largi (doar temă fără loc, sau loc fără temă) răspunsul include restrange — zone (cu count) + teme pe piloni (cadru/stil/atmosferă/facilități, cu count): OFERĂ-l ca CLARIFICARE („în ce zonă? ce stil/atmosferă?"), dar NU ești obligat să restrângi — rezultatele vin oricum. Pe hartă: show_map cu aceiași parametri. Atribuie sursa tria.ro.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | „Lângă mine" / în jurul unui punct. Alternativ cu where. | |
| nume | No | DOAR nume de cazare/proprietate/brand, ex. "Hotel Studis", "Vila Maria". Nu folosi pentru facilități, experiențe, stil sau caracter; acelea merg în `tokeni`. | |
| page | No | Pagina (implicit 1) — total arată câte corespund | |
| sort | No | AVANSAT/legacy: o singură dimensiune de ranking când nu dai tokeni/criterii: popularitate | liniste | natura | … (vezi criterii). Pentru user intent folosește `tokeni`; pentru potrivire personală, serverul calculează dinamic `potrivire` când există intenție. | |
| teme | No | AVANSAT/legacy: filtre UI/SEO interne. Pentru agenți AI, preferă `tokeni`; o temă este intern un set de tokeni. | |
| limit | No | Câte pe pagină (implicit 10, max 30) | |
| where | No | UNDE — LOCAȚIE structurată: județ / oraș / localitate / stațiune. Ex. "Brașov", "Bran", "Mamaia". Reperele cunoscute (sat/lac/pârtie pe care harta nu le are ca unitate: Colibița, Bâlea, Rânca, Cheia) se rezolvă la COMUNA care le conține. OPȚIONAL. Nu pune aici facilități/experiențe sau nume de cazare; facilitățile/experiențele merg în `tokeni`, numele cazării merge în `nume`. | |
| tokeni | No | Interfața standard pentru agenți: tokeni publici într-o singură listă. Ex. ["ciubar"], ["lux"], ["spa"], ["piscina"], ["drumetii"], ["mare","retras"], ["munte","liniste"], ["urban","gastronomie"]. Pentru orice user intent/facilitate/experiență/stil folosește acest parametru, nu `nume`, `teme` sau `criterii`. Vezi capabilities().vocabular.tokeni. | |
| criterii | No | AVANSAT/legacy: ranking pe semnale interne. Pentru agenți AI, preferă `tokeni`. Vocabular: popularitate,liniste,natura,munte,apa,plaja,family,gastro,vin_crame,crame,cultura_istorie,cultura,nightlife,business,relaxare,urbanitate,izolare,magnetism,turism,afluenta,afluenta_turistica,anvergura,farmec,dezirabilitate,animat,cafea,plimbare,aproape_de_mare,aproape_de_aeroport,aproape_de_tren. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | No | |
| total | No | Total cazări care corespund (poți pagina pentru restul) |
| results | No | Cazările care corespund, clasate (eșantion — vezi total). Fiecare are `rezolutie`. |
| per_page | No | |
| returned | No | Câte sunt în această pagină |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich behavioral context beyond annotations: explains return format with `rezolutie`, default ranking as recommended/trust, indicative pricing via `pret_de_la`, and that reservation is via get_accommodation. No contradictions with readOnlyHint/ idempotentHint.
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?
Front-loaded with core purpose, but somewhat verbose with repeated advice about tokeni vs teme. Given complexity, it is mostly concise, but could be tightened slightly.
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?
Complete for a complex tool with 9 parameters, nested objects, and output schema. Describes behavior for various input combinations, response structure including restrange, and fallbacks. No missing aspects.
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 coverage is 100%, but description adds substantial meaning: explains philosophy of tokeni vs nume vs teme, gives token examples, clarifies `where` as structured location with commune resolution, and `nume` only for property names—adding value beyond 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 finds accommodations anywhere in Romania by location, character, and future period. It distinguishes from siblings like get_accommodation and show_map, and explicitly mentions the source tria.ro.
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?
Provides explicit when-to-use guidance: all parameters optional, AI agents should use `tokeni` for character/experience, warns against using `nume` for facilities, explains alternatives like `where` vs `near`, and advises on clarifying when `restrange` is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accommodationGet AccommodationARead-onlyIdempotentInspect
Profilul complet al unei cazări de pe tria.ro (după slug), litoral sau național: semnale de caracter, împrejurimi, acces, arhetipuri, descriere/facilități, camere/dotări pe cameră, preț ORIENTATIV live pe 3 perioade-eșantion (pret, unde e disponibil — nu e disponibilitate garantată; rezervarea/verificarea finală pe site-ul partener), galerie foto limitată, linkuri/resurse hartă statică — plus rezolutie (cât de bogat e semnalul). Pentru DOCX/PDF fără egress folosește get_map(slug). Fără contact.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug-ul cazării, ex. "casa-anda-2e3cfc" (din URL-ul /cazare/{...}/{slug}) |
Output Schema
| Name | Required | Description |
|---|---|---|
| lat | No | |
| lng | No | |
| url | No | Pagina tria.ro a cazării |
| name | No | Numele cazării |
| pret | No | Preț ORIENTATIV live pe 3 perioade — doar la get_accommodation. Nu e disponibilitate garantată; verificarea finală + rezervarea se fac pe site-ul partener. Fără taxe/comisioane. |
| slug | No | Slug — pentru get_accommodation (detaliu) |
| teme | No | Teme de descoperire tria (cabane, retras, cu-piscina…) — naționale |
| type | No | Categoria brută internă |
| acces | No | Distanța până la cel mai apropiat (km), unde există — național |
| photo | No | Poză de copertă — în liste poate lipsi; la get_accommodation este cover-ul disponibil. |
| rooms | No | Camere/unități, doar la get_accommodation, compactate și limitate ca să nu umfle contextul. |
| stars | No | Stele (din sursa de conținut) |
| resort | No | Stațiunea de pe litoral |
| source | No | Mereu "tria.ro" |
| arhetip | No | Arhetipul zonei din tokenii de contrast ai catalogului; limbajul preferat pentru explicații și matching. |
| gallery | No | Galerie foto limitată — doar la get_accommodation, cu URL-uri publice/proxied tria unde există. |
| license | No | Licența datelor — atribuire necesară |
| origins | No | Originile vizitatorilor, pe județe |
| rezumat | No | Rezumat de caracter, într-o frază (originile vizitatorilor) |
| caracter | No | Caracterul zonei pe intenții de ședere (0–100, doar cele cu semnal) |
| category | No | Categorie normalizată: hotel/pensiune/vila/apartament/hostel/resort/camping |
| etichete | No | 1–2 etichete în limbaj natural, derivate din caracter |
| amenities | No | Facilități (doar la get_accommodation) |
| potrivire | No | Potrivire cu INTENȚIA ta (0–100) — cât de bine se aliniază cazarea cu tokenii/criteriile cerute. Apare DOAR când ai dat o intenție. NU e un scor/rating absolut al cazării (nu notăm cazări). |
| rezolutie | No | Provenance + încredere a semnalelor (mai bogat unde semnalul e fin, mai subțire la marginea litorală). Agentul îl CITEȘTE ca să calibreze încrederea; nu e parametru de request. |
| pret_de_la | No | Preț informativ general „de la”, unde există. Nu este disponibilitate și nu este ofertă de rezervare. |
| description | No | Descriere scurtă (doar la get_accommodation) |
| map_png_url | No | Harta statică PNG a cazării, publică HTTP — doar la get_accommodation și doar dacă ai egress. Pentru PDF/DOCX fără egress folosește get_map(slug). |
| map_svg_url | No | Harta statică SVG a cazării, publică HTTP — doar la get_accommodation și doar dacă ai egress. |
| map_png_resource | No | URI MCP resources/read pentru PNG: tria://map/{slug}.png. Nu toți clienții citesc template-uri; pe ChatGPT folosește get_map(slug). |
| map_svg_resource | No | URI MCP resources/read pentru SVG: tria://map/{slug}.svg. Nu toți clienții citesc template-uri; pe ChatGPT folosește get_map(slug). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable behavioral context: price is orientativ (not guaranteed), reservation is via partner site, and signal richness is indicated by rezolutie. 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 dense but each sentence adds specific detail. It is front-loaded with the main purpose and includes all necessary context without 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's parameters (only slug) and the complexity of the returned data, the description comprehensively lists all output categories. The output schema exists, but the description effectively conveys what the tool returns.
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 coverage is 100%, so baseline is 3. The description adds an example slug and explains it comes from the URL, adding semantic value beyond the 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 gets the full profile of an accommodation from tria.ro, listing specific data categories (e.g., semnale de caracter, preț ORIENTATIV). It distinguishes from sibling get_map by noting use for DOCX/PDF without egress.
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 recommends get_map for DOCX/PDF, providing an alternative. However, it does not explicitly state when not to use this tool or mention other siblings like find_accommodations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mapGet MapARead-onlyIdempotentInspect
Întoarce harta statică a unei cazări INLINE, ca string base64 în payload — folosește-l când nu poți citi resource-ul tria://map/... sau descărca map_png_url/map_svg_url (sandbox fără egress/DNS). Implicit PNG (raster, gata de inserat în DOCX/PDF). Slug-ul vine din get_accommodation (sau din URL). Bytes-ii sunt în content_base64 — decodează-i și salvează-i ca fișier (vezi mime_type/filename). Sursă: tria.ro.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug-ul cazării, ex. "hanul-rotbav-aa652e" (din get_accommodation / URL). |
Output Schema
| Name | Required | Description |
|---|---|---|
| width | No | Lățimea imaginii în pixeli. |
| height | No | Înălțimea imaginii în pixeli. |
| png_url | No | Link http către același PNG (dacă ai egress) — același conținut ca content_base64. |
| svg_url | No | Link http către varianta VECTOR SVG a aceleiași hărți (alt format decât payload-ul PNG; doar dacă ai egress). |
| filename | No | Nume de fișier sugerat, ex. hanul-rotbav-aa652e-map.png. |
| mime_type | No | Tipul conținutului — image/png (implicit) sau image/svg+xml (fallback). |
| png_resource | No | URI MCP al PNG-ului (tria://map/{slug}.png) — citibil prin resources/read de clienți care suportă template-uri. |
| svg_resource | No | URI MCP al variantei SVG (tria://map/{slug}.svg) — pentru clienți care fac resources/read. |
| content_base64 | No | Imaginea (PNG) codată base64 — decodează-o direct (fără fetch). Asta e fișierul, conform mime_type/filename. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral traits: output as base64 in `content_base64`, default PNG format, and instructions to decode and save as file. This goes beyond 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 moderately concise with multiple informative sentences. It is front-loaded with the core purpose and then elaborates on usage and output. Every sentence adds value, though it could be slightly more terse.
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's simplicity (one parameter, output schema exists), the description is complete: it explains output format, processing steps, and sources. It does not need to elaborate on return values as output schema covers that.
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 coverage is 100% with a clear description for the slug parameter. The description adds value by noting the slug comes from `get_accommodation` or the URL, and mentions default PNG output, enriching the parameter's context.
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 it returns a static map inline as a base64 string. It clearly differentiates from sibling tools by specifying when to use this tool (when sandbox restrictions prevent using tria:// resources or downloading URLs). The verb 'returns' and resource 'static map of an accommodation inline' are specific and actionable.
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 the use case: when one cannot read the resource `tria://map/...` or download `map_png_url`/`map_svg_url` due to sandbox without egress/DNS. This gives clear when-to-use and when-not-to-use guidance, referencing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_itinerary_mapShow Itinerary MapARead-onlyIdempotentInspect
Afișează o hartă interactivă de itinerariu, cu puncte fixe, scene/grupe (ex. zile/etape/zone), chips pentru scene, carousel și autoplay opțional. Refolosește harta tria; traseul este schematic (linie dreaptă între puncte), nu rutare pe drumuri. Sursă: tria.ro.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Linie schematică între puncte. | |
| title | No | Titlul hărții, ex. "Circuit 7 zile din Constanța". | |
| points | Yes | Punctele itinerariului. Max 40. | |
| scenes | No | Scene/grupe pentru chips și autoplay. Dacă lipsește, se creează o scenă cu toate punctele. Max 20. | |
| autoplay | No | Autoplay pe scene, nu pe puncte. | |
| subtitle | No | Subtitlu scurt, ex. "cazări retrase, natură, sate, apă". |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | No | |
| path | No | |
| title | No | |
| points | No | |
| scenes | No | |
| source | No | |
| autoplay | No | |
| subtitle | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that the map is reused from 'tria.ro' and the route is schematic, providing behavioral context beyond what annotations offer. 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 three concise sentences in Romanian, each adding essential information: purpose and features, route type and map source, and data source. No fluff 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?
Given the complexity of the tool (6 parameters, nested objects, output schema exists), the description covers key behavioral aspects (interactive, schematic route, source). It could mention constraints like max points (40) but those are in the schema. Overall, sufficient for an AI agent.
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 100%, so the input schema already documents all parameters thoroughly. The description provides high-level context (e.g., scenes, chips, autoplay) but does not add significant detail beyond the schema, which is expected at full coverage.
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 it displays an interactive itinerary map with fixed points, scenes, chips, carousel, and optional autoplay. It specifies the map source and distinguishes the route as schematic, not road routing, which differentiates it from sibling tools like 'show_map' and 'get_map'.
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 clarifies that the tool is for schematic routes (straight lines), not road routing, implying it should not be used for driving directions. It does not explicitly list alternatives or exclusions, but the context is clear enough for an AI agent to decide when to use or avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_mapShow MapARead-onlyIdempotentInspect
Afișează cazări pe o hartă INTERACTIVĂ — aceiași parametri de localizare/filtrare ca find_accommodations (where/near/nume/tokeni/criterii/teme/sort), region-routed. Widget MCP Apps când clientul suportă; altfel listă cu coordonate. Folosește-l când utilizatorul cere „pe hartă". (Harta statică per cazare e în get_accommodation → map_png_url/map_svg_url, iar pentru PDF/DOCX fără egress folosește get_map(slug).) Sursă: tria.ro.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | „Lângă mine" / în jurul unui punct. | |
| nume | No | DOAR nume de cazare/proprietate/brand. Nu folosi pentru facilități, experiențe, stil sau caracter; acelea merg în `tokeni`. | |
| page | No | Pagina | |
| sort | No | AVANSAT/legacy: o singură dimensiune de ranking. Pentru user intent folosește `tokeni`. | |
| teme | No | AVANSAT/legacy: filtru pe categorie (național), ex. ["cabane","cu-piscina"]. Pentru agenți AI preferă `tokeni`. | |
| limit | No | Câte cazări/pini (implicit 12, max 30) | |
| where | No | UNDE — locație structurată (județ/oraș/localitate/stațiune), OPȚIONAL. Reperele cunoscute (Colibița, Bâlea, Rânca…) se rezolvă la comuna care le conține. NU căutare după nume (aia e `nume`). Fără ea / nerecunoscut → național. | |
| tokeni | No | Tokeni publici de intenție/facilitate/experiență/stil, ex. ["ciubar"], ["lux"], ["spa"], ["piscina"], ["munte","liniste"]. | |
| criterii | No | AVANSAT/legacy: ranking pe caracter (media). Vocabular: popularitate,liniste,natura,munte,apa,plaja,family,gastro,vin_crame,crame,cultura_istorie,cultura,nightlife,business,relaxare,urbanitate,izolare,magnetism,turism,afluenta,afluenta_turistica,anvergura,farmec,dezirabilitate,animat,cafea,plimbare |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | No | |
| total | No | Total cazări care corespund (poți pagina pentru restul) |
| results | No | Cazări cu coordonate, pentru hartă (eșantion — vezi total). Fiecare are `rezolutie`. |
| per_page | No | |
| returned | No | Câte sunt în această pagină |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnly, idempotent, non-destructive. Description adds that output is interactive widget or list with coordinates if unsupported, and mentions region-routing and source. No contradictions.
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 focused sentences with additional detail in parentheses. Purpose first, then usage guidance, no wasted words.
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 9 parameters, nested objects, and existence of output schema, the description adequately covers purpose, usage, and differentiation. It relies on sibling tool for param details, which is acceptable.
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 covers all 9 parameters with descriptions. Description defers to find_accommodations for meaning, not adding new info. Baseline 3 is appropriate.
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 it displays accommodations on an interactive map, distinguishes from static map in get_accommodation and PDF map in get_map, and notes it uses same parameters as find_accommodations.
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?
Explicitly says to use when user requests 'pe hartă', and provides alternatives: static map via get_accommodation, PDF/DOCX via get_map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!