Search the cities TravelerLocal has guide pages for. Returns matching city names and page URLs. Use to discover coverage or resolve a place to a city.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Partial city name or keyword. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses the tool searches for cities that have guides, returns matches, and is used for discovery/resolution. However, it doesn't explain search behavior nuances (case sensitivity, partial match rules, ordering, or if no match is found). The description adds value but leaves some behavioral gaps.
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?
Three sentences, each serving a distinct purpose: what the tool does, what it returns, when to use it. Zero waste, perfectly front-loaded.
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?
For a simple fuzzy search tool with one parameter, the description covers purpose, return format, and usage contexts. No output schema exists, but the return format (city names + URLs) is simply stated. Very minor gap: doesn't mention edge cases like no results.
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 already has 100% coverage (query described as 'Partial city name or keyword'), so the description's mention of 'matching city names and page URLs' adds context about the return, but doesn't enhance parameter understanding beyond what the schema provides. Baseline 3 is appropriate.
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 uses specific verbs ('Search', 'Returns') and a clear resource ('cities TravelerLocal has guide pages for'), making the tool's purpose immediately obvious. It also distinguishes itself from siblings by focusing on city discovery rather than facts, booking, or transit checks.
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 gives explicit usage contexts: 'discover coverage' (finding which cities have guides) and 'resolve a place to a city' (mapping a place to a named city). It implicitly states when to use this tool (when you need to find a city or check coverage) without explicit negatives, but doesn't mention when not to use it (e.g., if you need city facts, use get_city_facts).
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.
