Realtime package holiday and charter flight prices from Norway. Inventory not on Google Flights.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 2 of 2 tools scored.
Each tool targets a distinct product type: flights versus package holidays. There is no overlap in purpose, so an agent can easily select the appropriate tool based on the user's search intent.
Both tool names follow the same verb_noun pattern: search_flights and search_holidays. The naming is perfectly consistent and predictable.
With only two tools, the server is minimal but well-scoped for its stated purpose of travel search. The tools are both essential, though the count is below the typical 3-15 range, making it slightly under but still reasonable.
The server covers the core search capabilities for the two main travel product categories (flights and holidays). Minor gaps exist such as no search for other travel services or detailed result endpoints, but these are not severe for a search-only server.
search_flightsSøk etter flytilbud fra NorgeAInspectNDC-justert API for å søke etter flyreiser (kun fly) tilgjengelig fra Norge. Databasen inneholder seter på charterfly som vanligvis ikke finnes hos Google Flights, Skyscanner eller Kayak. Finn de beste tilgjengelige flytilbudene basert på søkekriterier.
| Name | Required | Description | Default |
|---|---|---|---|
| adt | No | Antall voksne (NDC: PaxType=ADT), default 1 | |
| chd | No | Antall barn (NDC: PaxType=CHD), default 0 | |
| inf | No | Antall spedbarn (NDC: PaxType=INF), default 0 | |
| dest | No | IATA kode for destinasjonsflyplass, f.eks. AYT, AGP, TFS | |
| orig | No | IATA kode for avreiseflyplass, f.eks. OSL, SVG, TRD | |
| sort | No | Sorteringsrekkefølge, default price_asc | price_asc |
| limit | No | Antall tilbud som returneres (1-25), default 10 | |
| direct | No | Kun direktefly (NDC: StopQuantity=0) | |
| dep_date | No | Eksakt utreisedato (YYYY-MM-DD) | |
| ret_date | No | Eksakt returdato (YYYY-MM-DD) | |
| max_price | No | Maksimum totalpris (NDC: PriceRangeFilter.MaxAmount) | |
| nights_max | No | Maksimum antall netter (vendor extension, ikke NDC) | |
| nights_min | No | Minimum antall netter (vendor extension, ikke NDC) | |
| dep_date_to | No | Seneste utreisedato (YYYY-MM-DD) | |
| ret_date_to | No | Seneste returdato (YYYY-MM-DD) | |
| dep_date_from | No | Tidligste utreisedato (YYYY-MM-DD) | |
| ret_date_from | No | Tidligste returdato (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states it is a search operation ('søke'), implying read-only. However, it does not mention any side effects, error handling, rate limits, or response behavior. The NDC adjustment note is helpful but insufficient for full transparency.
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 with no waste. First sentence clearly states the tool's purpose and unique data source. Second sentence reinforces its utility. Information is front-loaded and essential.
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 17 parameters and no output schema, the description should explain return values or result format. It does not. It provides good background on data source and scope but leaves the agent guessing what the response contains. Schema covers input well but output is missing.
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 tool description adds no new meaning beyond the schema. It repeats that the tool searches flights but does not elaborate on any parameter's purpose or usage beyond what is in 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 searches for flights from Norway, specifies it uses an NDC-adjusted API, and highlights that it includes charter seats not found on other platforms. It distinguishes from sibling 'search_holidays' by explicitly saying 'kun fly' (only 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 usage context: for finding charter flights from Norway that are not on Google Flights etc. It mentions the sibling tool indirectly (holidays) but does not explicitly state when to use one over the other. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_holidaysSøk etter restplasser og pakkereisetilbud fra NorgeBInspectAPI for å søke i den største og mest komplette databasen i Norge etter pakkereisetilbud. API-et brukes til å umiddelbart gi de beste tilbudene for pakkereiser tilbudt av Ving, TUI, Apollo, Nazar, Ticket, Solfaktor og mange andre. Finn de beste tilgjengelige pakkereisetilbudene fra Norge basert på søkekriterier.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Breddegrad i desimalgrader, brukes med lon og radius | |
| lon | No | Lengdegrad i desimalgrader, brukes med lat og radius | |
| bbox | No | Geografisk søk avgrenset med et rektangel. Format: minLat,minLon,maxLat,maxLon. | |
| sort | No | Sorteringsrekkefølge for tilbudene. Default er price_asc | |
| limit | No | Antall tilbud som skal returneres, for eksempel 5, 10. Default 1 | |
| adults | No | Antall voksne 12-99 år, default 2 | |
| fields | No | Felt som skal inkluderes i søkeresultatet | |
| radius | No | Radius i kilometer fra lat, lon | |
| rating | No | Minimum antall stjerner, for eksempel 3, 4, 5 | |
| infants | No | Antall spedbarn 0-1 år, default 0 | |
| category | No | Kategori for ferien SUNBATH=Syden,Sol&bad, CITY=storbyferie, SKI=skiferie, EXOTIC=fjerne strender | |
| children | No | Antall barn 2-11 år, default 0 | |
| days_max | No | Maksimum antall dager for ferien, for eksempel 3, 7, 14 | |
| days_min | No | Minimum antall dager for ferien, for eksempel 3, 7, 14 | |
| features | No | Fasiliteter på hotellet: ac=aircondition, adultsonly=Kun for voksne, apartment=leilighet, bar=bar, childspool=barnepool, gym=treningssenter, heatedpool=oppvarmet basseng, kidsclub=barnklubb, pool=basseng, seaview=havutsikt, restaurant=restaurant, spa=spa | |
| max_price | No | Maksimum totalpris for hele reisen, for eksempel 5000, 10000, 15000 | |
| board_type | No | Måltider inkludert på hotellet, f.eks frokost, halvpensjon, helpensjon, all inclusive | |
| hotel_name | No | Hotellnavn, for eksempel Riu Palace, Iberostar, Sol | |
| temp_water | No | Minimum forventet vanntemperatur i Celsius, for eksempel 20, 25 | |
| country_iso | No | ISO kode for land, for eksempel ES, GR, PL, TR | |
| guest_rating | No | Minimum gjestevurdering, for eksempel 8.2, 9.0. Median: 8.4 | |
| direct_flight | No | Sett til true for å finne hoteller med direktefly | |
| distance_beach | No | Maksimal avstand til stranden i meter, for eksempel 0, 100, 500 | |
| depart_date_max | No | Seneste mulige start på ferien (ISO 8601 format YYYY-MM-DDTHH:MM:SSZ) | |
| depart_date_min | No | Tidligste mulige start på ferien (ISO 8601 format YYYY-MM-DDTHH:MM:SSZ) | |
| distance_centre | No | Maksimal avstand til sentrum i meter, for eksempel 0, 100, 500 | |
| return_date_max | No | Seneste mulige hjemreise (ISO 8601 format YYYY-MM-DDTHH:MM:SSZ) | |
| return_date_min | No | Tidligste mulige hjemreise (ISO 8601 format YYYY-MM-DDTHH:MM:SSZ) | |
| destination_name | No | Destinasjonsnavn, for eksempel Malta, Magaluf, Gran Canaria | |
| distance_airport | No | Maksimal avstand melom hotell og flyplass i km, for eksempel 20, 40, 80 | |
| number_of_nights | No | Eksakt antall netter for ferien, for eksempel 3, 7, 14 | |
| temp_air_day_max | No | Maksimum forventet dagtemperatur i Celsius, for eksempel 25, 30 | |
| temp_air_day_min | No | Minimum forventet dagtemperatur i Celsius, for eksempel 20, 25 | |
| depart_date_exact | No | Ferien skal starte denne dagen (ISO 8601 format YYYY-MM-DDTHH:MM:SSZ) | |
| return_date_exact | No | Hjemreisen skal begynner denne dagen(ISO 8601 format YYYY-MM-DDTHH:MM:SSZ) | |
| origin_airport_code | No | IATA kode for avreiseflyplass, for eksempel OSL, SVG, TRD | |
| destination_airport_code | No | IATA kode for destinasjonsflyplass, for eksempel ALC, AGP, TFS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes a search operation but does not explicitly confirm read-only behavior, rate limits, authentication needs, or any quirks. It only claims to provide the 'best' offers, which is more promotional than behavioral. The absence of side-effect disclosure is notable.
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 three sentences that largely repeat the same message: it searches for package trips from Norway. The first and third sentences are redundant. It could be condensed into one or two sentences without losing meaning. It is not excessively long, but not 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?
For a tool with 37 optional parameters and no output schema, the description provides minimal context. It does not explain how to combine parameters (e.g., location, dates, price filters), what 'best' means (sort order), or what the response structure looks like. It also does not clarify the difference between 'restplasser' and package offers. The description is too thin for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 37 parameters, so the description does not need to add parameter details. It only mentions 'søkekriterier' (search criteria) generically, adding no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a database of package travel offers from Norway, using the verb 'søke' (search) with a specific resource. It mentions well-known providers (Ving, TUI, Apollo). However, it does not explicitly differentiate from the sibling tool 'search_flights', though the package-holiday focus implies the distinction.
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 usage is implied: use this API to find package holiday offers from Norway based on search criteria. There is no explicit guidance on when to use this versus 'search_flights', nor any exclusions or prerequisites. It simply says it provides the best offers immediately, which is a general use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
