Loading ToolBench
Mixed quality with significant structural issues. Tool naming follows verb_noun conventions (fetch_, load_) which is good. However, descriptions are inconsistent in quality and detail. Schema documentation exists for most tools but lacks output schema documentation. Parameters are typed but descriptions vary from minimal to adequate. The server exposes multiple data-fetching tools with overlapping responsibilities, suggesting composition concerns. Parameter descriptions often lack constraints, ranges, or format specifications that would guide LLM behavior.
批量获取并生成报告的核心驱动程序
获取股票数据
获取股票列表
获取单只股票的数据
批量获取股票数据（同步版本）
异步批量获取股票数据
加载股票原始数据
Overlapping tool responsibilities: load_raw_data, load_data_msd, load_data_msd_batch, load_data_msd_batch_async, fetch_stock_data all fetch stock data with unclear semantic differences. LLMs will struggle to select the correct tool.
Minimal descriptions for discovery tools: fetch_stock_list has only 8 characters ('获取股票列表' = 'Get stock list'). Too vague, no explanation of when to use it, what structure it returns, or prerequisites.
Parameter descriptions lack constraints and format guidance: 'host' in fetch_batch_reports has no description of valid values or format. 'date' parameter described only as 'optional', should specify format enforcement (YYYY-MM-DD) and valid date range.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No output schema documentation for any tool. LLMs cannot infer what fields to expect from responses. Code shows BatchReportResponse, TechnicalReport models defined but tool registrations do not reference them.
Ambiguous parameter naming: 'who' in load_data_msd* tools lacks description and type clarity. Is this a user ID, agent name, or logging label? Should suffix with type (who_id, who_name) or describe in detail.
Inconsistent async/sync tool naming: load_data_msd_batch and load_data_msd_batch_async differ only in '_async' suffix. No description explains when to use which. LLM will not automatically infer concurrency semantics. Should document latency/throughput tradeoff explicitly.
Chinese descriptions with no English fallback: All tool descriptions are in Chinese (e.g., '批量获取并生成报告的核心驱动程序'). While valid, LLMs trained predominantly on English may misinterpret nuances. Consider providing English translations for clarity and broader LLM compatibility.
No error handling documentation: No tool description explains what errors are possible, whether they are retryable, or how to recover. Per pattern:recovery-guide, errors must tell the LLM what to do next. E.g., 'If date range is invalid, returns 400 with suggestion to check date format.'
Numeric parameter ranges not documented: fund_flow_limit in fetch_batch_reports defaults to 15 but no min/max specified. n in load_data_msd* defaults to 0 and is 'unused' per description, why expose it?