Skip to main content
Glama

Search VoyageHacks travel guides

search_articles
Read-onlyIdempotent

Full-text search across the VoyageHacks travel guides, about 680 published pages per language, covering flights, airline reviews, hotels, destinations, car rental, trains, airport transfers, eSIM, travel VPN, travel credit cards, travel gear and month-by-month "where to go" guides. Returns ranked matches with the title, canonical URL, section and a matching excerpt for each. Useful when a travel question needs published prices, comparisons, best-time-to-visit advice or step-by-step detail that can be attributed to a source URL. It searches VoyageHacks content only: not the wider web, not live fares or hotel availability, and it returns no booking or product links.

Input Schema

NameRequiredDescriptionDefault
langNoLanguage of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to "en".
limitNoMaximum results to return. Defaults to 5.
queryYesSearch terms, e.g. "cheap hotels rome" or "esim japan". Matched against titles, keywords, tags and article text.
sectionNoRestrict results to one site section. Omit to search every section.

Output Schema

NameRequiredDescriptionDefault
langYes
queryYes
resultsYes
sectionNo
resultCountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / lang / enum
      Previous value: -[
      -  "en",
      -  "de",
      -  "fr",
      -  "es",
      -  "it",
      -  "pl",
      -  "cs",
      -  "ja",
      -  "nl",
      -  "pt",
      -  "zh"
      -]New value: +[
      +  "en",
      +  "de",
      +  "fr",
      +  "es",
      +  "it",
      +  "pl",
      +  "ja",
      +  "nl",
      +  "pt",
      +  "zh"
      +]
  2. Changed6 schema fields changed
    • changedInput schema / properties / lang / description
      Previous value: -"Content language for the guides that come back (default \"en\")"New value: +"Language of the VoyageHacks guides returned. One of: en, de, fr, es, it, pl, cs, ja, nl, pt, zh. Defaults to \"en\"."
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 5)"New value: +"Maximum results to return. Defaults to 5."
    • changedInput schema / properties / query / description
      Previous value: -"Search terms, e.g. \"cheap hotels rome\" or \"esim japan\""New value: +"Search terms, e.g. \"cheap hotels rome\" or \"esim japan\". Matched against titles, keywords, tags and article text."
    • addedInput schema / properties / query / maxLength
      Added value: +300
    • addedInput schema / properties / section
      Added value: +{
      +  "description": "Restrict results to one site section. Omit to search every section.",
      +  "enum": [
      +    "flights",
      +    "airlines",
      +    "hotels",
      +    "destinations",
      +    "car-rental",
      +    "trains",
      +    "transfers",
      +    "esim",
      +    "vpn",
      +    "credit-cards",
      +    "travel-gear",
      +    "adventure",
      +    "travel-types",
      +    "when-to-go",
      +    "styles",
      +    "answers",
      +    "checklists",
      +    "deals"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "lang": {
      +      "type": "string"
      +    },
      +    "query": {
      +      "type": "string"
      +    },
      +    "resultCount": {
      +      "type": "integer"
      +    },
      +    "results": {
      +      "items": {
      +        "properties": {
      +          "lang": {
      +            "type": "string"
      +          },
      +          "section": {
      +            "type": "string"
      +          },
      +          "snippet": {
      +            "type": "string"
      +          },
      +          "title": {
      +            "type": "string"
      +          },
      +          "url": {
      +            "description": "Canonical URL, safe to cite.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "title",
      +          "url"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "section": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "query",
      +    "lang",
      +    "results"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so the safety profile is covered; the description adds what the annotations cannot — the corpus size, that results are ranked and include title/URL/section/excerpt, and explicit scope boundaries the agent would otherwise have to discover by calling. It doesn't mention pagination or behavior when a query yields zero matches, keeping it out of 5 territory.

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?

Three sentences, all front-loaded with the core capability first, then return shape, then exclusions. The long topical enumeration in sentence one is the only mild bloat, but it earns its place by telling the agent what kinds of questions the corpus can answer.

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?

An output schema exists, so return values needn't be explained further, and the description still summarizes them. With rich annotations, 100% schema coverage and a sibling family of link-fetchers, the description supplies everything an agent needs — corpus scope, ranking, attribution, and what it cannot answer — before calling.

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 query, lang, limit and section are all documented in the schema itself, making 3 the baseline. The description's enumeration of topics (flights, hotels, car rental, eSIM, 'when to go', etc.) loosely maps to the section enum values and adds marginal meaning, but it doesn't explain per-parameter behavior such as matching against titles/keywords/tags or how limit interacts with ranking.

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?

Specific verb ('Full-text search') plus a precisely scoped resource (VoyageHacks travel guides, ~680 pages per language), with the topic taxonomy enumerated so the agent knows exactly what corpus it hits. It clearly distinguishes itself from get_article (which fetches a page) and the link-lookup siblings by being a discovery/search surface.

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?

Gives a positive usage trigger ('when a travel question needs published prices, comparisons, best-time-to-visit advice or step-by-step detail that can be attributed to a source URL') and clear negative exclusions ('not the wider web, not live fares or hotel availability, no booking or product links'). It never names a specific sibling tool to use instead (e.g. get_booking_links for actual fares), so it stops short of full when/when-not routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.