Loading ToolBench
A multi-agent AI travel planning system built with LangGraph and FastAPI that provides travel planning, weather forecasting, and related services through both REST API and MCP server interfaces. Includes a dedicated MCP weather server providing weather warning and forecast tools.
This MCP server has serious definition quality gaps. Of 9 tool registrations, 4 are exact duplicates (tools 6-9 repeat tools 6 and 7). The 5 unique tools span two different servers (travel_tools.py and weather_server.py) with inconsistent quality. Tool descriptions are present but often verbose and written in Chinese, making them harder for English-language LLMs to reason about. Parameter descriptions lack specificity, no enums for constrained inputs, no clear format guidance, and several parameters accept strings without clear examples of valid values. Schemas are partially present but incomplete: no output schemas are documented for any tool, pagination is not addressed despite search tools returning lists, and there is no documentation of what fields clients should expect. Error handling is absent from tool definitions. Security considerations are not evident in the tool definitions.
获取指定位置的天气预报 参数: location (str): 位置信息，支持以下格式： - 中文城市名（如"北京"、"西宁"等，会自动转换为拼音再查找城市ID） - 城市拼音（如"xining"表示西宁，会自动转换为城市ID） - 城市ID（如"101010100"表示北京） - 经纬度坐标（如"116.41,39.92"） days (int): 预报天数，可选值为 3、7、10、15、30，默认为 3 返回: 格式化的天气预报字符串
获取指定位置的天气预报 参数: location: 城市ID或经纬度坐标（经度,纬度） 例如：'101010100'（北京）或 '116.41,39.92' 也可以直接传入数字ID，如 101010100 days: 预报天数，可选值为 3、7、10、15、30，默认为 3 返回: 格式化的天气预报字符串
获取指定位置的天气灾害预警 参数: location (str): 位置信息，支持以下格式： - 中文城市名（如"北京"、"西宁"等，会自动转换为拼音再查找城市ID） - 城市拼音（如"xining"表示西宁，会自动转换为城市ID） - 城市ID（如"101010100"表示北京） - 经纬度坐标（如"116.41,39.92"） 返回: 格式化的预警信息字符串
获取指定位置的天气灾害预警 参数: location (str): 位置信息，支持以下格式： - 中文城市名（如"北京"、"西宁"等，会自动转换为拼音再查找城市ID） - 城市拼音（如"xining"表示西宁，会自动转换为城市ID） - 城市ID（如"101010100"表示北京） - 经纬度坐标（如"116.41,39.92"） 返回: 格式化的预警信息字符串
Duplicate tool registrations: tools 6-9 are exact duplicates of tools 6-7. This creates tool naming conflicts and wastes schema space.
No output schemas documented. Tools are listed as returning strings (e.g., 'formatted weather string') but the actual JSON structure is not defined. LLMs cannot plan downstream composition or extract specific fields.
Descriptions are verbose, multilingual (Chinese), and lack clarity on WHEN to use each tool vs. similar alternatives. For example, search_destination_info, search_attractions, and search_weather_info all sound related to the same destination but their distinctions are unclear.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
搜索目的地景点和活动 这个工具专门用于搜索特定目的地的热门景点、 活动和必游之地，可以根据兴趣进行筛选。
使用DuckDuckGo搜索目的地信息 这个工具专门用于搜索旅行目的地的综合信息， 包括景点、旅游指南、文化背景等。
搜索酒店信息和价格 这个工具专门用于搜索特定目的地的酒店选择， 包括住宿选项、价格信息和最佳住宿地点。
搜索餐厅和用餐选择 这个工具专门用于搜索特定目的地的餐厅推荐， 包括当地美食、特色菜系和用餐地点。
搜索目的地天气信息 这个工具专门用于搜索特定目的地的天气预报信息， 包括气候条件、最佳旅行时间等。
Parameter 'location' in weather tools accepts 'string | integer' but no enum or format constraint. Description mentions multiple formats (city name, pinyin, city ID, coordinates) but does not specify which format is preferred or how the tool disambiguates. LLMs will guess.
Parameter 'days' in get_daily_forecast has a restricted set of valid values (3, 7, 10, 15, 30) but is declared as a plain integer type with no enum. Description mentions the constraint in prose, but LLMs cannot reliably parse prose constraints and often pass invalid values like 5 or 14.
No error handling guidance in tool definitions. What happens if location is invalid? If the weather API is unavailable? If days is out of range? Tool definitions do not communicate recovery paths.
Travel tools (search_*) do not document pagination. A destination search could return hundreds of results. Without limit/offset and total count, the LLM cannot fetch all results or manage large result sets efficiently.
Parameter defaults may cause unintended behavior. 'budget' defaults to '中等预算' (medium budget) and 'cuisine' defaults to empty string, these should be explicit or explained so LLMs do not misuse them.
Tool names use English (search_*, get_*) but descriptions and parameter names mix Chinese and English. This creates cognitive friction for English-language LLMs and inconsistent tool semantics.