Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

klook_verticals

Lists Klook's product verticals and nested child entries with type keys, labels, icons, and listing links, so you can discover product families and find valid things_to_do template_id values.

Instructions

List Klook product verticals. Returns Klook's navigation vertical menu: the top-level product verticals (Things to do, WiFi & SIM Card, Transportation, Train Tickets & Passes, Food & Dining) with every child entry nested. Each entry carries Klook's own type/template key, display label, icon key and absolute listing link. Use the menu to discover which product families Klook currently sells; the things_to_do children are the template_id value space the search page accepts.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

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 disclosure burden and does well: it describes the exact payload (type/template key, display label, icon key, absolute listing link), the nesting structure, and the cross-tool linkage to template_id values. It does not explicitly state read-only/non-mutating behavior or auth needs, though "List/Returns" strongly implies a safe read.

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?

Three sentences, front-loaded with purpose before payload details, and no filler. The middle sentence is dense with field listings but each item earns its place by describing the return payload that has no output schema.

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 zero parameters, no annotations, and no output schema, the description must explain the payload itself, which it does thoroughly, including entry fields and nesting. Pagination, error behavior, and an explicit read-only statement are absent, but these are minor for a static menu listing.

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?

The tool takes no parameters, so the baseline is 4. The description adds no parameter information because none exists, which is appropriate, and instead spends its words on the output shape.

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 opens with a specific verb and resource ("List Klook product verticals") and immediately clarifies the resource is the navigation vertical menu with nested children, which distinguishes it from flat catalog tools like categories or destinations. It stops short of naming any sibling tool explicitly, so differentiation is implied rather than stated.

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?

"Use the menu to discover which product families Klook currently sells" gives a clear usage context, and the pointer that things_to_do children form the template_id value space accepted by the search page makes the tool's role in a larger workflow explicit. There are no exclusions or named alternatives, so it falls short of a full when/when-not treatment.

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