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.3/5 across 7 of 7 tools scored.
Each tool has a clear and distinct purpose: capabilities for metadata, explore_areas for zones, find_accommodations for listing accommodations, get_accommodation for details, get_map for static maps, show_itinerary_map for itineraries, and show_map for interactive maps. No overlap in functionality.
Most tools follow a verb_noun pattern (explore_areas, find_accommodations, get_accommodation, get_map, show_itinerary_map, show_map), but 'capabilities' is a standalone noun, breaking the pattern. Additionally, verbs vary (explore, find, get, show) without a single convention, though this is acceptable for distinguishing actions.
7 tools is well-scoped for a lodging intelligence server focused on discovery and mapping. Each tool covers a necessary aspect without overloading the interface, making it easy for agents to navigate.
The tool set covers core workflows: area exploration, accommodation search, detailed profiles, and multiple map views. Minor gaps exist, such as lack of price/availability (explicitly out of scope) and lack of comparison tools, but for the stated purpose it is fairly complete.
Available Tools
7 toolscapabilitiesCapabilitiesARead-onlyIdempotentInspect
Versiunea serverului MCP tria.ro, tool-urile publicate și VOCABULARUL complet, structurat: teme (filtre de descoperire pe 4 piloni: Cadru/Stil/Facilități/Atmosferă) și criterii (semnale de ranking = criterii/sort). 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, destructiveHint=false. The description adds value by detailing what specific information is returned (version, tools, vocabulary structure) and the organization of vocabulary axes, providing behavioral context beyond the 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 sentence that front-loads the core purpose and specifies structure (slugs, labels, pillars). It is compact but could be slightly more efficient; still, it earns its place.
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 no parameters and an output schema exists, the description comprehensively covers what the tool returns: server version, published tools, and fully structured vocabulary with organization. No gaps are apparent.
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?
With 0 parameters and 100% schema description coverage, the baseline is 3. The description does not need to add parameter info, but it does explain the structure of the returned vocabulary, which is extra 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 explicitly states the tool returns the server version, published tools list, and complete vocabulary (themes and criteria with slug and label), clearly distinguishing it from siblings like explore_areas or find_accommodations which deal with geographic or accommodation data.
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 as a discovery/metadata tool, but no explicit guidance on when to use versus alternatives or when not to use is provided. The context makes it clear it's for retrieving server info and vocabulary, but lacks explicit exclusion criteria.
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 după scor). where = locație structurată (rezolvată server-side), NU căutare după nume; query = căutarea după nume. Întoarce o listă clasată cu semnalele de caracter tria + scor; fiecare rezultat poartă rezolutie (litoral=identitate/bogat, național=ambient). NB: scorul e COMPOZIT (recenzii + magnetism de zonă), deci orașele urcă peste cazările retrase — pentru „cea mai bună pentru mine" clasează după un semnal de caracter (criterii: munte/liniste/family) sau rating. NU întoarce preț/disponibilitate. La query LARG (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. | |
| page | No | Pagina (implicit 1) — total arată câte corespund | |
| sort | No | O singură dimensiune de ranking când nu dai criterii: scor (implicit) | popularitate | rating | … (vezi criterii). criterii îl suprascrie. | |
| teme | No | FILTRU pe categorie (taxonomia de descoperire, NAȚIONAL), ex. ["cabane","cu-piscina","retras"]. Diferit de criterii (acela e ranking). | |
| limit | No | Câte pe pagină (implicit 10, max 30) | |
| query | No | Potrivire după NUME, ex. "Vila Maria". Diferit de where. | |
| 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. Rezolvat server-side; NU e căutare după nume (aia e `query`). Dacă lipsește SAU nu e recunoscut (ex. "România") → caut NAȚIONAL, nu fac fuzzy pe text. | |
| criterii | No | RANKING pe caracter (media semnalelor), ex. ["liniste","munte","family"]. Vocabular: scor,popularitate,rating,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. Litoral adaugă plaja/anvergura/afluenta/farmec. |
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?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds valuable behavioral details: scoring composition, lack of price/availability, restrange behavior for broad queries, and that results include tria character signals. 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 front-loaded with purpose and uses dense, informative sentences. While it could be more structured with bullet points, every sentence adds value and avoids redundancy. Slightly verbose but efficient.
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 complexity (8 optional parameters, nested objects, output schema), the description is highly complete. It explains restrange clarification, scoring, parameter interactions, and the absence of price/availability. The output schema covers return values, so no gaps.
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 description adds significant meaning beyond the schema by distinguishing where (structured location, server-side resolved) from query (name search), explaining criterii as ranking vs teme as filtering, and providing vocabularies for criterii. Schema has 100% coverage but description enriches 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 clearly states the tool finds accommodations anywhere in Romania based on location, character, and future period. It distinguishes from siblings like show_map and get_accommodation by specifying that map display is handled elsewhere and that this tool returns a ranked list without price/availability.
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 context on when to use this tool vs show_map and implies alternatives for price/availability. It also advises when to offer clarification (restrange) for broad queries. However, it does not explicitly exclude usage for other sibling tools like get_accommodation or show_itinerary_map.
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, sentiment oaspeți, împrejurimi, acces, teme, 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ă preț/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 |
| scor | No | Scorul tria (0–100) — recomandarea de caracter, penalizată doar de recenzii slabe. Folosește-l la clasare. |
| 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ă — doar în show_accommodations_map (harta). Nu apare la search/top/get_accommodation. |
| stars | No | Stele (din sursa de conținut) |
| resort | No | Stațiunea de pe litoral |
| source | No | Mereu "tria.ro" |
| gallery | No | Galerie foto — nu e expusă pe MCP (doar pe web). |
| 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) |
| rezolutie | No | Provenance + încredere a semnalelor (litoral=bogat/identitate, național=ambient). Agentul îl CITEȘTE ca să calibreze încrederea; nu e parametru de request. |
| 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. |
| sentiment_zona | No | Sentiment ZONĂ: caracterul zonei (fără recenzii). Comun cazărilor vecine din aceeași zonă — de aceea se repetă. |
| 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). |
| sentiment_cazare | No | Sentiment CAZARE: verdictul din recenziile oaspeților proprietății (numărul de recenzii nu e expus). Specific cazării — diferă între proprietăți. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's added value is limited. It adds context about returned fields and resolution but does not disclose behavioral traits beyond the safe and idempotent nature.
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 one sentence plus a concise usage note and exclusion statement. Zero waste; front-loaded with the main purpose.
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 only one required parameter and an output schema exists, the description is complete. It covers what the tool does, what it includes/excludes, and provides alternative tool guidance.
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 100% coverage with a description for the slug parameter. The description does not add additional semantic meaning beyond repeating 'slug'. 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 returns a complete accommodation profile listing specific data fields and distinguishes it from get_map. The verb 'get' and resource 'accommodation' 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?
The description provides explicit guidance: for DOCX/PDF without egress, use get_map(slug) instead. It also notes that price/contact are not included, clarifying when not to use. However, it does not compare with find_accommodations or explore_areas.
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/query/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. | |
| page | No | Pagina | |
| sort | No | O singură dimensiune de ranking (criterii o suprascrie). | |
| teme | No | Filtru pe categorie (național), ex. ["cabane","cu-piscina"]. | |
| limit | No | Câte cazări/pini (implicit 12, max 30) | |
| query | No | Potrivire după NUME. | |
| 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 `query`). Fără ea / nerecunoscut → național. | |
| criterii | No | Ranking pe caracter (media). Vocabular: scor,popularitate,rating,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 indicate read-only, idempotent, non-destructive. Description adds that it returns an interactive widget or a list with coordinates, and is region-routed. 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?
Description is moderately concise, front-loaded with purpose, then parameter context, then alternatives. Could be slightly tighter but effective.
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 schema coverage and presence of output schema, the description is complete: it covers purpose, when to use, parameters, and distinguishes from siblings.
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 descriptions in Romanian. Description restates that parameters are same as find_accommodations but adds no significant new meaning 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 displays accommodations on an interactive map, using the same parameters as find_accommodations. It distinguishes itself from siblings like get_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 says to use it when the user asks 'on map'. Clearly differentiates from static maps in get_accommodation and PDF/DOCX maps via get_map(slug). Provides excellent alternative guidance.
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!