Tripuck
Server Details
Tripuck — Flight Meta-Search & Meeting Point
- 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 5 of 5 tools scored.
Each tool has a distinct purpose: cheapest_dates for monthly price overview, find_meeting_point for multi-origin meeting, flight_details for specific flight info, popular_routes for destination inspiration, search_flights for general search. No overlap or ambiguity.
All names use snake_case and are descriptive, but there is a mix of starting with an adjective (cheapest_dates, popular_routes) and verb (find_meeting_point, search_flights) or noun (flight_details). Slight inconsistency, but still clear and predictable.
5 tools is well-scoped for a flight search and comparison server. It covers search, cheapest dates, popular routes, meeting point, and flight details without being excessive or insufficient.
The tool set covers the main tasks: searching flights, finding cheapest days, exploring popular routes, getting detailed flight info, and coordinating multi-origin trips. No obvious gaps for the server's domain.
Available Tools
7 toolscheapest_datesTripuck Cheapest DatesARead-onlyIdempotentInspect
Tripuck price calendar — for a given route, returns the cheapest daily price across a full month. Use this when the user shows date flexibility: "when is the cheapest day to fly IST-AYT in April?", "hangi gün daha ucuz?", "أرخص يوم للسفر", "günstigste Tage für...". Use when the user asks about cheap days, flexible travel windows, or month-level price overviews. The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Target month in YYYY-MM. If omitted, the current month is used. | |
| market | No | Market / language code — controls pricing source and widget language. User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language. | |
| oneWay | No | One-way search. If false, round-trip prices are returned. | |
| origin | Yes | Departure IATA code. | |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| destination | Yes | Arrival IATA code. | |
| tripDuration | No | Trip length in days for round-trip (used when oneWay=false). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnly/idempotent/destructive annotations, the description adds that the tool returns widget UI and text in the user's language, and that the LLM must infer the locale. This provides useful behavioral context that annotations alone do not cover.
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 well-structured with two paragraphs. The first sentence defines the core function, followed by examples and parameter guidance. It could be slightly more concise but remains clear and 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 parameter count (7), complete schema descriptions, and annotations, the description provides sufficient context for an agent to select and invoke the tool correctly. It lacks output details but is adequate for this tool's purpose.
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 value by explaining the locale inference requirement and default currency behavior, which are not fully captured by the 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 returns cheapest daily prices across a full month for a given route. It distinguishes from siblings like search_flights by focusing on date flexibility, and includes multilingual examples that reinforce the purpose.
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 says to use when the user shows date flexibility, providing clear examples. It could be more precise about when not to use (e.g., for specific dates), but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_meeting_pointTripuck Meeting PointARead-onlyIdempotentInspect
Tripuck Meeting Point — finds the cheapest and fairest common destination for 2-5 people traveling from different cities. Example: "I'm in Istanbul, my friend is in Berlin, one is in Dubai — where should we meet?", "İstanbul, Berlin, Dubai nerede buluşalım?", "نحن في مدن مختلفة، أين نلتقي؟". Runs multi-city optimization and computes a fairness score across the group. Use when the user asks to coordinate a trip across multiple origins and needs a shared destination. The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly. | |
| period | No | Period: "year", "season", "month" or explicit "YYYY-MM". | season |
| sortBy | No | 'cheapest' = minimum total cost, 'fairest' = most balanced cost across travellers (Tripuck USP), 'least-transfers' = fewest layovers. | cheapest |
| origins | Yes | List of origin IATA codes (2-5 cities). Example: ["IST","BER","DXB"] for three friends flying from Istanbul, Berlin and Dubai. | |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| directOnly | No | Consider only non-stop routes. | |
| returnDate | No | Specific return date (optional), YYYY-MM-DD. | |
| departureDate | No | Specific departure date (optional), YYYY-MM-DD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds that it runs multi-city optimization, computes fairness score, infers language, and localizes UI text and currency defaults, providing full behavioral context.
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?
Well-structured with clear definition, examples, and behavioral details. Slightly lengthy but every sentence adds value.
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 8 parameters and no output schema, the description explains the tool's purpose, input requirements, and behavioral details well. Missing explicit output format but mentions widget UI and text response.
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 8 parameters. The description reinforces locale inference and currency defaults but does not add significant new semantics 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 it finds the cheapest and fairest common destination for 2-5 people from different cities, with examples. It distinctly differs from sibling tools like search_flights or cheapest_dates, which handle single-origin or date queries.
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 'Use when the user asks to coordinate a trip across multiple origins and needs a shared destination.' No explicit when-not-to-use, but sibling differentiation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flight_detailsTripuck Flight DetailsARead-onlyIdempotentInspect
Detailed information for a specific Tripuck flight ID: segments, layovers, baggage allowance, fare rules, refund/change conditions, operating carrier. Use for follow-up questions after search_flights: "what is the baggage allowance on this flight?", "bu uçuşta aktarma süresi nedir?", "كم الأمتعة المسموحة؟". The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Adult passengers. | |
| locale | No | User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language. | |
| origin | No | Departure IATA code of this flight (same as the prior `search_flights` `origin`). Pass it so the "open on Tripuck" link works. | |
| infants | No | Infant passengers. | |
| children | No | Child passengers. | |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| flightId | Yes | Tripuck flight ID — from `flight.id` in a prior `search_flights` response. | |
| searchKey | No | `searchKey` from a prior `search_flights` response (required to retrieve async search state). | |
| cabinClass | No | Cabin class. | |
| returnDate | No | Return date YYYY-MM-DD if the prior search was round-trip. | |
| destination | No | Arrival IATA code of this flight (same as the prior `search_flights` `destination`). | |
| departureDate | No | Departure date YYYY-MM-DD of this flight (same as the prior `search_flights` `departureDate`). |
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. Description adds that the response is localized based on locale and currency defaults are chosen from locale. This goes beyond annotations, so score 4.
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?
Three well-structured sentences: what the tool does, when to use with examples, and critical usage rules. 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 12 parameters, all well-documented in schema, the description covers usage context thoroughly. No output schema, but description indicates localized text response and widget UI. Nearly 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 each parameter has a description. The description adds extra context for locale (must infer from conversation) and currency (default from locale). This adds 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 provides detailed information for a specific flight ID, listing segments, layovers, baggage, fare rules, and conditions. It distinguishes itself from sibling tools like search_flights by focusing on follow-up details for a specific flight.
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 to use after search_flights for follow-up questions, gives example questions in multiple languages, and instructs the LLM to infer user language and pass locale. No ambiguity about when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
popular_routesTripuck Popular RoutesARead-onlyIdempotentInspect
Tripuck's Explore service — most popular destinations with current prices from a given origin city, aggregated from live flight inventory data. Use for inspiration-style queries where the destination is unknown: "where can I fly from Istanbul?", "İstanbul'dan nereye?", "وجهات شعبية من دبي", "populäre Reiseziele ab München". The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language. | |
| oneWay | No | One-way search. | |
| origin | Yes | Departure IATA code. | |
| period | No | Period: "year" (12 months), "season" (3 months), "month", or explicit "YYYY-MM". | season |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| directOnly | No | Return only non-stop routes. | |
| maxTripDays | No | ||
| minTripDays | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating data is aggregated from live flight inventory and that widget UI and response text are returned in the user's language. It also explains default currency selection. Annotations already indicate read-only and idempotent, and the description does not contradict 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 front-loaded with the core purpose and usage examples, followed by parameter details. It is comprehensive but could be more concise; every sentence adds value, though some parameter explanations could be shorter.
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 8 parameters, 1 required, and no output schema, the description covers most aspects adequately. Parameters like maxTripDays and minTripDays are not explained, but they are relatively self-explanatory. The lack of output schema makes the description's completeness sufficient for proper tool usage.
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 meaning beyond the input schema by emphasizing that locale must be inferred from conversation and listing supported languages. It also clarifies currency defaults per locale and explains period options. With 75% schema coverage, the description compensates well for the remaining gaps.
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 lists popular destinations with current prices from an origin city for inspiration-style queries. It distinguishes itself from sibling tools like search_flights or cheapest_dates by focusing on unknown destinations, making the purpose specific and unique.
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 to use for inspiration queries where destination is unknown, with multi-language examples. It also instructs the LLM to infer language and pass it as the locale parameter. However, it does not explicitly state when not to use or suggest alternative tools for known destinations, slightly lowering the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_esimTripuck eSIM Data PlansARead-onlyIdempotentInspect
Tripuck eSIM search — prepaid travel data plans (eSIM) for a destination country, compared across multiple providers. Use this when the user asks about mobile data, internet, SIM or eSIM for a trip, e.g. "eSIM for Japan", "data plan for my trip to the US", "internet in Dubai", "Japonya için eSIM", "خطة بيانات لدبي", "Datentarif für die Türkei". Input: a destination country (the LLM maps the place to its ISO country code), with optional minimum data (GB), validity days and sorting. Returns available packages with data amount, validity, coverage and price, each deep-linking to Tripuck.com for purchase. The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language. | |
| sortBy | No | Result ordering: "price_asc" cheapest first (default), "price_desc" most expensive first, "data_desc" largest data first, "validity_desc" longest validity first. | price_asc |
| country | Yes | Destination country as a 2-letter ISO 3166-1 alpha-2 code. The LLM MUST translate the country/city the user mentions to its ISO code (e.g. "Japan" → JP, "Türkiye" → TR, "the US" → US, "Dubai" → AE, "Paris" → FR). | |
| maxDays | No | Maximum validity period in days. | |
| minDays | No | Minimum validity period in days. | |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| minDataGb | No | Minimum data allowance in GB (e.g. 5 for "at least 5 GB"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint true, destructiveHint false. Description adds: returns packages with details and deep-links; locale affects UI and response language; default currency logic. No contradictions. Adds value beyond 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?
Description is somewhat long but well-structured with examples and instructions. Front-loads purpose. Could be more concise, but every sentence adds value.
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 7 parameters, 1 required, no output schema, description explains return values (packages with data, validity, coverage, price, deep-links). Covers locale/currency defaults. Adequate for a search tool, though error handling and pagination not mentioned.
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% (all parameters have descriptions). Description adds meaning: explains locale inference, currency defaults, country mapping from user input. Provides examples for sortBy. Adds 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?
Description clearly states it searches prepaid travel data plans (eSIM) for a destination country, compared across providers. Verb 'search' with resource 'eSIM data plans' is specific. Distinguishes from siblings as no other tool covers eSIM.
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 example queries that should trigger this tool (e.g., 'eSIM for Japan'). Instructs LLM to map place to ISO code and infer language for locale. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_flightsSearch Flights on TripuckARead-onlyInspect
Tripuck flight meta-search — real-time fare comparison across 700+ airlines and 50+ online travel agencies. Use this tool when the user asks for flight prices, e.g. "Istanbul to Antalya tomorrow", "cheapest Paris ticket", "yarın Londra'ya uçuş", "رحلة إلى دبي غداً", "Flüge nach Berlin". Inputs: IATA codes (IST, AYT, LHR...) and dates in YYYY-MM-DD. Results deep-link to Tripuck.com for detailed review and booking. The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Adult passengers (12+ years). | |
| locale | No | User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language. | |
| origin | Yes | Departure IATA code (3 letters). Examples: "IST" Istanbul, "AYT" Antalya, "LHR" London Heathrow. | |
| infants | No | Infant passengers (0-2 years). | |
| children | No | Child passengers (2-11 years). | |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| cabinClass | No | Cabin class. | economy |
| returnDate | No | Return date in YYYY-MM-DD — only for round-trip. Must be today or future, and after `departureDate`. | |
| destination | Yes | Arrival IATA code (3 letters). The LLM should translate city names to IATA codes. | |
| departureDate | Yes | Departure date in YYYY-MM-DD. MUST be today or in the future. IMPORTANT: do NOT default the year to your training-time "current year" — use the actual upcoming travel date the user intends; if the user does not specify a year, infer it from the conversation date context (often the current calendar year or next year). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds behavioral context such as real-time fare comparison, deep-linking to Tripuck.com, locale inference, and currency defaults. This goes beyond the annotations without contradicting them, but the description could still mention rate limits or caching behavior.
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 appropriately sized, with about 4 sentences. It is front-loaded with the core purpose and includes examples. Each sentence adds value, though it could be slightly more concise by combining some details.
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 10 parameters (3 required) and no output schema, the description covers essential behavioral details like locale/currency defaults and deep-linking. It does not explain return format or error handling, but for a search tool with rich schema annotations, the context is largely 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 baseline is 3. The description adds significant value by clarifying locale inference (LLM must infer from conversation), currency defaults based on locale, and important date handling guidance (do not default year to training data). This meaningfully enhances parameter understanding.
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's a flight meta-search tool for real-time fare comparison across many airlines and OTAs. It gives examples of user queries and distinguishes itself from siblings like cheapest_dates and flight_details by focusing on price search, but does not explicitly name alternatives.
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 says 'Use this tool when the user asks for flight prices' and provides query examples, which is clear context. However, it does not mention when not to use it or explicitly contrast with sibling tools, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hotelsSearch Hotels on TripuckARead-onlyIdempotentInspect
Tripuck hotel search — real-time availability and prices for a city on given dates. Use this tool whenever the user asks about hotels, accommodation, or places to stay, e.g. "hotels in Antalya next weekend", "4-star hotel in Istanbul near Taksim", "İstanbul'da otel", "فندق في دبي", "Hotel in Berlin". Inputs: a city name plus optional check-in / check-out dates (YYYY-MM-DD) and guest counts. Supports structured filtering by minimum star rating, minimum guest-review score, and sorting. Returns live hotel options with price, star rating, review score and a thumbnail, each deep-linking to Tripuck.com for full details and booking. The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Destination city or area name, e.g. "Antalya", "Istanbul", "Dubai", "Berlin". A free-text place name (not a code); it is matched to a Tripuck destination. | |
| adults | No | Number of adult guests (default 2). | |
| locale | No | User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language. | |
| sortBy | No | Result ordering: "recommended" (default), "price_asc" cheapest first, "price_desc" most expensive first, "star_desc" highest star first, "review_score" best-rated first. When the user asks to narrow/sort, re-call with this set. | recommended |
| checkIn | No | Check-in date in YYYY-MM-DD. MUST be today or in the future. If omitted, defaults to one week from today. Do NOT default the year to your training-time current year — use the actual upcoming date the user intends. | |
| checkOut | No | Check-out date in YYYY-MM-DD, after check-in. If omitted, defaults to the night after check-in. | |
| children | No | Number of child guests (default 0). | |
| currency | No | ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS). | |
| minStarRating | No | Minimum hotel star rating (1-5). Use when the user asks for e.g. "4-star or above". | |
| minReviewScore | No | Minimum guest review score (0-10). Use when the user wants "highly rated" hotels. |
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. Description adds non-obvious behaviors: language inference for UI text, currency defaults from locale, real-time data retrieval with deep links. 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?
Well-structured: purpose first, usage examples, then parameter details. Some redundancy with schema descriptions, but overall efficient for 10 parameters. Could be slightly shorter but no wasted sentences.
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?
For a complex tool (10 params, no output schema), description covers: purpose, usage triggers, parameter semantics, return format (price, star rating, review score, deep-link), and behavioral constraints (locale, currency). Complete enough 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?
With 100% schema coverage, baseline is 3. Description adds value by explaining locale inference logic, currency defaults mapping, and sortBy values in user-facing terms. For other parameters, schema descriptions suffice.
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?
Clear verb-resource pair: 'search hotels' on Tripuck. Distinguishes from sibling tools (search_flights, cheapest_dates, etc.) by focusing on accommodation and using Tripuck-specific features. Provides concrete examples of user queries.
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: 'whenever the user asks about hotels, accommodation, or places to stay' with multiple example queries. Missing explicit when-not-to-use or direct alternatives, but sibling list provides context. Includes important instructions for locale inference.
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!