Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Technical Analysis MCP exhibits critical definition gaps across most tools. While tool names are generally action-oriented (analyze_*, compare_*, screen_*, get_*), the implementation lacks consistent schema completeness and parameter descriptions. Of 9 tools examined, 7 have visible schemas in the server code, but parameter descriptions are inconsistent. Critically, tools like get_trade_plan, scan_trades, portfolio_risk, morning_brief, analyze_fibonacci, and options_risk_analysis are defined in deprecated/archived code paths (old_code/ and src/), raising questions about which is canonical. The main codebase (mcp1/server.py) shows only 3 tools clearly implemented. Tool descriptions exist but many are vague or domain-specific without clear guidance on LLM selection criteria. No error recovery patterns visible. Security risk: API keys and credentials are likely managed via environment variables (USE_GCP, CLOUD_RUN_URL, PROJECT_ID, GCP_PROJECT_ID) but tool parameters are not validated against injection attacks. Output schema documentation is minimal, tools return raw API responses without shaping for agent consumption.
Tools (9)
analyze_fibonacciread onlysource verified62/100
Analyze Fibonacci retracement levels and support/resistance for swing trading
analyze_securityread onlysource verified68/100
Analyze any stock/ETF with 150+ technical signals
compare_securitiesread onlysource verified67/100
Compare multiple stocks/ETFs and find the best pick
get_trade_planread onlyauthsource verified38/100
Get risk-qualified trade plan (1-3 max) with suppression reasons if not tradeable
morning_briefread onlysource verified37/100
Generate daily market briefing with signals and market conditions
Parameter descriptions inconsistent and sparse. 'period' param repeats 'Time period (15m, 1h, ...)' across all tools; parameter constraints not machine-parseable (no enums). 'criteria' in screen_securities is vague ('Screening criteria (rsi, min_score, etc.)'), LLM cannot determine valid keys.
Consolidate all tool definitions into a single canonical source (mcp1/server.py or src/technical_analysis_mcp/server.py). Remove or archive old_code/. Verify all 9 tools are registered and visible in the primary server entry point.
Document complete input and output schemas for all 9 tools. For each tool, provide: (1) input JSON Schema with required fields, types, enums, min/max for numerics; (2) output schema (e.g., 'returns {symbol: string, signals: [{name: string, value: number, category: string}], total_signals: int, next_cursor?: string}').
Expand tool descriptions to include selection guidance. Add a sentence explaining WHEN to use this tool vs related ones. Example for analyze_security: 'Use this for detailed signal analysis of a single security. For quick multi-security comparison, use compare_securities instead. For screening a universe, use screen_securities.'
Implement structured error handling. Wrap GCPClient async calls in try-except. Return error responses in format: {error: string, code: 'not_found'|'invalid_input'|'timeout'|'permission_denied', recovery: string}. Example recovery: 'Symbol "XYZ" not found. Try search_securities() with a partial match.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 7 points across a rubric change (v1 → v2)
39/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
39
<=2025-11-25
v2
2026-03-09
F
46
-
v1
scan_tradesread onlysource verified40/100
Scan universe for qualified trade setups (1-10 per universe)
Tool descriptions lack selection guidance for LLMs. Example: 'Analyze any stock/ETF with 150+ technical signals', does not explain WHEN to call analyze_security vs analyze_fibonacci vs options_risk_analysis. No dependency hints (e.g., 'Call this after screen_securities to deep-dive a picked symbol').
No output schema documentation visible. Tools return data from GCP Cloud Run backend (asyncio HTTP calls to CLOUD_RUN_URL), response structure unknown to LLM. No pagination guidance (limit defaults to 20, 10, 50 across tools), tools may return unbounded lists causing context explosion.
Error handling absent. GCPClient methods call response.raise_for_status() without catching exceptions or providing recovery guidance. Example: analyze() may fail with Firestore unavailable, network timeout, or invalid symbol, LLM receives raw httpx error, no actionable next step.
GCP credentials hardcoded into environment (GCP_PROJECT_ID, PROJECT_ID, CLOUD_RUN_URL, USE_GCP). No per-tool permission gates visible. Agents using these tools have full read access to all symbols, portfolios, and trade plans, no scope declaration or audit trail implementation.
Numeric parameters lack bounds. 'limit' in screen_securities defaults to 20, scan_trades to 10, but no min/max constraints visible. 'window' in analyze_fibonacci defaults to 50 (lookback window), unconstrained parameter could cause performance issues.
Add audit logging. Log each tool invocation with timestamp, tool name, caller ID (agent ID if available), input (sanitized), output summary, and execution time. Example: 'analyze_security(symbol=AAPL, period=3mo) called by agent-123, returned 150 signals in 2.3s'.
Validate all LLM-provided inputs before passing to GCP backend. Validate symbol format (alphanumeric, 1-5 chars), period against enum, numeric parameters against min/max bounds. Return 'Invalid symbol: must be 1-5 alphanumeric chars. Got: "XYZ123".'
Document which tools are idempotent and which are not. E.g., analyze_security is idempotent (read-only); get_trade_plan may have cached/time-dependent results. Agents need to know which calls are safe to retry.
Add dependency hints in descriptions. Example for portfolio_risk: 'Input can reference results from get_trade_plan() or manually specify symbol/shares/entry_price. If you don't have entry prices, call get_price_history() first.'
Split compound tools if discovered. Ensure each tool does exactly one thing. If a tool both ranks signals AND generates a plan, split into rank_signals + generate_plan.
Implement a dry-run or confirmation pattern for sensitive operations if any. If get_trade_plan returns executable trade instructions, add a confirm_trade or simulate_trade option before execution.