Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

klook_attractions_highlights

Fetches curated Klook attraction highlight sections for a city or country, including bestsellers, same-day bookings, deals, and kid-friendly picks with top activity cards.

Instructions

List curated Klook attraction highlight sections. Returns Klook's curated attraction highlight sections (Bestsellers, Book for today or tomorrow, New experiences, deals, date ideas, great for kids) for a city or a country, each with its top activity cards, plus the section-list button text and URL. A scope is required: type defaults to city when city_id is supplied and country otherwise, and the id must match the requested type. Unscoped highlights are rejected upstream.

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

Input Schema

Name	Required	Description
`type`	No	Highlight scope
`city_id`	No	Klook city id; required when type is city
`country_id`	No	Klook country id; required when type is country

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A4/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 behavioral burden and does well by explaining the returned content: section names, top activity cards, and section-list button text and URL. It also discloses the scope-validation behavior and upstream rejection of unscoped requests. It does not mention authentication or rate limits, but for a read-only listing tool the key behavioral context is present.

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?

The description is front-loaded and appropriately sized: it states the resource, enumerates the section types, describes the return payload, and then gives scope rules. The first two sentences overlap somewhat because 'List curated...' and 'Returns Klook's curated...' restate the same action, but the redundancy is mild.

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?

For a three-parameter tool with no output schema and no annotations, the description is complete enough to call correctly: it explains the return structure, the scope requirement, defaulting behavior, and type/id matching. It could be stronger only by mentioning edge cases beyond the unscoped rejection, such as behavior when both ids are supplied.

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 parameter meanings are already documented, but the description adds meaningful semantics by explaining the default type behavior when city_id or country_id is supplied and the requirement that the id match the type. This goes beyond the schema's basic field descriptions.

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 description uses a specific verb and resource: it lists curated Klook attraction highlight sections and names concrete section types such as Bestsellers and Book for today or tomorrow. It is clear what the tool returns, though it does not explicitly distinguish itself from sibling tools like klook_attractions_categories or klook_attractions_destinations.

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?

The description gives clear usage constraints: a scope is required, type defaults based on which id is supplied, the id must match the requested type, and unscoped highlights are rejected upstream. It does not name alternative tools for different attraction-discovery needs, but the conditions for valid use are explicit.

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

Deploy Server