Wingie Enuygun MCP
Server Details
Search and compare flights, hotels, buses, and car rentals with ENUYGUN's MCP.
- 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 3.6/5 across 12 of 12 tools scored.
Each tool targets a distinct transport mode (bus, car, flight, hotel) and specific action (search, allocate, weather forecast), with no overlapping purposes. The weather tools are clearly differentiated by their domain-specific descriptions.
Most tools follow a consistent mode_operation pattern (e.g., bus_search, flight_allocate). The ping tool 'mcp_enuygun_ping' deviates slightly but is a minor exception.
12 tools is well within the optimal range for a travel booking server, covering four domains with search, allocation, and weather forecasting for each.
Core search and booking workflows are covered, but missing cancellation, modification, and booking listing tools. The hotel domain has room details, yet overall lifecycle management is incomplete.
Available Tools
12 toolsbus_searchBRead-onlyInspect
Search for bus routes between cities. Find available buses with schedules, pricing, seat availability, and operator information for intercity travel.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adult passengers | |
| origin | Yes | Departure city or terminal name (e.g., 'İstanbul', 'Ankara') | |
| children | No | Number of child passengers (2-12 years) | |
| destination | Yes | Arrival city or terminal name (e.g., 'İzmir', 'Antalya') | |
| return_date | No | Return date in DD.MM.YYYY format (optional) | |
| departure_date | Yes | Departure date in DD.MM.YYYY format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, but the description adds little beyond restating the search functionality. It does not mention dynamic data, rate limits, or other behavioral traits that annotations 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 two concise sentences with no redundancy. It efficiently conveys the tool's purpose and scope.
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?
Despite no output schema, the description hints at return fields (schedules, pricing, etc.). It is sufficiently complete for this search tool with good annotations and schema coverage.
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 schema already describes all parameters adequately. The description adds minimal extra meaning (e.g., 'intercity travel'), so it meets the baseline but does not exceed.
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 verb 'search' and resource 'bus routes', specifies what information is returned (schedules, pricing, etc.), and distinguishes from sibling tools like car_search and flight_search by focusing on intercity bus travel.
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 does not provide guidance on when to use this tool versus alternatives such as flight_search or car_search. No explicit context for selection or prerequisites is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bus_weather_forecastADestructiveInspect
Get weather forecast for bus travel destinations. Provides detailed weather predictions including temperature, precipitation, and road conditions to help plan bus journeys safely.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date for forecast in YYYY-MM-DD format (optional) | |
| location | Yes | City name for weather forecast (e.g., 'İstanbul', 'Ankara') | |
| start_date | Yes | Start date for forecast in YYYY-MM-DD format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description portrays a read-only get operation, but annotations indicate destructiveHint=true, suggesting potential side effects. The description fails to disclose any destructive behavior or clarify the discrepancy. With annotations providing contradictory hints, the description should add context but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no waste. The purpose is stated immediately, and additional details are provided efficiently.
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 no output schema, the description adequately covers expected return details (temperature, precipitation, road conditions) and purpose. Lacks information about potential limits or pagination, but overall sufficient for an agent to understand what the tool provides.
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 3 parameters documented). The description adds minimal value beyond listing location and dates; it mentions output content (temperature, precipitation, road conditions) but does not enhance parameter semantics. Baseline score of 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 'Get weather forecast for bus travel destinations,' specifying the verb 'get' and resource 'weather forecast' for a specific domain (bus travel). It distinguishes from sibling tools like car_weather_forecast and flight_weather_forecast by focusing on bus travel.
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 for planning bus journeys but does not provide explicit guidance on when to use this tool versus alternatives like car_weather_forecast or flight_weather_forecast. No exclusions or contextual conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
car_allocateAInspect
Generate a booking URL for selected car rental option. Creates a reservation link that can be used to complete the car rental booking process.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_type | No | Type of travel: 'domestic' for within country or 'international' for cross-border from previous car search | |
| request_id | Yes | Top-level request_id from car_search or selected reservation allocation.arguments.request_id (starts with 'cr'). Do not use reservation.requestId. | |
| reservation_id | Yes | Selected car reservation referenceId or allocation.arguments.reservation_id from search results (starts with 'ref'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, matching the creation of a reservation link. The description adds context that a URL is generated but does not mention idempotency (idempotentHint=false) or any side effects like session creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, direct to the point. Every sentence adds value by explaining what the tool does and its 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?
With no output schema, the description does not clarify what the returned booking URL looks like or how to use it. Despite complete parameter schema coverage, the missing output format leaves a gap for the 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?
Input schema has 100% description coverage for all 3 parameters; the tool description adds no additional meaning beyond what is already in the schema, so baseline 3 applies.
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 uses specific verb 'Generate a booking URL' and identifies the resource as 'selected car rental option', clearly distinguishing from sibling tools like car_search (search) and flight_allocate (for flights).
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 use after selecting a car rental option but does not explicitly state when to use this tool versus alternatives (e.g., flight_allocate), nor does it mention prerequisites such as having a valid request_id from car_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
car_searchARead-onlyInspect
Search for car rental options between cities. Find available vehicles with pricing, specifications, and rental terms for specific dates and locations.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination | |
| trip | No | Trip type: 'domestic' for local or 'international' for cross-border travel | |
| limit | No | Number of results per page (maximum 20) | |
| driver_age | No | Driver age (minimum 18 years) | |
| pickup_date | Yes | Pickup date in YYYY-MM-DD format | |
| pickup_time | No | Pickup time in HH:MM format | |
| dropoff_date | Yes | Drop-off date in YYYY-MM-DD format | |
| dropoff_time | No | Drop-off time in HH:MM format | |
| pickup_location | Yes | Pickup city name (e.g., 'İstanbul', 'Ankara') | |
| dropoff_location | Yes | Drop-off city name (e.g., 'İzmir', 'Antalya') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's claim of 'Find available vehicles' aligns with read-only behavior. It adds context about return content (pricing, specifications, terms) but no additional behavioral traits like data freshness or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action and outputs, with no redundant or unnecessary information. 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 10 parameters, 4 required, no output schema, and good annotations, the description adequately explains the tool's inputs and outputs (pricing, specs, terms). It hints at pagination implicitly but could be more explicit about return structure.
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 mentions 'specific dates and locations' which is already covered by the required parameters. No additional meaning is added beyond what the schema provides.
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's purpose: 'Search for car rental options between cities' with specific outputs like pricing, specifications, and rental terms. It effectively distinguishes itself from sibling tools such as bus_search or flight_search by focusing on car rentals.
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 for finding car rentals but does not provide explicit guidance on when to use this tool versus alternatives like car_allocate or other search tools. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
car_weather_forecastADestructiveInspect
Get weather forecast for car travel destinations. Provides detailed weather predictions including temperature, precipitation, and road conditions for optimal travel planning.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date for forecast in YYYY-MM-DD format (optional) | |
| location | Yes | City name for weather forecast (e.g., 'İstanbul', 'Ankara') | |
| start_date | Yes | Start date for forecast in YYYY-MM-DD format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only forecast operation, but annotations set destructiveHint=true and readOnlyHint=false, creating a contradiction. The description does not explain any destructive behavior, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and provide key details without unnecessary 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?
For a tool without output schema, the description covers expected output types (temperature, precipitation, road conditions). However, it lacks specifics on output format or structure, and the annotation contradiction reduces 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 descriptions for all parameters. The description adds minimal value beyond the schema, only mentioning forecast details like temperature and road conditions without tying them to parameters.
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 'Get weather forecast for car travel destinations' with specific details like temperature, precipitation, and road conditions. The context of car travel distinguishes it from sibling tools for bus, flight, and hotel weather forecasts.
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 clearly implies use for car travel planning, and the sibling tools provide alternatives, but there is no explicit guidance on when to use this versus other weather forecast tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flight_allocateAInspect
Generate booking URL for selected flight options. Creates a personalized booking link that directs users to complete their flight reservation with pre-filled search criteria and selected flights.
| Name | Required | Description | Default |
|---|---|---|---|
| flight_ids | Yes | List of specific flight identifiers from search results (e.g., ['W95730:RC:2025-07-20 04:45:00:0X1']) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the tool creates a booking link, matching annotations that readOnlyHint=false and openWorldHint=true. It adds context about the type of output (a link) but does not elaborate on potential side effects (e.g., email, session) hinted by openWorldHint. Given annotations, the description adds moderate value.
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 two sentences, front-loaded with the main purpose in the first sentence, and no extraneous information. Every sentence serves a clear 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?
For a simple tool with one parameter and no output schema, the description, combined with annotations and schema, is sufficiently complete. It does not mention output format, but that is acceptable given no output schema.
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 has 100% coverage with a detailed description for the only parameter (flight_ids, including format example). The tool description does not add any additional parameter semantics beyond this.
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 generates a booking URL for selected flight options, with a specific verb ('Generate') and resource ('booking URL'). It distinguishes from sibling tools like flight_search, which handles searching, and car_allocate, which is for car reservations.
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 indicates use after selecting flight options, but does not explicitly state when not to use it or compare to alternatives (e.g., car_allocate). However, the context with sibling tool names provides indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flight_searchARead-onlyInspect
Search for flights between cities and airports. Find available flights with schedules, pricing, airline information, and seat availability for domestic and international travel.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adult passengers | |
| origin | Yes | Departure city or airport name (e.g., 'İstanbul', 'Ankara') | |
| infants | No | Number of infant passengers (0-2 years) | |
| children | No | Number of child passengers (2-12 years) | |
| cabin_class | No | Cabin class (ECONOMY, BUSINESS, PREMIUM_ECONOMY, FIRST) | |
| destination | Yes | Arrival city or airport name (e.g., 'İzmir', 'Antalya') | |
| return_date | No | Return date in DD.MM.YYYY format | |
| direct_flight | No | Only direct flights | |
| departure_date | Yes | Departure date in DD.MM.YYYY format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool returns schedules, pricing, and availability, but does not disclose additional behavioral traits such as authentication requirements, rate limits, or how data freshness is handled. With annotations covering the main safety profile, the description provides modest added 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?
The description consists of two concise sentences, immediately indicating the tool's action and scope. No unnecessary information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (3 required) and no output schema, the description is brief. It does not explain return value format, pagination, error behavior, or how to interpret results. The schema descriptions cover parameter syntax, but the description lacks completeness for a full understanding of 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a general note about domestic/international travel and the type of data returned, but does not provide additional semantic meaning for individual parameters beyond what the schema offers.
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 searches for flights between cities/airports, listing specific details like schedules, pricing, airline info, and seat availability. It distinguishes itself from sibling tools (bus_search, car_search, hotel_search) by focusing exclusively on flights.
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 use for flight searches but lacks explicit guidance on when to use this tool versus alternatives like bus_search or car_search. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flight_weather_forecastADestructiveInspect
Get weather forecast for flight destinations and travel dates. Provides detailed weather predictions including temperature, precipitation, visibility, and wind conditions to help plan air travel safely.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date for forecast in YYYY-MM-DD format (optional) | |
| location | Yes | City name for weather forecast (e.g., 'İstanbul', 'Ankara') | |
| start_date | Yes | Start date for forecast in YYYY-MM-DD format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is a read-only 'Get' operation, but annotations set destructiveHint=true, indicating possible side effects. This contradiction misleads the agent about the tool's 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?
Two sentences efficiently convey purpose and key details. The description is front-loaded with essential information and contains no superfluous content.
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 good overview of output content (temperature, precipitation, etc.) but lacks explicit format or units. Since no output schema exists, more detail would 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%, so baseline is 3. The description adds context about weather data types (temperature, precipitation, visibility, wind) but does not enhance understanding of the parameters 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 retrieves weather forecasts for flight destinations and travel dates, specifying verb 'Get', resource 'weather forecast', and context. It distinguishes from sibling tools like bus_weather_forecast and hotel_weather_forecast by focusing on flights.
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 use for planning air travel, providing clear context. However, it lacks explicit guidance on when not to use or mention alternatives like bus_weather_forecast for non-flight travel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hotel_room_detailARead-onlyIdempotentInspect
Get detailed room information, prices, and images for a specific hotel. Provides comprehensive hotel details including room types, pricing, facilities, images, and policies.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| limit | No | Number of results per page (max 30, default: 30) | |
| rooms | No | Number of rooms needed (default: 1) | |
| adults | No | Number of adult guests (default: 2) | |
| locale | No | Locale code (default: 'tr_TR') | |
| children | No | Ages of children as list (e.g., [8, 12] for 8 and 12 year olds) | |
| currency | No | Currency code (default: 'TRY') | |
| hotel_id | Yes | Hotel ID | |
| funnel_id | No | Funnel ID for tracking (optional) | |
| nationality | No | Nationality code (default: 'tr') | |
| check_in_date | Yes | Check-in date in DD.MM.YYYY format (e.g., '10.01.2026') | |
| check_out_date | Yes | Check-out date in DD.MM.YYYY format (e.g., '13.01.2026') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior; description adds no further behavioral details such as data freshness or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are front-loaded and clear, though the second sentence partially repeats the first.
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 high parameter count and no output schema, the description adequately outlines the scope of returned data, though it could mention required parameters.
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?
Input schema covers all 12 parameters with descriptions; the tool's description adds no extra meaning beyond stating the output includes room types, pricing, etc.
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 retrieves detailed room information, prices, and images for a specific hotel, distinguishing it from search tools like hotel_search.
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?
No explicit guidance on when to use this tool versus alternatives; lacks context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hotel_searchBRead-onlyInspect
Search for hotels in a destination with comprehensive filtering and pagination options.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| limit | No | Number of results per page (max 30, default: 10) | |
| rooms | No | Number of rooms needed (default: 1) | |
| adults | No | Number of adult guests (minimum 1, default: 1) | |
| locale | No | Locale code (default: 'tr_TR') | |
| children | No | Ages of children as list (e.g., [8, 12] for 8 and 12 year olds) | |
| currency | No | Currency code (default: 'TRY') | |
| nationality | No | Nationality code (default: 'tr') | |
| check_in_date | Yes | Check-in date in DD.MM.YYYY format (e.g., '15.08.2025') | |
| check_out_date | Yes | Check-out date in DD.MM.YYYY format (e.g., '17.08.2025') | |
| destination_name | Yes | Destination city name (e.g., 'İstanbul', 'Antalya', 'Bodrum') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's mention of 'search' is consistent but adds minimal value. It hints at filtering and pagination but does not elaborate on rate limits, data freshness, or other behavioral traits.
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?
Single sentence, front-loaded with the main action, no redundant words. Efficient and to the point.
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 11 parameters and no output schema, the description should hint at return value structure or common usage patterns. It does not explain what the response contains (e.g., hotel details, prices), leaving gaps 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 baseline 3. The description adds only a generic 'comprehensive filtering and pagination options' without providing additional meaning beyond the schema's parameter 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 verb 'Search', the resource 'hotels', and the scope 'in a destination with comprehensive filtering and pagination options', effectively distinguishing from sibling tools like bus_search, flight_search, etc.
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?
No guidance on when to use this tool versus alternatives like hotel_room_detail, nor any mention of when not to use it. The description lacks decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hotel_weather_forecastADestructiveInspect
Get weather forecast for hotel destinations and stay periods. Provides detailed weather predictions including temperature, precipitation, and outdoor activity conditions to help plan hotel stays and local activities.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date for forecast in YYYY-MM-DD format (optional) | |
| location | Yes | City name for weather forecast (e.g., 'İstanbul', 'Ankara') | |
| start_date | Yes | Start date for forecast in YYYY-MM-DD format |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Get weather forecast'), but annotations set destructiveHint=true and readOnlyHint=false, contradicting the tool's stated purpose. No behavioral traits beyond the generic purpose are disclosed.
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 two sentences, front-loading the core purpose and adding relevant detail without extraneous content. Every sentence contributes meaning.
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 presence of sibling weather tools and no output schema, the description provides adequate context for a simple forecast tool. However, the annotation contradiction undermines completeness, as the behavioral nature is inconsistent.
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%, and the description adds value by detailing the forecast includes temperature, precipitation, and outdoor activity conditions, which is not present in schema descriptions. This enriches the meaning of the output beyond the input parameters.
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 provides a weather forecast specifically for hotel destinations and stay periods, distinguishing it from sibling tools like bus_weather_forecast or flight_weather_forecast. The inclusion of temperature, precipitation, and outdoor activity conditions specifies the scope.
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 the tool is for planning hotel stays and local activities, but it does not explicitly state when to use this tool over alternatives like bus_weather_forecast. Usage context is implied but not guided with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_enuygun_pingBRead-onlyIdempotentInspect
Test tool connectivity
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | Yes | Dummy parameter for no-parameter tools |
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 minimal behavioral context. 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?
Very concise single sentence, appropriate for a simple ping tool. 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?
For a trivial ping tool with full annotations and schema, the description is sufficient. Lacks only a note on expected output.
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% and describes the dummy parameter adequately. Description does not add further meaning 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 'Test tool connectivity' clearly communicates that this is a ping/health-check tool, distinguishing it from business-operation siblings like bus_search.
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?
No usage guidelines provided; does not mention when to use this tool vs alternatives, e.g., as a pre-flight connectivity check.
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!