Skip to main content
Glama

Wingie Enuygun MCP

by com.enuygun
OverviewAdmin

Server Details

Search and compare flights, hotels, buses, and car rentals with ENUYGUN's MCP.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A3.8/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: search, weather, allocate, and detail per travel mode (bus, car, flight, hotel). The utility ping is clearly separate. No two tools appear to perform the same function, even though weather forecasts exist for multiple modes—they are explicitly differentiated by mode and context.

Naming Consistency5/5

All tools follow a consistent snake_case pattern with a transport mode prefix (bus_, car_, flight_, hotel_) followed by a descriptive action (search, weather_forecast, allocate, room_detail). The only exception is mcp_enuygun_ping, which is a generic connectivity test and deliberately outside the domain pattern. Overall, the naming is uniform and predictable.

Tool Count5/5

With 12 tools, the server is well-scoped for a travel aggregation service covering four major transport/hotel segments plus supporting weather and booking utilities. Each tool serves a clear purpose without unnecessary duplication or excessive granularity, hitting the sweet spot for usability.

Completeness3/5

The server provides search and weather for all modes, and booking allocation for car and flight, but lacks booking/allocation tools for bus and hotel. This is a notable gap in the booking workflow, as users can't complete bus or hotel reservations through this MCP. While search and detail tools cover planning, the missing allocation steps represent a significant incompleteness for a travel booking service.

Available Tools

12 tools
bus_weather_forecastA
Read-only
Inspect

Get weather forecast for bus travel destinations. Provides detailed weather predictions including temperature, precipitation, and road conditions to help plan bus journeys safely.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoEnd date for forecast in YYYY-MM-DD format (optional)
locationYesCity name for weather forecast (e.g., 'İstanbul', 'Ankara')
start_dateYesStart date for forecast in YYYY-MM-DD format

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a read-only, non-destructive operation. The description adds useful context about the forecast contents, such as temperature, precipitation, and road conditions, but does not disclose operational details like units, forecast range, or data limitations. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The main purpose is front-loaded, and the second sentence adds relevant detail about what the forecast includes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter read-only forecast tool with a fully documented schema and useful annotations, the description is largely complete. It states the purpose and the key output contents. A minor gap is the lack of detail on units or exact response structure, but this is not critical for selecting and invoking this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 location, start_date, and end_date. The description adds no parameter-specific semantics beyond general forecast content, which is acceptable given the schema's thoroughness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action, 'Get weather forecast', and clearly identifies the resource as 'bus travel destinations'. It also signals differentiation from sibling tools such as car_weather_forecast, flight_weather_forecast, and hotel_weather_forecast by emphasizing 'bus journeys' and 'road conditions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for planning bus journeys safely, which gives some context. However, it does not explicitly state when to prefer this tool over the sibling weather forecast tools, nor does it mention exclusions or alternatives.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
trip_typeNoType of travel: 'domestic' for within country or 'international' for cross-border from previous car search
request_idYesTop-level request_id from car_search or selected reservation allocation.arguments.request_id (starts with 'cr'). Do not use reservation.requestId.
reservation_idYesSelected car reservation referenceId or allocation.arguments.reservation_id from search results (starts with 'ref').

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already mark the operation as read-only and non-destructive, so the description does not need to cover safety. It adds that the output is a booking URL/reservation link that can be later used to complete the booking, which clarifies the tool's non-final role. However, it does not disclose any additional behaviors like side effects, error cases, or return value structure beyond being a URL.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences and front-loads the core purpose. Some redundancy exists between 'Generate a booking URL' and 'Creates a reservation link', but the second sentence adds the useful context that the link completes the booking process.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple allocation tool, the combination of a clear purpose statement, detailed schema parameter descriptions, and safety annotations covers what an agent needs to call it correctly. The main gap is that no output schema exists and the description only vaguely states the return value is a booking URL, without describing the response structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description itself says nothing about parameters, but all three parameters (trip_type, request_id, reservation_id) have thorough descriptions in the input schema, including format prefixes and usage warnings. With 100% schema description coverage, the baseline of 3 applies, and the description adds no extra parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Generate' and names the resource 'booking URL for selected car rental option', making the function clear. It distinguishes itself from search tools by requiring a 'selected' option, though it never names a sibling tool such as car_search or flight_allocate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'selected car rental option' implies this tool is used after a search and selection step, but the description does not explicitly state when to use it instead of car_search or other allocate tools. No alternatives or exclusions are mentioned; the only workflow guidance is hidden in the schema parameter descriptions, not the tool description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

