TravelerLocal — China travel facts for foreign visitors

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

No annotations are provided, so the description bears full responsibility. It clearly describes a read-only informational tool that returns booking procedure details without indicating any side effects or mutations.

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?

Two efficient sentences: the first packs key information, the second provides concrete examples. No wasted words.

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 no output schema, the description adequately explains the return content (real-name/passport, release time, etc.) and usage examples. It lacks mention of error handling or edge cases but is sufficient for a simple lookup tool.

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?

Schema coverage is 100% with a clear parameter description. The tool description does not add further semantics beyond the schema, but the example value suffices for a single 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 explicitly states the tool's purpose: providing booking info for Chinese attractions for foreigners, listing aspects like real-name/passport, release time, etc. It distinguishes from sibling tools (e.g., check_transit_eligibility, get_city_facts) by focusing on attraction booking procedures.

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 includes example queries for specific attractions, clarifying when to use the tool. It implicitly excludes other travel planning tasks by listing sibling tools in different domains.

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

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

No annotations provided, so description carries full burden. It discloses that the tool returns eligibility, regional limits, and defining conditions. It does not mention side effects, rate limits, or auth needs, but for a read-only eligibility check this is sufficient.

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?

Two sentences: first defines scope and exclusion, second lists inputs and outputs. No wasted words, front-loaded with key distinction.

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?

No output schema, but description mentions return fields (eligibility, regional limits, conditions). All parameters are covered by schema and description. Tool is simple, so description is complete enough.

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?

Schema coverage is 100% with descriptions for all three parameters. The description adds context about the transit requirement (onward to third country) but does not significantly extend schema meaning. 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 explicitly states the tool checks eligibility for China's 240-hour visa-free TRANSIT, distinguishes it from the 30-day visa-free entry, and lists required inputs (nationality, port, onward ticket) and outputs (eligibility, regional limits, conditions).

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 clearly distinguishes this transit eligibility check from the 30-day visa-free entry, helping agents decide when to use it. It does not explicitly mention when not to use relative to sibling tools, but the sibling tools are unrelated, so context is adequate.

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

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

No annotations are provided, so the description bears full responsibility. It mentions the tool returns 'field-verified facts' and 'honest local notes', implying a read-only, informative operation. However, it does not disclose any behavioral traits such as permissions, rate limits, or side effects. This is adequate for a simple fact retrieval tool.

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 a single paragraph that efficiently conveys the tool's purpose, key data categories, and example use cases. It is front-loaded with the main function. Slightly dense but not overly verbose; every sentence earns its place.

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 no output schema and no annotations, the description covers the essential domains (attractions, booking, hotels, payments, local notes) and provides example queries. It is sufficiently complete for an AI agent to decide when to select this tool over siblings.

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?

There is only one parameter, 'city', with 100% schema coverage (description in schema: 'City name or slug, e.g. Beijing or lhasa.'). The tool description adds context about why the city is needed but does not add new semantic information beyond the schema. Baseline of 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 clearly identifies the tool as providing field-verified facts for a Chinese city, listing specific categories (attractions, booking, hotels, payments, local notes). It distinguishes from sibling tools like check_attraction_booking and check_transit_eligibility by covering a broader set of traveler needs.

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 example questions ('how do I book X in <city>', 'can foreigners stay in hotels in <city>'), providing clear guidance on when to use. While it doesn't explicitly state when not to use, the sibling tool names imply alternatives for specific queries.

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

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

No annotations are provided, so the description bears full burden. It indicates a read-like operation returning city names and URLs, but does not disclose pagination, rate limits, or behavior on no matches. Adequate for a simple search.

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?

Two sentences, no redundancy, front-loaded with the main action. Every word adds value.

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 search with one parameter and no output schema, the description covers purpose, returns, and use cases. Could mention fuzzy matching or case sensitivity, but overall adequate.

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?

Schema coverage is 100%, with the query parameter described as 'Partial city name or keyword.' The description adds context on what the search returns but does not enrich the parameter semantics beyond the schema. Baseline score of 3 applies.

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 the tool searches for cities that TravelerLocal has field-verified pages for, returns match names and URLs, and specifies use cases ('discover coverage' or 'resolve a place to a city'). It distinguishes from siblings like check_attraction_booking and get_city_facts.

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 provides two explicit use cases: discovering coverage and resolving a place to a city. While it doesn't explicitly state when not to use it, the sibling tools cover different areas, making the context clear.

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