How a foreigner books a specific Chinese attraction: real-name/passport requirement, ticket release time, whether it sells out, the OFFICIAL channel, and whether authorized resellers exist. Use for 'can foreigners book the Forbidden City / Terracotta Army / Mogao Caves and when do tickets release'.
| Name | Required | Description | Default |
|---|---|---|---|
| attraction | Yes | Attraction name, e.g. "Forbidden City". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses what information the tool returns (booking requirements, release times, sell-out status, official channel, resellers), which is helpful and gives expectations. However, it doesn't mention limitations like whether it covers all attractions, whether data is real-time, or any error conditions, so transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence front-loading the core value proposition and the second giving concrete usage examples. Every word contributes; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a simple one-parameter check tool with no output schema, the description covers the key aspects: the input (attraction) and the nature of the output (booking-related details). It lacks generic disclaimers about data availability, but for a tool of this complexity it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the 'attraction' parameter is described with an example). The tool description reinforces the example with Forbidden City etc., but adds no new semantic detail beyond what the schema already provides. Baseline 3 applies because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it provides information on how foreigners book specific Chinese attractions, covering real-name/passport requirements, ticket release time, sell-out status, official channels, and authorized resellers. It uses specific verbs and resource types, and the sibling tools (transit, city facts, travel playbook) are clearly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for' and gives concrete example queries ('can foreigners book the Forbidden City / Terracotta Army / Mogao Caves and when do tickets release'), which clearly indicates when to invoke this tool. It doesn't explicitly state exclusions or alternatives, but the provided use cases make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of travel information: specific attraction booking, transit eligibility, city facts, system-level playbook, and city search. There is no overlap or ambiguity between them.
All tools follow a consistent verb_noun pattern with underscores (e.g., check_attraction_booking, get_city_facts). The naming convention is uniform and predictable.
With 5 tools, the set is well-scoped for the domain of China travel facts. Each tool addresses a common question type without being overly numerous or sparse.
The tools cover key areas like attraction booking, transit eligibility, city facts, and system-level advice. Minor gaps exist, such as general visa information beyond transit or inter-city transport, but the core needs for a foreign traveler are addressed.
