Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has significant definition quality issues across the board. While 19 tools are registered, only 2 have verifiable input schemas in the source code (current_timestamp and stock_data). The remaining 17 tools are defined ONLY in .roo/mcp.json without visible implementations or schemas in the provided src files. Descriptions exist for all tools but are extremely terse (10-20 chars on average), providing almost no actionable guidance for LLM tool selection. No parameter descriptions are visible for most tools. The server lacks structured output documentation, error recovery guidance, and proper naming conventions. Tool names like 'stock_data', 'fund_data', 'macro_econ' are generic nouns rather than action-verb patterns (get_stock_data, list_funds, fetch_macro_econ). Most critically, 17 of 19 tools have inferred definitions only, not explicit registration visible in the source, triggering the hard cap at 50 for those tools. Even the two visible tools (current_timestamp, stock_data) have minimal schema completeness.
Expand all descriptions to 50-200 characters with explicit selectivity guidance. Example: 'finance_news' → 'Retrieve financial news articles by keyword. Use when agent needs recent market news, earnings alerts, or industry updates. Returns sorted by recency with source attribution.'
Convert all 17 tools in .roo/mcp.json to explicit TypeScript implementations in src/tools/ with formal Zod schemas visible in httpServer.ts. Current setup hides tool definitions from static analysis and makes schemas invisible to LLMs.
Rename tools to action_noun patterns: 'stock_data' → 'get_stock_data', 'fund_data' → 'list_funds', 'macro_econ' → 'fetch_macro_indicators', 'basic_info' → 'get_stock_basic_info'. This lets LLMs infer intent from the name.
Add input parameter descriptions to every parameter in every tool. Example for stock_data 'indicators' param: 'Space-separated list of technical indicators to calculate. Valid: macd(12,26,9), rsi(14), kdj(9,3,3), boll(20,2), ma(10). Omit for raw price data only.'
Simplify the 'indicators' parameter in stock_data. Instead of free-form syntax 'macd(12,26,9) rsi(14)', expose separate boolean parameters: 'include_macd' (bool), 'include_rsi' (bool), 'include_kdj' (bool), with defaults for common windows. This is more discoverable and LLM-friendly.
Document output schemas for all tools. Example for stock_data: 'Returns array of daily OHLCV records: [{date: YYYYMMDD, open: number, high: number, low: number, close: number, volume: number, ...indicators}]. Capped at 1000 records; use pagination for larger ranges.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Naming conventions are weak. 15 tools use generic nouns (fund_data, macro_econ, money_flow, stock_data) rather than action verbs (get_, list_, fetch_). This violates pattern:tool which requires action verbs to convey intent to LLMs.
stock_data tool has overly complex indicators parameter description (mentioning MACD, RSI, KDJ, Bollinger Bands with nested syntax). LLMs struggle with complex nested schemas. This should be an enum or separate tools.
No documented output schemas for any tool. Pattern:tool requires documenting what fields will be returned so LLMs can plan downstream calls. Absence forces LLMs to guess.
No error recovery guidance visible in tool descriptions. Pattern:recovery-guide requires error responses to tell LLMs what to do next. No tool description explains what errors are possible or how to recover.
Tool names like 'basic_info', 'dragon_tiger_inst' are vague or abbreviated. Baseline rubric expects clear action_noun patterns. 'basic_info' does not clarify info about stocks, companies, or indices. 'dragon_tiger_inst' is domain jargon without context.
basic_infodragon_tiger_inst
Add error recovery guidance to descriptions. Example: 'If code is invalid (404), call list_stock_codes(market_type) to discover valid codes. If date range exceeds 10 years, try narrower date ranges.'
Define pagination for tools returning lists (stock_data, finance_news, fund_data, index_data). Add 'limit' (default 20, max 100) and 'offset' parameters, and return 'total_count' in response so agents know how many results exist.
Add 'market_type' enum constraints to stock_data tool definition to prevent invalid market types. Current implementation in httpServer.ts uses enum, but .roo/mcp.json definition is incomplete.
For each stock/market tool, clarify required code format in description with specific examples. Example: 'code parameter format varies by market_type: cn→000001.SZ, us→AAPL, hk→00700.HK, crypto→BTCUSDT. Call get_stock_codes(market_type) for valid values.'
Add parameter type definitions to .roo/mcp.json tools. Currently many tools lack explicit type declarations (type: string, type: number, etc.) in their input schemas.
Document which tools are read-only and which make changes. All 19 tools are marked READ_ONLY, which is correct, but descriptions should state 'This tool does not modify data' so agents know they can safely call it for fact-checking.
For tools that export CSV/JSON (stock_data, index_data), clarify whether the export happens in the response or as a side effect (file written to disk). Add explicit 'export_path' constraints and return the file URI in the response.
Consolidate overlapping tools. 'company_performance', 'company_performance_hk', 'company_performance_us' are three tools with identical signatures but different geographic scope. Consider a single 'get_company_performance(code, market_type)' tool instead.