car_weather_forecastA
Read-only
Inspect

Get weather forecast for car travel destinations. Provides detailed weather predictions including temperature, precipitation, and road conditions for optimal travel planning.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoEnd date for forecast in YYYY-MM-DD format (optional)
locationYesCity name for weather forecast (e.g., 'İstanbul', 'Ankara')
start_dateYesStart date for forecast in YYYY-MM-DD format

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly and non-destructive behavior. The description adds useful context that results include temperature, precipitation, and road conditions, but no caveats about forecast range, data source, or units. It is consistent 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, with the core operation front-loaded and a single clarifying second sentence. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only forecast tool with fully documented parameters, the description covers what the agent needs to select and call it. It names return categories despite no output schema, though it leaves minor details like units unspecified. Sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, so the schema already documents location and dates. The description adds no parameter-level detail beyond high-level output content, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and resource: getting weather forecasts for car travel destinations, and mentions road conditions that signal car-specific output. The verb-resource pair and mode qualifier distinguish it from the sibling weather tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description clearly situates the tool for car travel planning, implying use when the travel mode is by car. It does not explicitly name alternative bus/flight/hotel weather tools, but the car qualifier provides sufficient context. No misleading usage information.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
flight_idsYesList of specific flight identifiers from search results (e.g., ['W95730:RC:2025-07-20 04:45:00:0X1'])

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-read-only and non-idempotent behavior. The description adds useful context by explaining the generated URL is personalized and pre-filled, but it does not disclose potential side effects, expiration, or behavior with invalid flight IDs. It adds some value beyond annotations without being fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with the primary action front-loaded. The second sentence does add detail about personalization and pre-filled criteria, though it is somewhat redundant with the first sentence. No unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with full schema coverage and annotations clarifying side-effect profile, the description is sufficient. It conveys what the tool produces and the input source. It could mention the prerequisite of a prior flight search more explicitly, but the schema description already indicates the IDs come from search results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description includes a concrete example format. The tool description adds little beyond restating that the selected flights are used. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Generate') and resource ('booking URL for selected flight options'), and clarifies the result is a personalized link pre-filled with search criteria and selected flights. This clearly distinguishes it from siblings like flight_search and the other allocate tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is used after flight options have been selected, and the parameter description reinforces that flight_ids come from search results. However, it does not explicitly mention flight_search or state when not to use this tool, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

flight_weather_forecastA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoEnd date for forecast in YYYY-MM-DD format (optional)
locationYesCity name for weather forecast (e.g., 'İstanbul', 'Ankara')
start_dateYesStart date for forecast in YYYY-MM-DD format

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that this is read-only and non-destructive. The description adds useful behavioral detail by disclosing the returned data categories (temperature, precipitation, visibility, wind), which is not present in the annotations or schema. No contradiction; it could add units or date-range behavior but is not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight, front-loaded sentences. The first states the action and scope; the second enriches with concrete output details. No filler, no repetition of schema information, and every sentence contributes to an agent's understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter read-only tool with no output schema and full schema coverage, the description is sufficient: it explains the purpose, the planning context, and the kind of data returned. Minor gaps like units, forecast granularity, or date-range behavior are not critical given the tool's simplicity and the sibling-tool pattern.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (location, start_date, end_date) are already documented. The description adds conceptual context linking 'flight destinations' to location and 'travel dates' to start/end dates, but it does not provide any format or constraint details beyond the schema. This matches the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Get weather forecast') and a clear resource ('flight destinations and travel dates'), and the flight scope distinguishes it from the sibling weather tools (bus_weather_forecast, car_weather_forecast, hotel_weather_forecast). It also names the key weather elements returned, leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context—'for flight destinations and travel dates' and 'help plan air travel safely'—making it obvious when to choose this over the ground-transport weather siblings. However, it does not explicitly name alternatives or state when not to use the tool, so it falls just short of explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hotel_room_detailA
Read-onlyIdempotent
Inspect

