Smart Financial MCP is a STDIO-only server with 4 tools for stock market data queries via Tushare API. Core issues: (1) Tool names lack clarity, 'check_token_status' is reasonable but 'get_stock_basic_info', 'search_stocks', 'get_index_daily_price' are generic and do not indicate what data structure is returned or which Tushare API endpoint they wrap. (2) Descriptions are present but inconsistent in quality. 'check_token_status' has a 37-character description (below the 50-char minimum for clarity). 'get_index_daily_price' has a verbose 800+ character description with example index codes and return fields, which wastes tokens and includes example values (a documented anti-pattern). (3) Input schemas are defined but lack rigor: parameters have type and description, but several are optional without defaults or explanation of what happens when omitted. 'ts_code' is required for most tools but marked as optional string in schema. (4) Output schema is completely undocumented, tools return formatted strings with no machine-parseable structure, forcing LLMs to parse unstructured text. (5) No error recovery guidance, errors like 'Token无效或已过期' and 'Query failed' give no next steps. (6) No pagination support despite returning potentially large result sets. (7) All responses are plain text, not structured objects, this violates the pattern:response-shaper pattern.

• Restructure all tool responses as JSON objects with typed fields. Instead of 'token配置正常，可以使用Tushare API。', return {"status": "valid", "message": "Token is valid and accessible."}. This enables LLMs to extract and reason about specific fields.
• Reduce description length for 'get_index_daily_price' from 800+ chars to 100-150 chars. Replace literal example codes with a formal enum or pattern constraint in the schema. Move detailed index mappings to a separate discovery tool (list_index_codes) that agents call once.
• Add explicit defaults and validation for optional parameters. For 'get_stock_basic_info', require at least one of ts_code or name. If both are omitted, return error: 'Must provide either ts_code or name. Call search_stocks(keyword) first to discover codes.'
• Implement pagination for list/search tools. Add limit (default 20, max 100) and offset parameters. Return {"results": [...], "total_count": 5000, "has_more": true} so agents know whether to fetch more.
• Add error classification and recovery hints. Map Tushare API errors to agent-actionable steps. E.g., 'Token expired. Action: Call configure_token or set TUSHARE_TOKEN env var' or 'Network timeout. Action: Retry in 5 seconds or check Tushare service status.'
• Expand 'check_token_status' description to 60-80 chars explaining: 'Validates that the Tushare API token is configured and valid. Call this before other tools if token was recently updated.' Consider renaming to 'validate_tushare_token' (verb_noun pattern).
• Make search_stocks return structured results: {"matches": [{"ts_code": "000001.SZ", "name": "平安银行", "industry": "银行"}], "count": 3} instead of plain-text list. This allows downstream tools to consume results directly without re-parsing.