Loading ToolBench
Huaxingzhi: explainable, source-aware China inbound travel planning, data, CLI, HTTP API, and MCP server
The server provides 9 tools with complete input schemas and descriptions visible in china_travel_kit/mcp.py. Tool names follow verb_noun conventions (recommend_trip, search_spots, discover_areas, get_city_guide, plan_itinerary, get_trip_preparation, get_emergency_help, check_data_freshness, check_package_integrity). Descriptions are present for all tools and most parameters. However, several tools lack parameter-level descriptions, and output schemas are not documented. The domain is well-scoped (read-only travel planning), but parameter coverage and output documentation gaps prevent a higher score. Error handling is minimal, most tools appear to assume successful execution without recovery guidance.
List unverified or stale records so callers can avoid presenting old facts as current.
Verify the official release manifest and detect missing or modified repository files. This detects tampering but does not prevent copying.
Find bilingual stay areas and attraction neighborhoods by province or city. This does not expose residential or personal data.
Get transport, seasonal, food, culture, stay-area, and emergency guidance for a covered city.
Return sourced emergency numbers and bilingual usage guidance for a covered city. Recheck local handling before travel.
Get bilingual seasonal clothing, gear, risk, stay-area, food, culture, and transport guidance. This is not live weather or medical advice.
Output schemas not documented. No LLM guidance on what fields to expect from tool responses. Rubric baseline: 100% of A+ tools have documented return types.
Parameter-level descriptions largely missing or incomplete. Many parameters (e.g., 'keyword', 'city', 'category' in search_spots; 'days', 'interests' in plan_itinerary) lack inline descriptions explaining their purpose and constraints. Rubric: 100% of A+ tool params have descriptions.
No error handling or recovery guidance. Tool descriptions lack statements about what to do on failure, missing data, or invalid inputs. Rubric: Error responses must tell the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Create an explainable rule-based draft. Always verify live hours, bookings, weather, and transport.
Automatically rank covered cities and create an explainable trip draft from party size, dates, desired places, interests, pace, budget, mobility needs, and free text. Live bookings and transport still require verification.
Search source-aware sample travel data. Results are not live availability or navigation data.
recommend_trip parameters lack clarity on mutual exclusivity. 'start_date' + 'end_date' vs 'month' + 'days' are alternative input modes, but the schema and description do not document this dependency. Agents may pass both unnecessarily.
Several tools return travel data without pagination/limit guidance. search_spots, discover_areas, and get_city_guide may return large unstructured result sets. Rubric baseline: Tools returning lists should accept page/offset and limit parameters.
Tool descriptions mention 'not live' or 'requires verification' but do not offer clear next steps for the LLM. E.g., 'Always verify live hours, bookings, weather, and transport' is a warning, not actionable guidance on which tools or external services to check.