Variflight Tripmatch MCP Server

Official

by variflight

Overview Schema Related Servers Score Discussions

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as flight price lookup, flight search by number, and train ticket search, but there is some overlap between getFlightPriceByCities and searchFlightsByDepArr, which both retrieve flight information based on cities and dates, potentially causing confusion. The flightHappinessIndex is broad and could overlap with comfort aspects of other tools, but descriptions help clarify.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern with camelCase, as seen in getFlightPriceByCities and searchFlightsByNumber, with minor deviations like flightHappinessIndex (which lacks a verb prefix) and getTodayDate (which is more direct). Overall, the pattern is readable and mostly uniform.
Tool Count5/5
With 9 tools, the count is well-scoped for a travel and flight information server, covering key areas like flight searches, pricing, transfers, weather, and train services. Each tool serves a specific function without redundancy, making the set efficient and appropriate for the domain.
Completeness4/5
The tool surface covers core travel planning needs, including flight and train searches, pricing, transfers, and weather, with good CRUD-like coverage for information retrieval. Minor gaps exist, such as no explicit tools for booking or updating reservations, but agents can work around this with the provided search and info tools.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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 of behavioral disclosure. It states what the tool does (get weather for 3 days) and the input format (IATA code), but doesn't describe behavioral traits like rate limits, authentication needs, error handling, or what the output looks like (e.g., format, units, or structure). For a tool with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. It uses two sentences efficiently: one for the main function and one for input details. There's no unnecessary repetition or fluff, though it could be slightly more structured (e.g., separating usage notes).
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 the complexity (a weather query tool with no output schema and no annotations), the description is incomplete. It covers the input but lacks crucial context: no information on output format (e.g., what data is returned, units), error cases, or behavioral constraints. Without annotations or an output schema, the description should compensate more to be complete for agent use.
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 input schema has 100% description coverage, with the parameter 'airport' fully documented in the schema (including pattern and examples). The description adds minimal value beyond the schema by reiterating the IATA code requirement and providing the same examples. Since schema coverage is high, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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 clearly states the tool's purpose: 'Get airport future weather for 3days (today、tomorrow、the day after tomorrow) by airport IATA 3-letter code.' It specifies the verb ('Get'), resource ('airport future weather'), and scope ('3days'), but doesn't explicitly differentiate from sibling tools like 'getFlightPriceByCities' or 'searchFlightsByNumber', which are unrelated to weather. The purpose is clear but sibling differentiation is only implicit.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or related tools (e.g., whether there are other weather tools or if this is the only one). The context is implied (need airport weather for 3 days), but there's no explicit usage context or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states the action ('Search') but doesn't describe any behavioral traits such as whether it's read-only, rate-limited, requires authentication, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple search tool.
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 the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, performance, or output format, which are crucial for an AI agent to use the tool correctly. The simplicity of the tool (one parameter) doesn't compensate for these gaps.
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 schema description coverage is 100%, with the single parameter 'query' fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'keyword', but doesn't provide additional syntax, format details, or examples beyond what's in the schema description.
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 clearly states the tool's purpose with a specific verb ('Search') and resource ('train stations'), and includes the method ('by keyword'). However, it doesn't explicitly differentiate from sibling tools like 'searchTrainTickets' which searches for tickets rather than stations, though the distinction is implied.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'searchTrainTickets' or 'getFlightAndTrainTransferInfo', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions the date format constraint and hints at using 'getTodayDate' for today's date, but fails to describe key behaviors such as whether this is a read-only operation, what the output looks like (e.g., list of tickets, prices), error handling, or any rate limits. For a search tool with no annotations, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, with two concise sentences that directly state the tool's purpose and a key constraint. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
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 the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on output format (e.g., what data is returned), behavioral traits like error handling or pagination, and usage context relative to siblings. This leaves the agent with insufficient information to fully understand the tool's operation and 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value by reiterating the date format requirement, which is also covered in the schema's pattern and description. It does not provide additional semantic context beyond what the schema offers, meeting the baseline for high schema coverage.
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 clearly states the tool's purpose: 'Search for train tickets between two cities on a specific date.' It specifies the verb ('search'), resource ('train tickets'), and scope ('between two cities on a specific date'), which is clear and specific. However, it does not explicitly differentiate from sibling tools like 'searchTrainStations' or 'getFlightAndTrainTransferInfo', which could cause confusion about when to use this versus alternatives.
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 provides no guidance on when to use this tool versus alternatives. It mentions the date format requirement but does not indicate scenarios where this tool is preferred over siblings like 'searchTrainStations' or 'getFlightAndTrainTransferInfo'. There is no explicit context for usage, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions format requirements (IATA codes, YYYY-MM-DD) and references 'getTodayDate' for date handling, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, what kind of price information is returned (e.g., single quote, range, list), whether it requires authentication, or any rate limits. The description adds some context but is insufficient for a mutation-free tool with zero annotation coverage.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific format requirements. Every sentence earns its place by providing essential constraints without redundancy. It's efficient and well-structured.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers input formats and references date handling, but lacks details on output behavior, error cases, or integration with siblings. Without annotations or output schema, more context on what the tool returns would be beneficial, but it's adequate for a basic query 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 schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it reiterates the IATA code requirement and date format, and mentions using 'getTodayDate' for incomplete dates, which is useful but not substantial. This meets the baseline for high schema coverage.
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 clearly states the tool's purpose: 'Get flight price information by departure city, arrival city, and departure date.' This specifies the verb ('Get'), resource ('flight price information'), and key parameters. However, it doesn't explicitly differentiate from sibling tools like 'searchFlightsByDepArr' which might serve similar purposes, preventing a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It mentions using 'getTodayDate' for date handling, but this is a prerequisite rather than a usage guideline. There's no comparison with sibling tools like 'searchFlightsByDepArr' or 'flightHappinessIndex' to help the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about date handling requirements and parameter optionality, but does not cover other behavioral aspects like error handling, rate limits, authentication needs, or what the search returns (e.g., flight details, availability). The description is adequate but incomplete for a search tool.
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 appropriately sized and front-loaded with the core purpose, followed by specific formatting rules and usage notes. Every sentence adds value, though the structure could be slightly improved by grouping related instructions (e.g., date rules together). It avoids redundancy and waste.
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?
Given the tool's moderate complexity (4 parameters, search functionality) and lack of both annotations and output schema, the description is partially complete. It covers input formatting and critical usage rules well, but omits details about what the tool returns (e.g., flight data structure, error responses) and other behavioral expectations, leaving gaps for the agent.
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 parameters thoroughly. The description adds minimal value beyond the schema by reinforcing format examples (e.g., IATA codes) and the 'keep empty' guidance for optional parameters, but does not provide significant additional semantic context. This meets the baseline for high 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 clearly states the specific action ('Search flights') with the resource ('by flight number and date'), distinguishing it from sibling tools like 'searchFlightsByDepArr' which searches by departure/arrival airports. It provides concrete examples (e.g., MU2157, CZ3969) that reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage with explicit instructions for handling today's date (use 'getTodayDate' tool) and optional parameters (dep/arr can be empty if unknown). However, it does not explicitly state when to use this tool versus alternatives like 'searchFlightsByDepArr', leaving some ambiguity in sibling tool differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavioral traits such as date format requirements and the need to use getTodayDate for today's dates, but lacks details on rate limits, authentication needs, or what the output contains (e.g., transfer options, times, costs). This is adequate but has clear gaps for a tool with no annotation coverage.
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 appropriately sized and front-loaded, starting with the core purpose followed by specific guidelines. Every sentence earns its place, though it could be slightly more structured (e.g., bullet points for clarity). No wasted words, making it efficient for an AI agent.
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?
Given no annotations and no output schema, the description provides basic context like parameter formats and tool alternatives, but lacks details on behavioral aspects (e.g., error handling, response structure) and doesn't fully compensate for the absence of structured data. It's minimally viable but incomplete for a tool with 3 parameters and complex usage.
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 parameters thoroughly. The description adds minimal value beyond the schema, mentioning date format and airport code standards, but doesn't provide additional semantic context or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose with specific verbs ('Get flight and train transfer info') and resources ('by departure city and arrival city and departure date'), distinguishing it from siblings like getFlightPriceByCities or searchFlightsByDepArr by focusing on transfer info rather than pricing or general flight searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'For today's date, you MUST use getTodayDate tool instead of hardcoding any date,' directly naming an alternative tool and specifying when to use it, which helps differentiate from siblings like getTodayDate and ensures correct parameter handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns today's date (not historical/future), uses local timezone (not UTC), and outputs in YYYY-MM-DD format. It doesn't mention error conditions, performance characteristics, or authentication needs, but for a simple date tool this is reasonably complete.
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 perfectly concise with two sentences that each earn their place: first states what the tool does with format/timezone details, second provides critical usage guidance. No wasted words, front-loaded with core functionality.
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 date-retrieval tool with no output schema, the description provides sufficient context: purpose, format, timezone, and usage guidance. It doesn't explain the return value structure beyond format, but for a simple string output this is adequate. The dummy parameter situation could be slightly confusing without schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 1 parameter with 100% schema description coverage, but the parameter is a 'Dummy parameter for no-parameter tools' according to the schema. The description correctly implies no meaningful parameters are needed by not mentioning any. It adds value by clarifying this is essentially a parameterless tool despite the schema structure.
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 clearly states the tool's purpose with specific verb ('Get') and resource ('today's date'), including format details ('YYYY-MM-DD format') and timezone context ('in local timezone'). It distinctly differentiates from sibling tools which are all flight/travel related, making this a standalone utility tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this tool whenever you need today's date - NEVER hardcode dates.' This gives clear when-to-use instructions and a specific prohibition against alternatives (hardcoding). No sibling tools overlap in functionality, so no comparative guidance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses key behavioral traits: the tool searches flights, requires valid IATA codes, and has specific date formatting rules. However, it doesn't mention potential limitations like result pagination, error handling, or authentication needs, leaving some gaps for a search tool.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific usage rules and format requirements. Every sentence adds necessary information without redundancy, making it efficient and well-structured.
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?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is mostly complete: it covers purpose, usage, parameter semantics, and format rules. However, it lacks details on output format (e.g., what data is returned) and error cases, which could be important for a search tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value by explaining the semantic difference between 'dep/arr' (airport codes) and 'depcity/arrcity' (city codes), and clarifies date handling (e.g., using 'getTodayDate' for today). This goes beyond the schema's technical descriptions, but doesn't fully cover all parameter interactions.
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 clearly states the tool's purpose: 'Search for flights between airports or cities by date.' It specifies the verb ('search'), resource ('flights'), and scope ('between airports or cities by date'), distinguishing it from siblings like 'searchFlightsByNumber' (which searches by flight number) and 'getFlightPriceByCities' (which focuses on prices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: it distinguishes between 'depcity/arrcity' for cities with multiple airports and 'dep/arr' otherwise, and explicitly mentions using 'getTodayDate' for today's date. It also implies usage for flight searches by location/date, not by number or price, which helps differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tripmatch-mcp MCP server](https://glama.ai/mcp/servers/variflight/tripmatch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/variflight/tripmatch-mcp)

Score Badge

Copy to your README.md:

[![tripmatch-mcp MCP server](https://glama.ai/mcp/servers/variflight/tripmatch-mcp/badges/score.svg)](https://glama.ai/mcp/servers/variflight/tripmatch-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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