Crawlora MCP

klook_search

Read-only

Search Klook travel activities and experiences by free-text query, destination city or category and return one page of normalized activity cards with activity id, title, canonical URL, price display strings, rating, review count, sold-out state and tags, plus the upstream total and current destination. Provide at least one of query, city_id or category_id: a free-text query runs Klook keyword search and can be combined with a city_id from klook_destinations or klook_suggest and a category_id from klook_categories, while a request without query browses that destination or category listing; a query with no matches returns an empty list, not an error. sort reorders the same result set, price_min and price_max must be supplied together, and page/per_page select the 1-based window with per_page from 1 to 50. Klook caps total at 10000 for broad queries, so treat it as a floor rather than a corpus size, and an empty activities list is a valid result. Use klook_activity with a returned activity_id for one card, or klook_suggest when you only need to resolve a name.

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"
  }
}

Input Schema

Name	Required	Description
`poi`	No	Optional Klook point-of-interest key from /klook/search/filters (des_id_list group), format p<digits>. Browse only: rejected together with query.
`page`	No	1-based result page. Defaults to 1.
`sort`	No	Result ordering. One of recommended, bestselling, top_rated, price_low_to_high, newest. Defaults to recommended.
`query`	No	Free-text activity search. At least one of query, city_id or category_id is required. Omit to browse a destination or category listing.
`city_id`	No	Klook city id from /klook/destinations or /klook/suggest. Filters results to that destination.
`end_date`	No	Optional latest participation date in RFC 3339 form, e.g. 2026-12-05T00:00:00Z.
`per_page`	No	Results per page, 1-50. Defaults to 20.
`price_max`	No	Optional maximum price in the response currency.
`price_min`	No	Optional minimum price in the response currency. Must not exceed price_max.
`start_date`	No	Optional earliest participation date in RFC 3339 form, e.g. 2026-12-01T00:00:00Z. Must not be after end_date.
`category_id`	No	Klook category id from /klook/categories. Narrows results to that category and its children.
`duration_tag`	No	Optional duration-bucket id from /klook/search/filters (duration_tag group).
`interest_tag`	No	Optional interest/topic id from /klook/search/filters (interest_tag group). Only valid when browsing a city or category, not with a free-text query.
`service_lang_tag`	No	Optional guided-language id from /klook/search/filters (service_lang_tag group).
`other_filters_tag`	No	Optional service/feature id from /klook/search/filters (other_filters_tag group).

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond readOnlyHint/openWorldHint, the description discloses the upstream total cap of 10000 for broad queries (treat as a floor, not corpus size), that an empty activities list is a valid result, and that sort reorders the same result set rather than changing it. Those are non-obvious behaviors an agent could otherwise misread as failure or truncation.

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?

Purpose and the required-at-least-one constraint are front-loaded, and almost every clause carries a real constraint. The middle section is dense and runs long, but no sentence is filler; tighter paragraphing would only marginally improve it.

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?

For a 15-parameter, open-world search tool this covers mode selection, filtering interactions, pagination, ordering and edge-case returns. With an output schema present it correctly avoids over-explaining the response shape while still flagging the meaningful return fields and the total cap.

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 parameter documentation is largely handled there and baseline 3 would apply. The description adds relational meaning the schema does not state per-parameter: price_min and price_max must be supplied together, page/per_page define a 1-based window within 1-50, and browsing vs. keyword mode changes which parameters are meaningful.

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?

States a specific verb and resource ('Search Klook travel activities and experiences') and enumerates what comes back (normalized activity cards with activity id, title, URL, price display strings, rating, review count, sold-out state, tags, upstream total). It also names the sibling it is not (klook_activity for a single card, klook_suggest for name resolution), so an agent can separate it from adjacent search tools.

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?

Gives explicit selection logic: at least one of query, city_id or category_id; a free-text query combined with a city_id/category_id from other tools vs. browsing a listing without query; klook_activity for one returned id; klook_suggest when only a name needs resolving. It even states the negative case (a query with no matches returns an empty list, not an error).

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

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.