Loading ToolBench
A Python-based MCP chatbot that integrates multiple MCP servers with LLM services for tool execution and conversation management
This server has significant definition quality gaps across all tools. Most tool descriptions are extremely brief (under 50 characters), parameter descriptions are minimal or missing context about valid values and formats, and no input schemas document expected structure or validation rules. No output schemas are documented. The tools span multiple languages (Chinese and English descriptions inconsistently), and critical tools like 'save_to_local' lack proper error guidance. Only 1 of 5 tools has a reasonably complete parameter schema with descriptions. The server's schema file shows MCPTool registration but actual tool implementations in services/*.py are not visible, making verification difficult.
get weather alerts for a US state.
获取指定时区或本地的当前时间
Get weather forecast for a location.
查询天气情况
保存问题和回答到本地文件
No output schemas documented for any tool. LLMs cannot infer what fields to expect or plan downstream tool calls. This violates the core pattern that tools must document their return structure.
Tool descriptions are too brief and lack context. 'Get weather forecast for a location' (32 chars) does not explain WHEN to use this vs get_weather, WHAT it returns, or whether it covers all geographies. Descriptions should be 50-200 characters and answer: what, when, what context is needed.
Parameter 'timezone' in get_current_time has a description ('IANA标准时区名称...') but lacks explicit format/pattern constraints. No mention of what happens on invalid input (e.g. 'invalid_tz'), whether empty string is allowed, or case-sensitivity handling despite claiming 'supports...case conversion'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter 'location' in get_weather accepts freeform string ('城市名称') with no validation or constraints. No specification of what regions are supported, whether partial names work, or how the tool handles ambiguous locations (e.g. 'Springfield' exists in multiple US states). LLM may pass arbitrary strings and get failures with no recovery guidance.
save_to_local is a WRITE operation but its description does not state this. LLMs need to know which operations modify state (and thus may have side effects when retried). The description also lacks error guidance: what happens if file_name is invalid, if directory doesn't exist, or if write fails? No guidance on recovery.
Inconsistent description languages and quality. 'get_current_time' and 'save_to_local' use Chinese descriptions; others use English. No parameter descriptions for 'state' in get_alerts beyond 'Two-letter US state code', no mention of what happens with invalid codes (e.g. 'XX', lowercase 'ca') or whether territories are supported.
No error handling or recovery guidance in any tool description. If get_weather fails for an invalid location, or save_to_local fails due to filesystem permission errors, the LLM has no direction on what to do next (e.g. 'Try search_locations() for valid names' or 'Check file permissions').
Tool definitions are inferred from the MCPClient.list_tools() output rather than directly visible in the source. The actual tool implementation files (services/weather_service_us.py, services/res_prompt_services.py, services/weather_service_zh.py) are not provided, so input validation, error handling, and output structure cannot be verified. This limits confidence in actual implementation quality.