Loading ToolBench
Backend service for Worry-Free-Travel application with AI agent for intelligent recommendations and intent understanding
This MCP server exhibits severe definition quality gaps across both tools. While 2 tools are identified (get_rate_limit, chat), the source code provided contains NO actual tool implementation code, only Maven pom.xml files and requirements.txt. The tool definitions appear to be inferred from the metadata in the prompt rather than directly visible in source code. Critical issues: (1) Tool implementations are not visible in the provided source; (2) descriptions are minimal and do not explain WHEN/WHY to use the tool; (3) no input validation or constraints are documented; (4) no output schemas are specified; (5) no error handling guidance is provided; (6) parameter descriptions are sparse. The 'chat' tool description is in Chinese and minimal. The 'get_rate_limit' tool has only a key parameter with basic documentation. Neither tool shows structured return types or pagination support.
智能客服聊天接口 —— 用户以自然语言输入需求，系统识别意图并返回推荐结果。
查询限流状态
Tool implementations not visible in source code. Only Maven/Python configuration files provided; actual tool handler code is missing. Cannot verify schema enforcement, error handling, or return types.
Descriptions are extremely brief and lack WHEN/WHY context. 'get_rate_limit' description is 21 chars; 'chat' description is in Chinese and provides no actionable guidance for LLM tool selection.
No output schemas documented. LLMs cannot determine what fields to expect from these tools or plan downstream calls. Baseline for A+ tools: 100% have documented return types.
Parameter descriptions are sparse and lack validation constraints. The 'key' parameter in get_rate_limit has minimal documentation; 'query', 'user_id', and 'conversation_id' in chat lack detail about expected format, length, or valid patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
No error handling guidance. What happens if rate limit is exceeded? What if chat query is malformed or user_id doesn't exist? LLM has no recovery path.
Tool names are vague. 'chat' is generic and does not follow verb_noun pattern (should be 'send_message', 'query_support', or similar). This violates the baseline where 90% of A+ tools start with specific action verbs.
No pagination support documented for tools that may return multiple results. If 'chat' returns conversation history or 'get_rate_limit' returns details, no limit/offset/next_cursor parameters are declared.
Tool composition unclear. Is 'chat' a single-turn query or multi-turn conversation? Does it maintain state via conversation_id? Does it perform intent detection and recommendations? Undocumented dependencies make it hard for LLMs to compose correctly.