Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

klook_search_hot_keywords

Fetch Klook hot search keywords and curated topic tabs for start pages, cities, or destination countries to support travel search discovery and navigation.

Instructions

Get Klook hot search keywords and topic tabs. Returns the hot search keywords Klook publishes for a search context, together with its curated topic tabs. Without country_id it reads the start-page set, scoped to city_id when one is supplied and unscoped otherwise; with country_id it reads that destination country's page instead and city_id is ignored. hot_words entries carry the keyword text, the exact query Klook records for it and a landing url when Klook publishes one (some hot words have no link). tabs are named lists of curated items (a raw tab key such as search_topics_popular, or Klook's display name for the curated tab that has no raw key), and each item carries its title, subtitle, icon, landing url and display price when present. An empty hot_words list is a valid answer, not an error.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "klook_search_hot_keywords"
  }
}

Input Schema

NameRequiredDescriptionDefault
city_idNoKlook city id from /klook/destinations or /klook/suggest to scope the start-page hot words; ignored when country_id is set
country_idNoKlook country id from /klook/destinations to read the destination-page hot words instead of the start-page set

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that an empty hot_words list is a valid answer rather than an error, that some hot words have no landing url, and that city_id is silently ignored when country_id is set. The 'Get' framing implies read-only but it is not stated explicitly, and nothing is said about auth, rate limits or paging.

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?

Front-loaded with what the tool returns, then the two read modes, then the entry shapes and the empty-result caveat — a sensible order with no filler. The third sentence is long and enumerates field names at some length, but each item clarifies the response shape for a tool with no output schema.

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?

There is no output schema, and the description compensates by describing both top-level return structures (hot_words entries with keyword, query and optional landing url; tabs as named lists of items with title, subtitle, icon, url and optional price). For a zero-required-parameter read tool, an agent has everything needed to call it and interpret the response.

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 100%, so the schema already documents both parameters and the baseline would be 3. The description earns above baseline by explaining the interaction the schema does not spell out: city_id only scopes the start-page set and becomes a no-op once country_id is present.

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 first sentence names a specific verb and resource ('Get Klook hot search keywords and topic tabs'), and the body distinguishes two distinct read modes (start-page set vs. destination-country page). It never names a sibling such as klook_hot or klook_suggest, so the agent must infer the boundary from the name and scope description alone.

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?

Guidance for choosing between the two invocation modes is explicit: omit country_id for the start-page set (optionally scoped by city_id), supply country_id to read the destination page, in which case city_id is ignored. What is missing is routing guidance relative to neighbouring tools — there is no statement of when to prefer this over klook_search, klook_hot or klook_suggest.

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

Deploy Server

Other Tools