Loading ToolBench
A MCP service provide CN market data and research tools
CnStock has 3 tools with definitions visible in mcp_app.py. All tools start with action verbs (brief, medium, full) but lack critical schema documentation and parameter clarity. Tool descriptions are present but generic (10-50 chars on core details). Input parameters have type declarations (string) but lack enums, ranges, validation rules, and format constraints. No output schemas are documented. Error handling is minimal ('No data found' is the only visible error message). The tools appear to be simple data retrieval endpoints with minimal composition. This server reads as a proof-of-concept rather than production-ready tooling.
Get brief information for a given stock symbol, including - basic data - trading data
Get full information for a given stock symbol, including - basic data - trading data - financial data - technical analysis data
Get medium information for a given stock symbol, including - basic data - trading data - financial data
No documented output schemas. Tools return unstructured strings (StringIO buffers built by research.build_*() functions). LLMs cannot parse expected fields, extract IDs for chaining, or plan downstream calls. This forces agents to regex-parse free-form text responses.
Symbol parameter lacks validation constraints. Description says 'must be in the format of SH000001 or SZ000001' but provides no enum or regex pattern. LLMs will hallucinate invalid formats like 'SZ1335', '1335', or 'AAPL'. No format constraint in schema prevents this.
Tool descriptions are bare-bones. 'Get brief information for a given stock symbol...' (49 chars) does not explain WHEN to use brief vs medium vs full, what data differences to expect, or why the distinctions matter. LLMs will struggle to select the right tool given a user intent like 'Show me everything about this stock'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 13 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Parameter descriptions repeat the type constraint ('Stock symbol, must be in the format of...') but omit actionable guidance. No mention of case sensitivity, whether the tool accepts aliases/names (description claims it 'infer convert user inputs like stock name to stock symbol' but provides no lookup mechanism), or what happens if the symbol is invalid.
Error handling is minimal. Only visible error path is 'No data found for symbol: ' + symbol. No guidance for LLM recovery (e.g., 'Try search_symbols() to find the correct symbol'), no categorization of errors (retryable vs user-fixable), and no invalid symbol format detection before calling external data service.
No pagination or result limits documented. If research.load_raw_data() or build_*() functions return large datasets, the response could balloon context. No limit parameter, no statement in description of expected response size, no cap enforcement visible.
Tools appear to operate on a single resource (one stock symbol at a time). No batch variants (e.g., brief_batch accepting multiple symbols) for agents that might want to compare stocks or fetch multiple portfolios. This forces N sequential calls instead of one batch operation.