Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

klook_search_unified

Search Klook across destinations, activities, and service shortcuts using a partial query, returning typed suggestions and landing URLs for city or activity lookups.

Instructions

Search Klook across product verticals. Returns Klook's platform search-box suggestions for a partial query: destination cities, keyword suggestions, vertical-service shortcuts (airport transfers, hotels, rail passes and similar) and matching activities in one list. Each suggestion carries a normalized type (destination, keyword, vertical_service, activity or other), Klook's raw upstream type code in upstream_type, and an absolute landing url. Vertical-service entries can carry Klook's own template placeholders such as {dest_city_id} in their url; they are served as-is, so substitute a real id only if you know that vertical's own parameter shape. A query with no matches returns an empty suggestions list. Use a destination suggestion's id with /klook/search (city_id), or an activity suggestion's id with /klook/activities/{activity_id}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "klook_search_unified"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesPartial text to suggest for, 1-80 characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.7/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does disclose real behavior: the merged list shape, the normalized type field, the raw upstream_type passthrough, absolute landing urls, the fact that vertical_service urls may contain unsubstituted template placeholders served as-is (with an explicit warning about substituting ids), and that zero matches yields an empty suggestions list rather than an error. That covers the failure and data-shape quirks an agent would otherwise be surprised by. It omits auth/pagination/rate-limit characteristics, which keeps it below 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 purpose and return content, then edge case, then downstream usage — a sensible ordering with no filler sentences. It is dense (one long paragraph) and the placeholder caveat is somewhat verbose, but every clause carries operational information rather than restating the name.

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?

With no output schema and no annotations, the description compensates well by documenting the response item structure, the type/upstream_type fields, urls, the empty-result case, and the follow-up call for each relevant suggestion id. What remains unaddressed is its relationship to the many sibling search/suggest tools, which is relevant context for an agent choosing among them.

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% and the single `query` parameter already documents itself as partial text of 1-80 characters. The description reinforces the semantics ("partial query", "partial text to suggest for") but adds no format, encoding, or example guidance beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a concrete verb and resource ("Search Klook across product verticals") and then narrows it to what is actually returned: platform autocomplete suggestions for a partial query. The enumeration of suggestion kinds (destination, keyword, vertical_service, activity) makes the tool's identity clear, and a reader can infer this is autocomplete rather than a full search. It never explicitly names the close siblings (klook_suggest, klook_search) to draw the boundary, so it stops just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by "partial query" and "search-box suggestions", which tells an agent to reach for this during prefix/typeahead flows. The final sentence gives genuine downstream routing advice (destination id to /klook/search, activity id to /klook/activities/{activity_id}). However, there is no explicit statement of when NOT to use it or how it differs from the sibling suggest/search tools, leaving the selection decision to inference.

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