Get detailed room information, prices, and images for a specific hotel. Provides comprehensive hotel details including room types, pricing, facilities, images, and policies.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 1)
limitNoNumber of results per page (max 30, default: 30)
roomsNoNumber of rooms needed (default: 1)
adultsNoNumber of adult guests (default: 2)
localeNoLocale code (default: 'tr_TR')
childrenNoAges of children as list (e.g., [8, 12] for 8 and 12 year olds)
currencyNoCurrency code (default: 'TRY')
hotel_idYesHotel ID
funnel_idNoFunnel ID for tracking (optional)
nationalityNoNationality code (default: 'tr')
check_in_dateYesCheck-in date in DD.MM.YYYY format (e.g., '10.01.2026')
check_out_dateYesCheck-out date in DD.MM.YYYY format (e.g., '13.01.2026')

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already communicate read-only, non-destructive, and idempotent behavior, lowering the burden. The description adds what data is returned (room types, pricing, facilities, images, policies), but does not disclose behavioral traits like date-dependent availability, pagination behavior, or potential empty results. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and the main action is front-loaded. The second sentence is somewhat redundant with the first but does add facilities and policies, so it earns its place reasonably well.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should carry more weight in explaining return values. It does list key content areas, but it omits how pricing varies by dates/occupancy, pagination details, and response shape. Overall it is adequate but has clear gaps for an agent deciding whether the tool fully covers a request.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 12 parameters. The description does not add meaning beyond the schema, such as date format expectations, occupancy impact, or pagination semantics, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get detailed room information, prices, and images for a specific hotel.' It clearly distinguishes itself from sibling hotel_search by targeting a specific hotel rather than searching across hotels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a specific hotel' implies this is for when a hotel_id is already known, but the description never explicitly says to use hotel_search first when no hotel_id is available. No alternatives or exclusions are mentioned, so usage guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hotel_weather_forecastA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoEnd date for forecast in YYYY-MM-DD format (optional)
locationYesCity name for weather forecast (e.g., 'İstanbul', 'Ankara')
start_dateYesStart date for forecast in YYYY-MM-DD format

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds the expected forecast contents and purpose but does not disclose data source, update frequency, units, or response structure; with annotations covering the safety profile, this is adequate but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two terse sentences front-load the action and then add useful output details without redundancy. Every phrase in the description earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter read-only weather query with no output schema, the description covers what the tool does, when to use it, and what it returns. It leaves out units and response format, but the low complexity and strong annotations make this a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions, so the baseline is 3. 'Hotel destinations' maps to location and 'stay periods' hints at the optional end_date, but the description adds no syntax or formatting detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with a specific verb and resource: 'Get weather forecast for hotel destinations and stay periods.' It names output categories (temperature, precipitation, outdoor activity conditions) and distinguishes itself from the sibling bus/car/flight_weather_forecast tools by explicitly targeting hotel stays and local activities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly scopes usage to planning hotel stays and local activities, which is a distinct context from the mode-specific weather siblings. It does not explicitly name alternatives or exclusions, so it stops one step short of a full when-to-use/not-to-use guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_enuygun_pingB
Read-onlyIdempotent
Inspect

Test tool connectivity

