Loading ToolBench
An MCP server that provides direct access to Wind API for financial data queries, supporting wsd (time series), wss (cross-sectional), wsq (real-time quotes), and date functions
Wind MCP server exposes 8 tools for financial data access via Wind API. Naming is action-verb-based (get_*, search_*, wind_*) which is good. However, critical gaps exist: descriptions are present but often generic and in Chinese, parameters lack comprehensive type definitions in the schema specifications shown, and output schemas are not explicitly documented. The code shows partial implementation, tool registration via @mcp.tool() decorator is visible for 3 tools (get_today_date, search_windpy_doc, get_today_date visible in source), but the remaining 5 wind_* tools (wind_wsd, wind_wss, wind_wsq, wind_tdays, wind_tdaysoffset, wind_tdayscount) are inferred from the TOOLS list provided but NOT explicitly defined in the visible source code excerpt. Per the HARD SCORING RULES, tools that cannot be seen as explicit registrations must be capped at 50. This severely limits the overall score. Additionally, parameter descriptions mention format examples (e.g. '2016-01-01', '-5D') but do not validate or constrain these as enums or patterns, LLMs will hallucinate invalid date formats. Error handling is minimal, no recovery guidance provided. Composition is reasonable (each tool does one thing), but missing field chaining IDs in output definitions.
获取服务器当前日期
检索WindPy官方API文档（仅限本服务支持的六个函数），返回相关内容片段。
获取区间内日期序列（TDAYS）
计算指定区间内的日期数量（TDAYSCOUNT）
根据基准日期计算偏移后的日期（TDAYSOFFSET）
获取日时间序列数据（WSD）
获取实时行情数据（WSQ）
获取日截面数据（WSS）
5 of 8 tools (wind_wsd, wind_wss, wind_wsq, wind_tdays, wind_tdaysoffset, wind_tdayscount) are inferred from the TOOLS list but NOT explicitly defined in visible source code. Per HARD SCORING RULES, inferred tools are capped at 50 overall.
Output schemas are not formally documented for ANY tool. Descriptions mention return structure (e.g. 'dict with match field') but no structured schema definition is provided. LLMs cannot parse downstream requirements without explicit return schemas.
The 'options' parameter appears in 5 tools (wind_wsd, wind_wss, wind_wsq, wind_tdays, wind_tdaysoffset, wind_tdayscount) as an unconstrained string. Description is vague ('semicolon-separated optional params'). No enum of valid options, no validation pattern, no format guidance. LLMs will hallucinate invalid options.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
Date parameters (beginTime, endTime) in multiple tools lack format validation. Examples are given ('2016-01-01', '20160101', '-5D') but no regex pattern or enum enforces these formats. LLMs will pass invalid dates.
Descriptions are present but inconsistent in language (mix of Chinese and English) and lack LLM-optimized context. Many are under 100 characters and do not explain WHEN to use each tool or dependencies. Example: 'wind_wsd' description is ~60 chars in Chinese; no guidance on whether to use wind_wsd vs wind_wss.
No error handling or recovery guidance. If a Wind API call fails (e.g. invalid code, connection down, date out of range), tools do not provide actionable errors. LLMs will not know whether to retry, ask the user, or try an alternative tool.
Tool naming uses domain-specific abbreviations (wsd, wss, wsq) instead of action verbs first. 'get_timeseries_data', 'get_snapshot_data', 'get_realtime_quote' would be more discoverable for LLMs.
Parameters 'codes' and 'fields' accept 'string|list' types. No guidance on when to use string vs list, or how the tool disambiguates them. LLMs will default to one or the other inconsistently.
No pagination, result limits, or result counts documented. If wind_wsd returns thousands of data points, the response will blow the context window. No limit guidance in descriptions.