FastAPI-based MCP server for fetching historical stock prices and analyzing portfolio values using yfinance
The Stock Tracker MCP has 2 tools with visible schema definitions and descriptions. Both tools follow a verb_noun naming pattern (get_*, portfolio_*) and include parameter schemas with types. However, definitions lack depth: descriptions are minimal (10-15 chars each), parameter descriptions are generic, output schemas are undocumented, and error handling provides no recovery guidance. The portfolio_analysis tool has a critical validation issue (length mismatch check) but no actionable error message. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite READ_ONLY risk classification. Overall, the tools are functional but fall short of production quality, descriptions do not explain WHEN to use each tool, WHAT they return, or HOW to recover from errors.
Fetch historical stock prices
Analyze portfolio value over time
Tool descriptions are too short (10-15 chars) and lack WHEN/WHY guidance. 'Fetch historical stock prices' does not explain when to use get_stock_price vs portfolio_analysis, what format the output is, or what ticker symbols are valid.
Output schemas are completely undocumented. LLMs cannot predict that get_stock_price returns a list of dicts with keys like 'Date', 'Open', 'High', 'Low', 'Close', 'Volume', or that portfolio_analysis returns records with ticker columns plus 'Total'. Without documented output structure, agents cannot plan downstream operations.
Parameter descriptions lack format constraints and guidance. 'period' parameter description says 'Time period (e.g., '1mo', '6mo', '1y')', examples should be replaced with an enum or pattern constraint. 'interval' has the same issue. LLMs will reuse example values literally rather than adapting to context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Error handling provides no recovery guidance. When portfolio_analysis returns {'error': 'Tickers and quantities length mismatch'}, the LLM has no hint what to do next. Should it retry? Call a different tool? Ask the user? Errors must categorize as retryable/user-fixable/fatal and suggest next steps.
No tool annotations despite READ_ONLY risk classification. Tools are marked READ_ONLY in the metadata but do not include readOnlyHint in their schema definitions. This prevents MCP clients from optimizing caching or enforcing execution restrictions.
No pagination or result limits. If a user requests 6 months of daily stock data for multiple tickers, the response could contain thousands of data points, exhausting the LLM context window. Tools should accept limit/offset parameters and document max result size.
Parameter naming inconsistency: portfolio_analysis uses 'tickers' (plural) and 'quantities' (plural), suggesting arrays, but descriptions do not explicitly state they must be parallel arrays of the same length. The length check happens at runtime and returns a vague error rather than being prevented by schema constraints.
No idempotency guarantees documented. If an LLM retries get_stock_price with the same ticker and period due to a transient error, will it return the same results or stale/different data? This is critical for agent reliability.