Romanian lodging character intelligence: calm, nature, culture, stays, itinerary maps. Read-only.
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.
Average 4.3/5 across 8 of 8 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose: capability discovery, area exploration, accommodation search, accommodation detail, concierge brief, static map, itinerary map, and interactive map. Even though find_accommodations and show_map share parameters, they serve different output formats (list vs map). The detailed descriptions ensure no two tools appear to do the same thing.
Tool names mostly follow a consistent verb_noun pattern (explore_areas, find_accommodations, get_accommodation, get_concierge_brief, get_map, show_itinerary_map, show_map). The only deviation is 'capabilities', which is a noun rather than a verb; the rest are predictable and consistent.
With 8 tools, the server is well-scoped for its purpose of lodging intelligence. Each tool provides a distinct function: discovery, details, maps, itinerary, and concierge support, without unnecessary bloat. The count is within the ideal 3-15 range.
The toolset covers the core read-only workflows for a lodging intelligence server: searching accommodations (find_accommodations), getting detailed profiles (get_accommodation), exploring areas (explore_areas), mapping (show_map, get_map, show_itinerary_map), and concierge assistance (get_concierge_brief). The capabilities tool exposes the vocabulary, enabling correct token usage. No obvious dead ends or missing operations for the stated purpose.
capabilitiesCapabilitiesAVersiunea 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 | |||
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds behavioral context about the content structure (three vocabulary axes, reserved items) and the guarantee of slug+label format, which goes beyond the structured metadata.
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 a single, dense sentence that packs server info, tool list, vocabulary structure, and purpose. It's efficient but slightly heavy with Romanian administrative phrasing; still, no redundant filler.
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?
With rich annotations, an output schema, and zero parameters, the description fully covers what the tool does and how it is structured. It even notes reserved content, making it complete for agent decision-making.
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, so the baseline is 4. The description does not need to explain parameters, but it documents the meaning of the vocabulary axes, which is the closest analog to parameter semantics and adds value.
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 provides server version, published tools, and a structured vocabulary (tokeni, teme, criterii) with slugs and labels. This distinguishes it from sibling domain tools like find_accommodations or get_map, making its purpose unambiguous and specific.
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 implies usage by calling the vocabulary the 'standard interface' and saying it allows users to 'ask exactly without guessing or confusing axes.' This suggests consulting this tool before using other tools, but it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_areasExplore AreasAClasează 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). Dacă dai where, tool-ul rămâne în zona părinte rezolvată și nu întoarce județe naționale. Ex.: județele cele mai montane, localitățile cele mai verzi din Cluj, stațiunile cele mai potrivite pentru familie. Sursă: tria.ro.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | O dimensiune de ranking: liniste, natura, verde, parcuri, arii_protejate, munte, schi, apa, family, gastro, vin_crame, crame, cultura_istorie, cultura, nightlife, business, relaxare, magnetism, turism, urbanitate, viata-de-seara, viata_de_seara (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 | Județul părinte pentru scope=localitate, ex. "Brașov"; acceptă și o localitate/stațiune, caz în care se folosește județul ei. Dacă `scope=judet` și dai `where`, tool-ul auto-corectează la localitățile din județul/locul rezolvat. | |
| criterii | No | Ranking compozit (media) — doar pentru statiune. |
| Name | Required | Description |
|---|---|---|
| areas | No | Zonele clasate |
| judet | No | Județul părinte (doar scope=localitate) |
| scope | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral details: when `where` is provided, the tool stays in the resolved parent area and does not return national counties, plus auto-correction behavior for `scope=judet`.
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 compact, front-loaded with the main purpose, and contains no wasted words. It packs in scope options, `where` behavior, examples, and data source in a single efficient paragraph.
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?
The description covers all key behavioral aspects: scope granularity, use of `where` to constrain results, ranking via `sort` or `criterii`, and provides multiple examples that illustrate the tool's range. With an output schema present, return structure need not be explained.
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 parameters are already well-documented. The description adds example use cases and clarifies the `sort` vs `criterii` ranking modes, but these are largely redundant with the schema's own 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 verb 'Clasează' (ranks) with resource 'ZONE' and explicit exclusion 'nu cazări' clearly distinguishes from accommodation siblings. It identifies the tool's purpose as answering 'where to go' by area character, which is specific and unambiguous.
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?
It gives clear context for when to use: ranking areas by character with scope options (judet, localitate, statiune) and illustrative examples (mountainous counties, green localities, family resorts). It implicitly excludes accommodation searches but does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_accommodationsFind AccommodationsAGă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); dacă locația nu se rezolvă, tool-ul întoarce eroare în loc de top național. 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", "verde", "parcuri", "arii-protejate", "podgorie", "gastronomie", "viata-de-seara", "liniste-seara", "cultura", "urban", "balnear", "vibrant", "sezon-vara", "sezon-iarna", "activ-noaptea", "sezonier", "activ-tot-anul", "weekend", "cu-piscina", "cu-spa", "cu-restaurant", "cabane", "lux", "spa", "ciubar", "drumetii", "ciclism", "atv", "delta", "echitatie", "schi", "degustari-vin", "foc-tabara", "piscina", "copii", "evenimente"). Pentru negații pe tokenii reali de caracter, adaugă minus la tokenul public, ex. ["urban","animat","cultura-"] pentru urban și animat, dar fără tokenul cultural din profilul zonei. 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" (actualizat pentru 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; acceptă și forma calificată "localitate, județ" (ex. "Filiași, Dolj"). 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. Dacă locația nu se rezolvă, primești eroare; pentru top național omite `where`. 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"]. Acceptă semn pe tokenii reali de caracter: `cultura+` = cere tokenul, `cultura-`/`-cultura`/`fara cultura` = exclude cazările care poartă tokenul intern de caracter. Negația nu se aplică facilităților/experiențelor. 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: liniste,natura,munte,arii_protejate,schi,apa,family,gastro,vin_crame,crame,cultura_istorie,cultura,nightlife,business,relaxare,urbanitate,izolare,magnetism,turism,afluenta_turistica,farmec,dezirabilitate,aproape_de_mare,aproape_de_aeroport,aproape_de_tren. |
| 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ă |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context beyond annotations: error behavior when `where` doesn't resolve, default ranking as "recomandate/încredere", price qualifier "ORIENTATIV... NU e disponibilitate garantată", and the `restrange` response field for broad searches. 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 long but densely packed with necessary information for a 9-parameter tool. It is front-loaded with purpose and then organized by usage themes. However, it is a single large paragraph that could benefit from bullet points or subheadings; while every sentence earns its place, the structure makes scanning harder than ideal.
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 high complexity (9 params, nested objects) and an existing output schema, the description covers everything needed: parameter selection rules, error conditions, ranking semantics, clarifications, and integration with sibling tools (get_accommodation, show_map). It even references capabilities().vocabular.tokeni for additional vocabulary. No gaps found.
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 the description adds substantial semantic richness: `tokeni` includes an extensive vocabulary list, negation syntax (`cultura+`/`cultura-`), and guidance on what not to use it for. `where` explains structured location resolution and known landmarks mapping to communes. `nume` restricts to property names. Each parameter gains operational meaning beyond the raw 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 opens with a clear, specific verb and resource: "Găsește cazări ORIUNDE în România... după LOC, CARACTER și PERIOADĂ." It distinguishes from siblings by focusing on discovery across Romania versus get_accommodation (single property details) and explore_areas (area exploration). The scope (litoral/țară) and filtering dimensions are explicit.
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: for any user intent/facility/style, use `tokeni`, not `nume`/`teme`/`criterii`. It names alternatives and exclusions (e.g., `where` for location, `nume` only for property names, `near` for point-based search). States when to get final verification: "rezervarea/verificarea finală pe get_accommodation → site-ul partener." Also instructs on presenting `restrange` as clarification but not being obligated to restrict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accommodationGet AccommodationAProfilul 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}) |
| 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 | Etichetă publică de preț informativ în forma „de la X lei”, fără sufix. 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly and idempotent. The description adds crucial behavioral context: the price is 'ORIENTATIV live' and not guaranteed availability, booking is finalized on the partner site, the photo gallery is limited, and a 'rezolutie' field indicates signal richness. It also explicitly states 'Fără contact,' which is not inferable from 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 a single, dense sentence that front-loads the core purpose before listing content categories and caveats. It is information-dense but somewhat run-on; however, all included details serve a purpose, so it earns a 4 rather than a lower score.
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?
The description provides a comprehensive overview of the tool's output facets, including price limitations and an alternative tool for map-related tasks. Given the presence of an output schema, it does not need to detail return structures, but it covers the main user-facing caveats. It lacks details on error handling or exact output formatting, but overall is sufficiently complete.
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 input schema already documents the single required 'slug' parameter with an example and format, achieving 100% schema coverage. The description merely restates 'după slug' without adding new syntax or format details, so it falls to the baseline of 3 for parameter semantics.
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 'Profilul complet al unei cazări de pe tria.ro (după slug)' which clearly defines the tool's function as retrieving a complete accommodation profile by slug. It enumerates specific data categories (character signals, surroundings, access, archetypes, description/facilities, rooms, price, gallery, map links, resolution), distinguishing it from sibling tools like find_accommodations or 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 provides explicit alternative guidance: 'Pentru DOCX/PDF fără egress folosește get_map(slug)' and notes 'Fără contact' as a limitation. However, it does not explicitly differentiate when to use this tool versus other siblings like find_accommodations for searching, so guidance is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_concierge_briefGet Concierge BriefABrief deterministic pentru AI concierge al unei cazări: fapte publice, diferențiatori, întrebări sugerate, guardrails și CTA-uri permise. Nu consumă LLM, nu confirmă disponibilitate/preț final și nu expune contact direct; agentul folosește brief-ul ca să răspundă despre proprietate și zonă fără să inventeze.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | free | pro. În local/prototip schimbă doar nivelul de detaliu și CTA-urile permise; nu activează billing. | |
| slug | Yes | Slug-ul cazării, ex. "gramofon-inn-f28a36" | |
| intrebare | No | Întrebarea turistului; opțional. Tool-ul o clasifică simplu și întoarce un cadru de răspuns. |
| Name | Required | Description |
|---|---|---|
| mode | No | free | pro |
| facts | No | |
| source | No | |
| license | No | |
| property | No | |
| question | No | |
| concierge | No | |
| guardrails | No | |
| missing_profile_data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: no LLM consumption, no availability/price confirmation, no direct contact, and deterministic results. This goes beyond the annotations and aligns with them, with 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 a single, well-structured sentence that efficiently packs purpose, contents, and limitations without filler. It is front-loaded with the tool's role and is easy to scan for an agent.
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?
With 3 parameters and an output schema present, the description is sufficiently complete. It explains the tool's role, contents, deterministic nature, and limitations, giving the agent all needed context for correct invocation.
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 provides full descriptions for all three parameters (100% coverage). The description adds minimal parameter-specific detail beyond what the schema states; it mentions the 'intrebare' parameter contextually but does not introduce new syntax or format information.
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 defines the tool as a deterministic concierge brief for accommodations, listing its contents (public facts, differentiators, suggested questions, guardrails, and allowed CTAs). It distinguishes itself from sibling tools like get_accommodation and find_accommodations by focusing on AI concierge Q&A support rather than searching or mapping.
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 states the agent uses the brief to answer about the property and area without inventing, establishing a clear usage context. It also lists exclusions (does not confirm availability/final price, no direct contact), helping decide when not to use it, though it doesn't explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mapGet MapAÎ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). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral context: returns base64, implicit PNG, decoding instructions, and that it works in restricted environments. 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 concise for the information conveyed. It front-loads the core purpose and includes necessary details like decoding. Every sentence adds value, though it could be slightly tighter.
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 an output schema (not shown but indicated), the description covers behavior, use case, preconditions (slug source), and decoding. For a single-parameter tool, this is complete.
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 baseline is 3. The description adds value by providing an example format (hanul-rotbav-aa652e) and explicitly linking the slug to get_accommodation/URL.
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 returns a static map of an accommodation as a base64 string. It specifies the use case (inline retrieval when resource URLs are inaccessible) and the format (implicit PNG). This distinguishes it from siblings like show_map and show_itinerary_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?
Explicitly states when to use: when you cannot read the tria://map/... resource or download map_png_url/map_svg_url due to sandbox restrictions. It also mentions the slug comes from get_accommodation or URL. No explicit when-not-to-use, but the context is clear.
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 MapAAfiș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ă". |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| path | No | |
| title | No | |
| points | No | |
| scenes | No | |
| source | No | |
| autoplay | No | |
| subtitle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds useful behavioral context: it reuses the tria map, shows schematic routes (straight lines) instead of road routing, and attributes the 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?
The description is concise, two sentences front-loading key capabilities. While it could be structured with bullet points, the current format is efficient and avoids 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?
The description covers core functionality but omits constraints like maximum number of points (40) and scenes (20), which are present in the schema. Given the complexity (nested objects, output schema exists), the description is adequate but could mention these limits to improve completeness.
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 detailed descriptions for all parameters. The tool description mentions features (chips, carousel, autoplay) but does not add significant semantic value beyond what the schema already provides. 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 the tool displays an interactive itinerary map with specific features (fixed points, scenes, chips, carousel, optional autoplay). It distinctively positions this tool against show_map by emphasizing itinerary-specific functionality and non-road routing.
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 no guidance on when to use this tool versus sibling tools like show_map or get_map. It does not mention prerequisites, exclusion criteria, or alternative scenarios. For an AI agent, this could lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_mapShow MapAAfiș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), acceptă și "localitate, județ" (ex. "Filiași, Dolj"), 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 → național; nerecunoscut → eroare. | |
| tokeni | No | Tokeni publici de intenție/facilitate/experiență/stil, ex. ["ciubar"], ["lux"], ["spa"], ["piscina"], ["munte","liniste"]. Pe tokenii reali de caracter cu negabil=true în capabilities(), acceptă minus: ["urban","animat","cultura-"]. | |
| criterii | No | AVANSAT/legacy: ranking pe caracter (media). Vocabular: liniste,natura,munte,arii_protejate,schi,apa,family,gastro,vin_crame,crame,cultura_istorie,cultura,nightlife,business,relaxare,urbanitate,izolare,magnetism,turism,afluenta_turistica,farmec,dezirabilitate,aproape_de_mare,aproape_de_aeroport,aproape_de_tren |
| 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ă |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only, idempotent, non-destructive operation. The description adds valuable behavioral context: the tool renders an interactive map widget when the client supports it, otherwise falls back to a list with coordinates, and is region-routed. This goes beyond the structured 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 a single dense sentence that front-loads the core purpose and packs in disambiguation with siblings and fallback behavior. While a bit long, every clause earns its place; the source attribution 'Sursă: tria.ro' is minor but not harmful.
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?
With an output schema present, the description doesn't need to explain return values. It covers purpose, usage timing, sibling alternatives, and interactive-vs-list fallback behavior. It is complete enough for a tool with 9 parameters and nested objects, though 'region-routed' is left slightly unclear.
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%, with detailed per-parameter descriptions. The tool description only lists the parameter names (where/near/nume/tokeni/criterii/teme/sort) without adding new meaning beyond the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.
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 'Afișează cazări pe o hartă INTERACTIVĂ' (displays accommodations on an interactive map), with a specific verb and resource. It distinguishes itself from siblings by referencing find_accommodations (same filtering parameters), get_accommodation (static map URLs), and get_map (for PDF/DOCX 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?
Explicit when-to-use guidance is provided: 'Folosește-l când utilizatorul cere „pe hartă”'. It also gives when-not-to-use by pointing to alternatives: static map per accommodation in get_accommodation, and get_map(slug) for PDF/DOCX without egress. This clearly steers the agent to the right sibling.
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.
No comments yet. Be the first to start the discussion!
