Loading ToolBench
This server has fundamental structural and documentation issues that prevent confident production use. While tool definitions are technically present, the descriptions are minimal and lack crucial context for LLM agent selection. The schemas are present but incomplete, several tools have optional parameters without type information, and descriptions fail to document format constraints, dependencies, or when to use each tool instead of similar ones. Error handling exists but provides only generic failure responses without recovery guidance. The server lacks parameter-level descriptions in several critical tools, which violates pattern:tool-description baseline (100% of A+ tools document all parameters). Tool composition is reasonable (each does one thing), but the interface does not match the chat data model, for example, date parameters default to current date with silent fallback, which could mask errors. Overall, this is a competent domain-specific utility but falls short of production-grade tool engineering standards.
获取当前年份所有法定节假日
获取当前年份所有因调休导致需要上班上课的原休息日
根据公历日期计算星期几
查询指定日期的节假日信息，包含是否为节假日的判断 date: 查询日期，格式：YYYY-MM-DD，不指定则查询当前日期
获取距离指定日期最近的下一个节假日 date: 起始日期，格式：YYYY-MM-DD，不指定则使用当前日期
Parameter-level descriptions missing or incomplete across 4 of 5 tools. Pattern:tool-description baseline requires 100% of A+ tools to document all parameters. holiday_info, current_year_holidays, next_holiday, and current_year_work_days lack per-parameter documentation in schema; descriptions are embedded in tool description only.
Output schemas are not documented for any tool. LLMs cannot plan multi-step calls or extract the right data without knowing return structure. Pattern:tool requires documented output schemas. Code reveals tools return JSON strings (e.g., holiday_info returns {"date", "name", "type", "is_holiday", ...}, but LLM has no way to know this without reading implementation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Tool descriptions too terse to guide LLM selection. current_year_holidays (18 chars), current_year_work_days (27 chars), next_holiday (31 chars) all fall below baseline p10=34 chars. Descriptions state WHAT but not WHEN to use or prerequisites. Pattern:tool-description baseline minimum is 10 - 1024 chars with p10 starting at 34.
Date parameter validation relies on silent defaults. holiday_info and next_holiday default to current date if not provided ('if not date: date = datetime.now().strftime("%Y-%m-%d")'), which masks errors and could cause LLMs to skip required parameters without realizing it. Pattern:constrained-input recommends explicit validation and clear error messages.
Error responses lack recovery guidance. Code returns generic JSON errors like '{"error": "日期格式错误..."}' without suggesting next steps. Pattern:recovery-guide requires errors to tell LLM what to do next (e.g., 'Invalid date format. Use YYYY-MM-DD, e.g., 2024-01-15').
Semantic duplication: holiday_info returns weekday_name_en, and get_weekday also returns weekday_name_en. LLM cannot distinguish when to call each tool. Pattern:tool-chain requires tool names to make distinctions obvious (e.g., 'get_holiday_info' vs 'get_weekday' are clear; these are already somewhat distinguishable, but the overlapping weekday field invites confusion).
No pagination or result-count limits documented. current_year_holidays and current_year_work_days likely return arrays but lack limit/offset parameters and total count fields. Pattern:paginated-result baseline (p10=1, p90=8 params) and design principle require pagination for list tools.