MCP投资助手服务器 - Investment assistant server for stock market analysis, providing index temperature calculation, company candlestick data, fundamental analysis, financial statements, and fund flow information
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server provides 5 investment research tools with Chinese descriptions targeting the Lixinger API. However, the implementation has critical gaps in definition quality. Tool descriptions are present but lack LLM-optimized structure and critical metadata. Parameter schemas are visible in the provided code but lack comprehensive type definitions and constraints. No output schemas are documented. Error handling is minimal. The server accepts domain-specific parameters but does not guide the LLM through failure modes or recovery paths. All tools are read-only operations, which is positive for safety, but the definitions themselves do not communicate this clearly through annotations.
No output schemas documented for any tool. LLMs cannot infer the structure of candlestick data, fundamental metrics, financial statements, or fund flow responses. Agents cannot plan downstream transformations or extract required fields for chaining.
Enum constraints exist in configuration files (MARKET, FUND_FLOW_TYPE, FS_TABLE_TYPE, etc.) but are NOT declared in tool input schemas. LLMs see free-form string parameters and may hallucinate invalid values like 'US股' or '基金流向'. Enums must be in the schema, not just in code comments or config.
Add explicit enum declarations to tool input schemas for all constrained-choice parameters: marketCn (A股, 港股, 美股), fsTableType (non_financial, bank, security, insurance, reit, other_financial), fundFlowType (互联互通, 融资融券), samplingPeriod (daily, weekly, monthly). Do not rely on config files, enums must be in the JSON Schema 'enum' field.
Document output schemas for all 5 tools. For mcp_get_index_temperature, define: { temperature: number, interpretation: string, ...}. For candlestick, define: { open, high, low, close, volume, date, ... }. For fundamental/financial_statement, define: { metricName: string, value: number|null, date: string, ... } and clarify pagination (returns full array or paginated results?). For fund_flow, define: { flowType: string, amount: number, date: string, ... }.
Rewrite tool descriptions to be LLM-optimized (50-200 chars). E.g., mcp_get_company_candlestick: 'Get historical candlestick (OHLCV) data for a single stock to analyze price trends. Required: stockCode (e.g. "000001" for A-stock, "0001" for HK stock), marketCn, startDate (YYYY-MM-DD), endDate. Returns daily/weekly/monthly candles in OHLCV format.' This tells the LLM what the tool does, when to use it, what format inputs take, and what to expect back.
Add format specifications to all date parameters. E.g., startDate: 'Start date in YYYY-MM-DD format (e.g., 2024-01-15). Data available from 1990-01-01 to today.' This prevents LLM hallucination of invalid date formats.
Add bounds and constraints to numeric and array parameters. E.g., stockCodes: 'Array of stock codes (1-50 codes per call). A-stocks: 6-digit code (e.g., "000001"), HK stocks: 5-digit code with optional .HK suffix (e.g., "0001" or "0001.HK").' Limit parameter: 'Integer 1-1000 (default 20). Cap returned rows to avoid timeout.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Tool descriptions are either too short (under 20 chars: mcp_get_company_candlestick, mcp_get_company_financial_statement) or too long/unfocused (mcp_get_index_temperature at 200+ chars with financial education content). None clearly communicate WHEN to use this tool, how it differs from related tools, or what the LLM should expect.
Date parameters (startDate, endDate) lack format specifications. Are they YYYY-MM-DD, ISO 8601, Unix timestamps, or something else? LLMs will guess and frequently produce invalid formats, causing API failures. Every date parameter needs a format constraint in its description.
No error handling documentation. What happens if an API call fails? What does a -100 return mean in mcp_get_index_temperature? What HTTP status codes indicate retryable vs. fatal errors? LLMs have no guidance on recovery paths.
No discovery mechanism for complex parameters. mcp_get_company_fundamental and mcp_get_company_financial_statement accept a metricsList array, but the tool definitions do not enumerate the 20+ valid metrics (pe_ttm, pb, ps_ttm, etc.). LLMs will hallucinate metric names. Consider adding a separate discovery tool (list_fundamental_metrics, list_financial_metrics) or documenting the full enum in the schema.
No pagination or result limits declared. Arrays (stockCodes in mcp_get_index_temperature, metricsList in mcp_get_company_fundamental) lack size constraints. Unbounded arrays can blow context windows or cause API timeouts. Declare minimum and maximum array sizes in parameter descriptions.
API market availability is undocumented in tool definitions. COMPANY_MARGIN_TRADING_API only supports A股, but mcp_get_company_fund_flow accepts both A股 and 港股. The tool will fail silently for 港股 + 融资融券. Document market + fundFlowType compatibility constraints in the parameter descriptions.
All tools are read-only (Risk: READ_ONLY flagged), but this is not communicated via toolAnnotations. Modern MCP clients support readOnlyHint to guide safe tool selection in agent loops. Annotate tools to enable better agent reasoning.
Implement toolAnnotations to declare read-only status. In the tool registration, add: { name: 'mcp_get_index_temperature', description: '...', inputSchema: {...}, meta: { readOnlyHint: true } }. This enables MCP clients to prioritize safe tools in agent loops.
Add dependency hints to parameter descriptions. E.g., metricsList in mcp_get_company_fundamental: 'Array of metric keys (e.g., ["pe_ttm", "pb"]). To discover available metrics, see the resource://fundamental-metrics documentation or call list_fundamental_metrics (if available). Common metrics: pe_ttm (PE-TTM), pb (Price-to-Book), ps_ttm (PS-TTM).' This guides LLMs to discovery before guessing metric names.
Document API market compatibility constraints. E.g., mcp_get_company_fund_flow fundFlowType parameter: 'Type of fund flow data. Options: "互联互通" (Shanghai-Hong Kong Connect, A股 + 港股), "融资融券" (Margin trading, A股 only). Verify market compatibility before calling.'
Add error recovery guidance. E.g., mcp_get_index_temperature description: 'If the call returns temperature: -100, the API failed (likely invalid stockCode or network issue). Verify the code format matches the market (A股: 6 digits, 港股: 4-5 digits, 美股: 1-5 letters). Retry with a known code like "000016" (A股) or "0001" (HK) to confirm connectivity.'
Implement result limiting and pagination. For tools returning multiple metrics or candlesticks, declare a 'limit' parameter (1-1000, default 50) and return { data: [...], total: number, nextCursor?: string }. This prevents context window exhaustion and enables agents to fetch large datasets incrementally.
Add a discovery resource or tool to help agents discover valid metric names. E.g., a resource://fundamental-metrics URI listing all 20+ available metrics with descriptions, or a list_fundamental_metrics() tool. This eliminates LLM hallucination of invalid metric names.