trip-search-mcp

by nanwer

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct domain or action: flight searching, price watching, stays, activities, events, weather, and currency conversion. There is no overlap between tools; even the flight-related tools (search_flights, search_cheapest_dates, watch_flight_price, list_active_watches, cancel_watch) have clearly differentiated purposes.
Naming Consistency3/5
Tool names use a mix of verb styles: 'search_' for five tools, 'get_' for two, and individual verbs like 'cancel_', 'convert_', 'list_', and 'watch_'. While each name is clear, the lack of a uniform pattern makes the set slightly less predictable.
Tool Count5/5
With 11 tools, the server covers essential trip planning needs—flight search, price monitoring, stay search, activities, events, weather, and currency conversion—without unnecessary bloat. The count is well-scoped for its domain.
Completeness4/5
The tool surface covers core trip planning tasks comprehensively. Minor gaps exist: get_activity_details is referenced but not implemented, and there is no tool for booking flights or stays (though that may be out of scope). Overall, agents can accomplish most planning workflows without dead ends.
Average 4.8/5 across 11 of 11 tools scored.
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 is passing
This repository is licensed under MIT 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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses caching behavior (5-minute cache), date validation (rejects past dates), meaning of null fields (baggage_allowance, etc.), timezone handling (local times with IATA codes), city code expansion, and detailed filter semantics. No contradictions with annotations since none exist.
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 well-structured with clear sections but is overly long, including a rendering directive and pre-call elicitation that could be separated. While every sentence adds value, the length reduces conciseness. It front-loads the most important info but could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, 3 required, output schema exists), the description covers all critical aspects: parameter semantics, behavioral nuances, error handling, caching, and result presentation. It is comprehensive and leaves no major gaps for an AI agent to misuse the tool.
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 0%, so the description must compensate. It explains critical parameters like origin/destination (IATA and city codes), max_stops (with exact meanings), departure_window and inbound_window (inclusive-start/exclusive-end semantics), and airlines filter behavior. However, it does not explain simpler parameters like adults, children, infants, cabin_class, and max_results, leaving some gaps.
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 live flight offers for a given route and date range using Google Flights data.' It uses a specific verb ('search') and resource ('flight offers'), and implicitly distinguishes from sibling tools like search_cheapest_dates and watch_flight_price by focusing on live searches for specific routes and dates.
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 extensive 'PRE-CALL ELICITATION' guidance on what user preferences to collect before calling, which indirectly informs when to use the tool. However, it does not explicitly contrast with sibling tools or state when not to use this tool, missing a direct exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It extensively covers: use of SerpAPI with parallel calls for 'all' category (~3s latency, 2x quota cost), airbnb category being slower and more fragile, default currency (EUR), filter scoping (min_rating only hotels, etc.), address always null, review scale 0-5, sort_by options, rendering requirements (artifact with cards, no images due to hotlink protection), and warnings handling. No contradictions are present.
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 very long and verbose, containing extensive sections on pre-call elicitation and result presentation that could be abbreviated or separated. While well-organized (rendering directive first, then purpose, parameters, usage context), its length may overwhelm quick parsing. Not every sentence is essential; some repetition occurs (e.g., category descriptions appear in multiple places). Conciseness is moderately compromised.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, 4 categories, filter scoping, rendering rules, output schema exists), the description is exceptionally complete. It covers input semantics, behavioral traits, output form, rendering directives, pre-call elicitation, and warning handling. The presence of an output schema reduces the need to describe return values. Sibling differentiation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully document parameters. It does so comprehensively: explains each category value, sort_by options, filter applicability (min_rating for hotels, min_bedrooms/min_bathrooms for rentals), currency override, and max_price_per_night. It also clarifies that 'address is always null', 'review_score is 0-5', and provides conversion guidance. All 16 parameters are effectively covered.
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 function: 'Search Google's hotel AND vacation rental listings for a city, date range, and party size, returning a ranked unified list of available places to stay.' It explicitly distinguishes itself from siblings like search_flights and get_stay_details by specifying it searches for stays across hotels and vacation rentals, and it does not book reservations.
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 detailed guidance on when to use this tool, including a 'PRE-CALL ELICITATION' section that instructs the agent to confirm parameters like category, location, dates, etc., with the user. It differentiates between categories (all, hotels, vacation_rentals, airbnb) and specifies when each is appropriate. However, it does not explicitly mention that get_stay_details should be used for more details on a specific property, which would strengthen usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses important behaviors: weekend/holiday rate staleness, daily ECB updates at 16:00 CET, 29+ currencies, error handling (invalid_input), and return field details. This exceeds basic expectations.
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?
Description is well-structured with clear sections (USE THIS TOOL WHEN, Inputs, Returns, Powered by, RESULT PRESENTATION). However, it is somewhat verbose; a few redundant phrases could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 params and no annotations, the description covers all essential aspects: inputs, outputs, behavior, source, limitations (weekend rates), and presentation guidelines. The presence of an output schema reduces the need for return value details, but the description still adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description must compensate. It provides full semantics: amount is numeric >0, from_currency and to_currency are 3-letter ISO uppercase with examples. Also states error condition for unrecognized currencies.
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 it converts a numeric amount between two ISO 4217 currencies using ECB rates. The verb 'convert' is specific and resource is well-defined. No sibling tool performs conversion, so distinction is clear.
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 explicitly lists three usage scenarios ('USE THIS TOOL WHEN') including direct conversion requests and mixed-currency totals. It does not provide negative guidance (when not to use) or alternatives, but given sibling tools are unrelated, this is sufficient.
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, the description carries the full burden. It discloses result format (sorted list of date combinations and price), what is not returned (flight details), parameter semantics (e.g., departure_window exclusivity, airline filter behavior), currency behavior, and performance implications. It does not explicitly state the tool is read-only, but the context implies it, and the level of detail is high.
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 well-structured with section headers and bullet points, front-loading the purpose. However, it is somewhat verbose, particularly the rendering directive and pre-call elicitation sections, which could be condensed without losing essential guidance. Nonetheless, every part serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema present), the description is complete. It covers purpose, usage, parameter details, output format (list of entries with date and price), rendering guidance, and follow-up actions. The presence of an output schema reduces the burden, but the description still explains the output structure adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only types and defaults with 0% description coverage. The description compensates thoroughly by explaining every parameter's meaning, format, and behavior, including edge cases like trip_duration requirement for round trips, departure_window exclusivity, airlines filter semantics, and default values. This adds significant value 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?
The description clearly states the tool's purpose: 'Find which travel dates are cheapest across a flexible range' and distinguishes it from the sibling tool 'search_flights' by explicitly stating what it does not return and providing usage scenarios. The verb 'find' and resource 'cheapest travel dates' are specific and unambiguous.
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 includes explicit sections 'USE THIS TOOL WHEN' and 'USE search_flights INSTEAD WHEN' with typical user phrasings, and provides a 'PRE-CALL ELICITATION' section detailing required user inputs. This offers comprehensive guidance on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavioral traits: persistence across restarts via SQLite, refresh frequency controlled by list_active_watches, single API call per refresh, and alerting condition (price ≤ threshold).
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 relatively long but well-structured with clear sections (USE THIS, DO NOT USE, Inputs, Returns, PRE-CALL ELICITATION). It is front-loaded with the main purpose. Slightly verbose but still effective.
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 10 parameters, 4 required, and no schema descriptions, the description covers crucial aspects: watch behavior, parameter semantics for threshold and currency, return value (watch_id), persistence, and pre-call elicitation. Could elaborate on more parameters, but the reference to search_flights mitigates this.
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 0%, but the description explains key parameters: threshold_price, currency, and note. It states inputs are the same shape as search_flights for origin, destination, etc., though not all 10 parameters are individually described. The cross-reference is acceptable.
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 registers a persistent watch on a flight route, departure date, and price threshold. It distinguishes itself from sibling tools like search_flights (one-off) and list_active_watches (listing/refreshing).
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?
Explicitly provides when-to-use scenarios (e.g., 'watch this route') and when-not-to (one-off searches, redirecting to search_flights). Also suggests alternatives like search_cheapest_dates for flexible dates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses: costs 1 SerpAPI quota call, caching with TTL ~5 min, that address is NOT in response, and returns a single object not a list. No contradictions with annotations (none exist).
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 relatively long but well-structured: starts with rendering directive, then purpose, usage guidelines, return fields, and caveats. Every sentence adds value, though the rendering directive could be considered separate guidance for the agent's response rather than tool behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, extensive output schema with nested objects, caching, quota), the description covers all essential aspects: input parameters, output fields, usage boundaries, and behavioral notes. It also mentions what is NOT returned (address). Output schema exists but description adds context beyond it.
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 coverage is 0%, but description explains that property_token is 'copied from any offer in a search_stays response' and that dates and adults should match the original search. It provides meaning beyond schema for key parameters, though it doesn't explicitly describe currency (default provided in 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?
The description clearly states: 'Fetch rich per-property details for a single stay (hotel or vacation rental) the user has already seen in a search_stays result.' It uses specific verb (fetch) and resource (per-property details for a single stay), and distinguishes itself from sibling search_stays by specifying it is for a single property already selected.
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 explicitly states when to use: 'USE THIS TOOL WHEN: the user has narrowed down to a specific property...', and when not to use: 'DO NOT USE THIS TOOL WHEN: the user is still browsing or hasn't specified a property. Use search_stays first.' It provides clear context and an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully carries burden: explains data source (Open-Meteo), no API key needed, geocoding via Nominatim, default date behavior, hard 7-day cap, output structure, and rendering rules. No contradictions.
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?
Description is very long (800+ words) with redundancy between rendering directive and result presentation. However, it uses clear sections and bullet points, so readability is okay but conciseness suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description still thoroughly explains return fields, rendering guidelines, and pre-call behavior. Covers all key aspects for correct tool invocation and result usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description compensates by detailing each parameter (location, lat/lon, start/end dates, units) with defaults, examples, and constraints (e.g., hard cap). Adds significant meaning beyond 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?
Clearly states it fetches a 7-day weather forecast for a city or coordinates. Distinct from siblings like search_activities, search_events. Includes specific verb and resource.
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?
Explicit 'USE THIS TOOL WHEN' section with three clear scenarios (trip planning, date comparison, enriching context). Also has 'PRE-CALL ELICITATION' with date handling defaults, providing strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: re-runs watches, flips status, costs one call per refresh, bounded by refresh_after_hours, forced refresh option. It also details return fields and side effects.
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 overly long with rendering directives and result presentation tips that could be separate. It is well-structured but not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: purpose, usage, parameters, behavior, return fields, and even rendering suggestions. It is complete given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains both parameters: include_cancelled for listing cancelled watches, and refresh_after_hours for refresh frequency, including the forced refresh usage.
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 lists active flight price watches, re-runs old checks, and flips status on threshold hits. It distinguishes itself from siblings like cancel_watch and watch_flight_price.
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?
Explicit usage examples are given: user queries like 'any deals?' or 'show my watches', and proactive use at session start. It provides clear context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: data source (Google via SerpAPI), output structure (EventOffer fields), rendering constraints (artifact vs prose), image handling (hotlink warning), and pre-call logic. No contradictions and exceeds the burden for safe invocation.
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 well-structured with clear sections and a front-loaded rendering directive. However, it is quite verbose; some instructions could be condensed without losing clarity. Still, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (described in text), the description is exceptionally complete: covers purpose, usage, parameters, output fields, rendering behavior, sibling differentiation, and pre-call elicitation. No obvious gaps remain for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully: explains `location` as free-text, `query` with examples, `date_filter` with enum values and usage warnings, and `max_results` with default and range. Pre-call elicitation clarifies mapping from user requests to parameters.
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 a specific verb ('Search Google for') and resource ('time-bound events'). It explicitly distinguishes from the sibling tool `search_activities` by contrasting time-bound events with ongoing activities, leaving no ambiguity.
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 includes a dedicated 'USE THIS TOOL WHEN' section with specific user query examples, and explicitly contrasts with `search_activities`. Pre-call elicitation rules further guide parameter selection, making usage conditions extremely clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: watch is marked cancelled (not deleted), return format on success, and implication of being able to retrieve cancelled watches. This goes beyond minimal disclosure.
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?
All sentences are valuable, front-loaded with core action, then examples, return format, and additional guidance. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 1 param and no annotations, the description covers purpose, usage, behavior, parameter meaning, and return format comprehensively. Output schema is described in-line.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter watch_id is explained beyond the schema: it is the ID from watch_flight_price or list_active_watches. Since schema coverage is 0%, the description compensates fully.
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 cancels a flight price watch by watch_id, with specific verb and resource. It distinguishes from siblings like watch_flight_price and list_active_watches.
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?
Provides explicit usage scenarios (e.g., 'stop watching that route'), tells when to use list_active_watches first, and clarifies that cancelled watches are not deleted and can be listed with include_cancelled=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses limitations (no coordinates/price), rendering directive, pre-call elicitation strategy, and return format details beyond the input schema, fully compensating for missing 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?
Well-structured with front-loaded rendering directive, sections for usage, inputs, returns, and presentation. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers rendering, parameter details, return field descriptions, limitations, and pre-call behavior, making it self-sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, each parameter is explained with context and examples (e.g., query accepts natural language, place_type_filter enum values, min_rating excludes unrated results).
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?
Clearly states it searches Tripadvisor's 'Things to Do' with specific verb 'Search' and distinguishes from sibling tool `search_events` by contrasting ongoing activities vs date-specific events.
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?
Explicitly lists when to use ('what should I do in X', 'things to do in X', etc.) and when not to (use search_events for date-specific events), plus three detailed pre-call branches.
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:

[![trip-search-mcp MCP server](https://glama.ai/mcp/servers/nanwer/trip-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nanwer/trip-search-mcp)

Score Badge

Copy to your README.md:

[![trip-search-mcp MCP server](https://glama.ai/mcp/servers/nanwer/trip-search-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nanwer/trip-search-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/nanwer/trip-search-mcp'

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