ParametersJSON Schema
NameRequiredDescriptionDefault
random_stringYesDummy parameter for no-parameter tools

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Changedcar_search1 field changed
      • addedInput schema / properties / sort_by
        Added value: +{
+  "description": "Sort criteria: 'recommended', 'price_asc' for cheapest first, 'price_desc' for most expensive first, 'distance' for nearest first, 'review' for highest rated, or 'review_count' for most reviewed",
+  "type": "string"
+}
  2. 11 tool updates
    • Addedbus_search
    • Addedbus_weather_forecast
    • Addedcar_allocate
    • Addedcar_search
    • Addedcar_weather_forecast
    • Addedflight_allocate
    • Addedflight_search
    • Addedflight_weather_forecast
    • Addedhotel_room_detail
    • Addedhotel_search
    • Addedhotel_weather_forecast
  3. 11 tool updates
    • Removedbus_search
    • Removedbus_weather_forecast
    • Removedcar_allocate
    • Removedcar_search
    • Removedcar_weather_forecast
    • Removedflight_allocate
    • Removedflight_search
    • Removedflight_weather_forecast
    • Removedhotel_room_detail
    • Removedhotel_search
    • Removedhotel_weather_forecast
  4. 11 tool updates
    • Addedbus_search
    • Addedbus_weather_forecast
    • Addedcar_allocate
    • Addedcar_search
    • Addedcar_weather_forecast
    • Addedflight_allocate
    • Addedflight_search
    • Addedflight_weather_forecast
    • Addedhotel_room_detail
    • Addedhotel_search
    • Addedhotel_weather_forecast
  5. 11 tool updates
    • Removedbus_search
    • Removedbus_weather_forecast
    • Removedcar_allocate
    • Removedcar_search
    • Removedcar_weather_forecast
    • Removedflight_allocate
    • Removedflight_search
    • Removedflight_weather_forecast
    • Removedhotel_room_detail
    • Removedhotel_search
    • Removedhotel_weather_forecast
  6. 3 tool updates
    • Removedbus_get_reservation_detail
    • Removedcar_get_reservation_detail
    • Removedflight_get_reservation_detail
  7. 19 tool updates
    • Removedbus_cancel_commit
    • Removedbus_cancel_viewonly
    • Removedbus_reservation_reissue
    • Removedbus_send_cancel_otp
    • Removedbus_send_invoice_mail
    • Removedbus_send_refund_mail
    • Removedbus_send_ticket_mail
    • Removedcar_cancel_commit
    • Removedcar_cancel_otp
    • Removedcar_cancel_viewonly
    • Removedcar_rental_reservation_reissue
    • Removedcar_send_invoice_mail
    • Removedcar_send_refund_mail
    • Removedcar_send_ticket_mail
    • Removedflight_cancel_viewonly
    • Removedflight_checkin
    • Removedflight_send_invoice_mail
    • Removedflight_send_ticket_mail
    • Removedflight_ticket_reissue
  8. 15 tool updates
    • Changedbus_cancel_commit3 fields changed
      • changedInput schema / properties / otp_code / description
        Previous value: -"The OTP code for confirmation"New value: +"One-time password received via SMS for verification"
      • changedInput schema / properties / pnr / description
        Previous value: -"The PNR code of the bus ticket"New value: +"Bus ticket PNR (Passenger Name Record) code to cancel"
      • removedInput schema / properties / to_wallet
        Removed value: -{
-  "description": "Whether to refund to wallet (True) or original payment method (False)",
-  "type": "boolean"
-}
    • Changedbus_send_cancel_otp1 field changed
      • changedInput schema / properties / pnr / description
        Previous value: -"The PNR code of the bus ticket"New value: +"Bus ticket PNR (Passenger Name Record) code to initiate cancellation for"
    • Changedbus_send_ticket_mail1 field changed
      • changedInput schema / properties / pnr / description
        Previous value: -"The PNR code of the bus ticket"New value: +"Bus ticket PNR (Passenger Name Record) code to send ticket for"
    • Changedcar_allocate1 field changed
      • changedInput schema / properties / trip_type / description
        Previous value: -"Type of travel: 'domestic' for within country or 'international' for cross-border"New value: +"Type of travel: 'domestic' for within country or 'international' for cross-border from previous car search"
    • Changedcar_cancel_commit1 field changed
      • removedInput schema / properties / to_wallet
        Removed value: -{
-  "description": "Whether to refund to wallet (True) or original payment method (False)",
-  "type": "boolean"
-}
    • Changedcar_get_reservation_detail1 field changed
      • changedInput schema / properties / reservation_id / description
        Previous value: -"Car rental reservation identifier to fetch detailed information for"New value: +"Car rental reservation identifier to fetch details for"
    • Changedcar_search3 fields changed
      • removedInput schema / properties / filters
        Removed value: -{
-  "description": "Additional filtering options for refining search results",
-  "type": "object"
-}
      • changedInput schema / properties / limit / description
        Previous value: -"Number of results per page (maximum 50 for authenticated users)"New value: +"Number of results per page (maximum 20)"
      • removedInput schema / properties / sort_by
        Removed value: -{
-  "description": "Sort criteria: 'recommended', 'price_asc' for cheapest first, 'price_desc' for most expensive first, 'distance' for nearest first, 'review' for highest rated, or 'review_count' for most reviewed",
-  "type": "string"
-}
    • Changedflight_allocate1 field changed
      • changedInput schema / properties / flight_ids / description
        Previous value: -"List of flight IDs to allocate (e.g., ['W95730:RC:2025-07-20 04:45:00:0X1'])"New value: +"List of specific flight identifiers from search results (e.g., ['W95730:RC:2025-07-20 04:45:00:0X1'])"
    • Changedflight_cancel_viewonly1 field changed
      • changedInput schema / properties / pnr / description
        Previous value: -"The PNR code of the flight ticket"New value: +"Flight ticket PNR (Passenger Name Record) code to check cancellation details for"
    • Changedflight_checkin3 fields changed
      • addedInput schema / properties / last_name
        Added value: +{
+  "description": "Passenger's last name as registered in the booking",
+  "type": "string"
+}
      • changedInput schema / properties / pnr / description
        Previous value: -"The PNR code of the flight ticket"New value: +"Flight ticket PNR (Passenger Name Record) code for check-in"
      • changedInput schema / required
        Previous value: -[
-  "pnr"
-]New value: +[
+  "pnr",
+  "last_name"
+]
    • Changedflight_get_reservation_detail2 fields changed
      • changedInput schema / properties / last_name / description
        Previous value: -"The last name of the passenger"New value: +"Passenger's last name as registered in the booking"
      • changedInput schema / properties / pnr / description
        Previous value: -"The PNR code of the flight ticket"New value: +"Flight ticket PNR (Passenger Name Record) code"
    • Changedflight_ticket_reissue2 fields changed
      • addedInput schema / properties / last_name
        Added value: +{
+  "description": "The last name of the passenger",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "pnr"
-]New value: +[
+  "pnr",
+  "last_name"
+]
    • Changedflight_weather_forecast3 fields changed
      • changedInput schema / properties / end_date / description
        Previous value: -"Bitiş tarihi (YYYY-MM-DD formatında) - opsiyonel"New value: +"End date for forecast in YYYY-MM-DD format (optional)"
      • changedInput schema / properties / location / description
        Previous value: -"Şehir adı (örn: 'İstanbul', 'Ankara')"New value: +"City name for weather forecast (e.g., 'İstanbul', 'Ankara')"
      • changedInput schema / properties / start_date / description
        Previous value: -"Başlangıç tarihi (YYYY-MM-DD formatında)"New value: +"Start date for forecast in YYYY-MM-DD format"
    • Addedhotel_room_detail
    • Changedhotel_search11 fields changed
      • changedInput schema / properties / adults / description
        Previous value: -"Number of adult guests"New value: +"Number of adult guests (minimum 1, default: 1)"
      • changedInput schema / properties / check_in_date / description
        Previous value: -"Check-in date in DD.MM.YYYY format"New value: +"Check-in date in DD.MM.YYYY format (e.g., '15.08.2025')"
      • changedInput schema / properties / check_out_date / description
        Previous value: -"Check-out date in DD.MM.YYYY format"New value: +"Check-out date in DD.MM.YYYY format (e.g., '17.08.2025')"
      • changedInput schema / properties / children / description
        Previous value: -"Ages of children (e.g., [8, 12])"New value: +"Ages of children as list (e.g., [8, 12] for 8 and 12 year olds)"
      • addedInput schema / properties / currency
        Added value: +{
+  "description": "Currency code (default: 'TRY')",
+  "type": "string"
+}
      • changedInput schema / properties / destination_name / description
        Previous value: -"Destination city name (e.g., 'İstanbul', 'Antalya')"New value: +"Destination city name (e.g., 'İstanbul', 'Antalya', 'Bodrum')"
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "Number of results per page (max 30, default: 10)",
+  "type": "integer"
+}
      • addedInput schema / properties / locale
        Added value: +{
+  "description": "Locale code (default: 'tr_TR')",
+  "type": "string"
+}
      • addedInput schema / properties / nationality
        Added value: +{
+  "description": "Nationality code (default: 'tr')",
+  "type": "string"
+}
      • addedInput schema / properties / page
        Added value: +{
+  "description": "Page number for pagination (default: 1)",
+  "type": "integer"
+}
      • changedInput schema / properties / rooms / description
        Previous value: -"Number of rooms"New value: +"Number of rooms needed (default: 1)"
  9. 32 tool updates
    • Addedbus_cancel_commit
    • Addedbus_cancel_viewonly
    • Addedbus_get_reservation_detail
    • Addedbus_reservation_reissue
    • Addedbus_search
    • Addedbus_send_cancel_otp
    • Addedbus_send_invoice_mail
    • Addedbus_send_refund_mail
    • Addedbus_send_ticket_mail
    • Addedbus_weather_forecast
    • Addedcar_allocate
    • Addedcar_cancel_commit
    • Addedcar_cancel_otp
    • Addedcar_cancel_viewonly
    • Addedcar_get_reservation_detail
    • Addedcar_rental_reservation_reissue
    • Addedcar_search
    • Addedcar_send_invoice_mail
    • Addedcar_send_refund_mail
    • Addedcar_send_ticket_mail
    • Addedcar_weather_forecast
    • Addedflight_allocate
    • Addedflight_cancel_viewonly
    • Addedflight_checkin
    • Addedflight_get_reservation_detail
    • Addedflight_search
    • Addedflight_send_invoice_mail
    • Addedflight_send_ticket_mail
    • Addedflight_ticket_reissue
    • Addedflight_weather_forecast
    • Addedhotel_search
    • Addedhotel_weather_forecast
  10. 32 tool updates
    • Removedbus_cancel_commit
    • Removedbus_cancel_viewonly
    • Removedbus_get_reservation_detail
    • Removedbus_reservation_reissue
    • Removedbus_search
    • Removedbus_send_cancel_otp
    • Removedbus_send_invoice_mail
    • Removedbus_send_refund_mail
    • Removedbus_send_ticket_mail
    • Removedbus_weather_forecast
    • Removedcar_allocate
    • Removedcar_cancel_commit
    • Removedcar_cancel_otp
    • Removedcar_cancel_viewonly
    • Removedcar_get_reservation_detail
    • Removedcar_rental_reservation_reissue
    • Removedcar_search
    • Removedcar_send_invoice_mail
    • Removedcar_send_refund_mail
    • Removedcar_send_ticket_mail
    • Removedcar_weather_forecast
    • Removedflight_allocate
    • Removedflight_cancel_viewonly
    • Removedflight_checkin
    • Removedflight_get_reservation_detail
    • Removedflight_search
    • Removedflight_send_invoice_mail
    • Removedflight_send_ticket_mail
    • Removedflight_ticket_reissue
    • Removedflight_weather_forecast
    • Removedhotel_search
    • Removedhotel_weather_forecast
  11. 9 tool updates
    • Removedbus_get_reservations
    • Removedcar_get_reservations
    • Removedflight_get_reservations
    • Removedflight_request_refund_receipt
    • Removedflight_send_refund_mail
    • Removedget_password_change_link
    • Removedget_user_profile
    • Removedget_user_travels
    • Removedget_wallet_link
  12. 42 tool updates
    • First observedbus_cancel_commit
    • First observedbus_cancel_viewonly
    • First observedbus_get_reservation_detail
    • First observedbus_get_reservations
    • First observedbus_reservation_reissue
    • First observedbus_search
    • First observedbus_send_cancel_otp
    • First observedbus_send_invoice_mail
    • First observedbus_send_refund_mail
    • First observedbus_send_ticket_mail
    • First observedbus_weather_forecast
    • First observedcar_allocate
    • First observedcar_cancel_commit
    • First observedcar_cancel_otp
    • First observedcar_cancel_viewonly
    • First observedcar_get_reservation_detail
    • First observedcar_get_reservations
    • First observedcar_rental_reservation_reissue
    • First observedcar_search
    • First observedcar_send_invoice_mail
    • First observedcar_send_refund_mail
    • First observedcar_send_ticket_mail
    • First observedcar_weather_forecast
    • First observedflight_allocate
    • First observedflight_cancel_viewonly
    • First observedflight_checkin
    • First observedflight_get_reservation_detail
    • First observedflight_get_reservations
    • First observedflight_request_refund_receipt
    • First observedflight_search
    • First observedflight_send_invoice_mail
    • First observedflight_send_refund_mail
    • First observedflight_send_ticket_mail
    • First observedflight_ticket_reissue
    • First observedflight_weather_forecast
    • First observedget_password_change_link
    • First observedget_user_profile
    • First observedget_user_travels
    • First observedget_wallet_link
    • First observedhotel_search
    • First observedhotel_weather_forecast
    • First observedmcp_enuygun_ping

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources