Skip to main content
Glama
variflight

Variflight Tripmatch MCP Server

Official
by variflight

flightHappinessIndex

Analyze flight comfort and amenities by comparing punctuality, seat dimensions, baggage allowances, and health protocols for informed travel planning.

Instructions

using this tool when you need information related to following topics: Detailed flight comparisons (punctuality, amenities, cabin specs),Health safety protocols for air travel,Baggage allowance verification,Environmental impact assessments,Aircraft configuration visualization,Comfort-focused trip planning (seat dimensions, entertainment, food). etc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fnumYesFlight number including airline code (e.g. MU2157, CZ3969)
dateYesFlight date in YYYY-MM-DD format. IMPORTANT: If user input only cotains month and date, you should use getTodayDate tool to get the year. For today's date, use getTodayDate tool instead of hardcoding
depNoDeparture airport IATA 3-letter code (e.g. HFE for Hefei)
arrNoArrival airport IATA 3-letter code (e.g. CAN for Guangzhou)

Implementation Reference

  • The MCP tool handler function for 'flightHappinessIndex'. It receives input parameters, calls the flightService.getFlightHappinessIndex method, formats the response as JSON text content, and handles errors.
    }, async ({ fnum, date, dep, arr }) => {
        try {
            const flights = await flightService.getFlightHappinessIndex(fnum, date, dep, arr);
            return {
                content: [
                    {
                        type: "text",
                        text: JSON.stringify(flights, null, 2)
                    }
                ]
            };
        }
        catch (error) {
            console.error('Error searching flights by number:', error);
            return {
                content: [{ type: "text", text: `Error: ${error.message}` }],
                isError: true
            };
        }
    });
  • Zod-based input schema defining parameters fnum (flight number), date (YYYY-MM-DD), optional dep and arr (IATA codes) with validation rules and descriptions.
    fnum: z.string()
        .regex(/^[A-Z0-9]{2,3}[0-9]{1,4}$/)
        .describe("Flight number including airline code (e.g. MU2157, CZ3969)"),
    date: z.string()
        .regex(/^\d{4}-\d{2}-\d{2}$/)
        .describe("Flight date in YYYY-MM-DD format. IMPORTANT: If user input only cotains month and date, you should use getTodayDate tool to get the year. For today's date, use getTodayDate tool instead of hardcoding"),
    dep: z.string()
        .length(3)
        .regex(/^[A-Z]{3}$/)
        .describe("Departure airport IATA 3-letter code (e.g. HFE for Hefei)")
        .optional(),
    arr: z.string()
        .length(3)
        .regex(/^[A-Z]{3}$/)
        .describe("Arrival airport IATA 3-letter code (e.g. CAN for Guangzhou)")
        .optional(),
  • dist/index.js:128-164 (registration)
    Registration of the 'flightHappinessIndex' MCP tool, including name, description, input schema, and handler function.
    server.tool("flightHappinessIndex", "using this tool when you need information related to following topics: Detailed flight comparisons (punctuality, amenities, cabin specs),Health safety protocols for air travel,Baggage allowance verification,Environmental impact assessments,Aircraft configuration visualization,Comfort-focused trip planning (seat dimensions, entertainment, food). etc.", {
        fnum: z.string()
            .regex(/^[A-Z0-9]{2,3}[0-9]{1,4}$/)
            .describe("Flight number including airline code (e.g. MU2157, CZ3969)"),
        date: z.string()
            .regex(/^\d{4}-\d{2}-\d{2}$/)
            .describe("Flight date in YYYY-MM-DD format. IMPORTANT: If user input only cotains month and date, you should use getTodayDate tool to get the year. For today's date, use getTodayDate tool instead of hardcoding"),
        dep: z.string()
            .length(3)
            .regex(/^[A-Z]{3}$/)
            .describe("Departure airport IATA 3-letter code (e.g. HFE for Hefei)")
            .optional(),
        arr: z.string()
            .length(3)
            .regex(/^[A-Z]{3}$/)
            .describe("Arrival airport IATA 3-letter code (e.g. CAN for Guangzhou)")
            .optional(),
    }, async ({ fnum, date, dep, arr }) => {
        try {
            const flights = await flightService.getFlightHappinessIndex(fnum, date, dep, arr);
            return {
                content: [
                    {
                        type: "text",
                        text: JSON.stringify(flights, null, 2)
                    }
                ]
            };
        }
        catch (error) {
            console.error('Error searching flights by number:', error);
            return {
                content: [{ type: "text", text: `Error: ${error.message}` }],
                isError: true
            };
        }
    });
  • Helper method in OpenAlService class that constructs API parameters and calls the 'happiness' endpoint via makeRequest to retrieve the flight happiness index data.
    async getFlightHappinessIndex(fnum, date, dep, arr) {
        const params = {
            fnum,
            date,
        };
        if (dep)
            params.dep = dep;
        if (arr)
            params.arr = arr;
        return this.makeRequest('happiness', params);
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It lists topics the tool covers but doesn't disclose behavioral traits such as whether it's a read-only query, what data sources it uses, potential rate limits, or error handling. For a tool with 4 parameters and no annotations, this leaves significant gaps in understanding how it behaves.

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

Conciseness3/5

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

The description is a single run-on sentence listing topics, which is somewhat efficient but lacks structure (e.g., no bullet points or clear categorization). It's front-loaded with usage guidance but could be more organized. While not verbose, it doesn't maximize clarity per sentence.

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

Completeness2/5

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

Given no annotations, no output schema, and a tool with 4 parameters, the description is incomplete. It lists topics but doesn't explain what the tool actually returns (e.g., a happiness index score, detailed reports), how results are formatted, or any limitations. For a tool named 'flightHappinessIndex', this leaves too much ambiguity about its function and 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 description coverage is 100%, with clear descriptions for each parameter (flight number, date, departure, arrival). The description doesn't add any meaning beyond what the schema provides—it doesn't explain how parameters relate to the listed topics (e.g., how 'fnum' and 'date' affect health safety protocols). Baseline score of 3 is appropriate since the schema does the heavy lifting.

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

Purpose3/5

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

The description lists topics the tool covers (flight comparisons, safety protocols, baggage allowance, etc.), which gives a general sense of purpose. However, it doesn't specify a clear verb-action (like 'retrieve' or 'calculate') and doesn't distinguish this from sibling tools like 'searchFlightsByNumber' or 'getFlightPriceByCities'. The purpose is vague rather than specific.

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?

The description starts with 'using this tool when you need information related to following topics', which provides some context but is generic. It doesn't explicitly state when to use this tool versus alternatives (e.g., vs. 'searchFlightsByNumber' for basic flight info or 'getFlightPriceByCities' for pricing), nor does it mention exclusions or prerequisites. No clear guidance on tool selection is provided.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/variflight/tripmatch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server