Crawlora MCP

klook_suggest

Read-only

Return Klook autocomplete matches for a partial destination or activity name: matching activities with ids and category names, cities with city_id and country_id, and countries with listing URLs. query is required and must be 2 to 80 characters; limit caps the returned activities from 1 to 20 and defaults to 10. Use it when you only have a name and need an id, then pass a city_id to klook_search or an activity_id to klook_activity. Use klook_search for a real result page or klook_destinations for the full country and area inventory, and treat any of the three empty lists as a valid no-match answer.

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

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum activities to return, 1-20. Defaults to 10.
`query`	No	Text to complete. Required, 2-80 characters.

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.6/5.0

Behavior4/5

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

Annotations already cover read-only and open-world behavior, and the description adds a genuinely non-obvious trait: any of the three empty lists is a valid no-match answer rather than an error. It also discloses the query length bounds and the limit default/range. It does not discuss rate limits or match-ranking behavior, which keeps it just short of a 5.

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 routing guidance, then constraints; every sentence is load-bearing. It is dense but not padded, though the return-shape enumeration slightly overlaps what the output schema already declares.

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 an output schema exists, the description need not explain returns, yet it still tells the agent the sibling to use next, the required-ness of query, the limit default, and how to interpret empty results. Nothing needed to call this correctly is missing.

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 baseline is 3, but the description adds meaning the schema lacks — it declares query as required (the schema has no required array) and restates the 2–80 character and 1–20 limits in operational terms. That partially compensates for a real gap in the structured definition.

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 — "Return Klook autocomplete matches for a partial destination or activity name" — and enumerates exactly what comes back (activities with ids and category names, cities with city_id/country_id, countries with listing URLs). This is clearly distinguishable from klook_search and klook_destinations, which it names.

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 an explicit trigger ("when you only have a name and need an id"), the follow-up routing (pass city_id to klook_search, activity_id to klook_activity), and when-not alternatives (klook_search for a real result page, klook_destinations for full inventory). Nothing about tool selection is left to inference.

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.