MCP server (stdio) exposing the AlphaForge `forge` CLI to Claude Code / Cursor / Codex for backtesting, trading, and quantitative strategy optimization
This MCP server demonstrates strong naming conventions, excellent parameter documentation via Pydantic Field annotations, and comprehensive schema information visible in the source. All 17 tools follow verb_noun naming (list_*, get_*, run_*, generate_*, fetch_*, save_*, apply_*). Each tool has a clear, substantive description (50-150 chars). Parameters are richly annotated with descriptions, examples, regex patterns, and type constraints (FastMCP generates inputSchema from Pydantic Field metadata). Output schemas are inferred from return type hints (Envelope[dict] pattern). However, three issues prevent a higher score: (1) Output schemas are not explicitly documented in tool definitions, they are inferred from return annotations, making them less visible to clients; (2) Error handling guidance is minimal, tools return errors via the Envelope wrapper but lack actionable recovery hints; (3) The 'save_strategy' tool accepts a JSON body as a string parameter, which is non-standard for agent composition (most tools should accept structured parameters, not opaque JSON strings). Tool definitions are directly visible in src/alpha_forge_mcp/server.py with explicit @mcp.tool() decorators, so all tools are scored based on actual code, not inference.
Apply saved optimization results to a strategy (with progress notification)
Get exploration status for a strategy (read-only, idempotent)
Fetch and cache historical OHLCV data for a symbol (with progress notification)
Check AlphaForge binary presence, authentication status, and plan tier (read-only, idempotent)
Generate TradingView Pine Script v6 code from a strategy (read-only, idempotent)
Get metadata for a technical indicator (read-only, idempotent)
Get full exploration journal by id (read-only, idempotent)
Output schemas are inferred from return type hints rather than explicitly declared in tool definitions. Clients cannot introspect what fields a tool returns without analyzing the Envelope[dict] wrapper. Type hints like 'dict' are too generic.
'save_strategy' accepts a JSON string body parameter (json_body: string) rather than structured fields. This violates the composition pattern, agents cannot build the JSON programmatically without string manipulation, and parsing errors are silent.
Error handling in tool responses uses the Envelope wrapper (ok/data/error fields) but does not provide actionable recovery guidance. An agent receiving {ok: false, error: 'forge binary not found'} does not know whether to retry, ask the user, or call a different tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2025-06-18+ | v2 |
Get full backtest or optimization result by id (read-only, idempotent)
Get full details of a registered strategy by id (read-only, idempotent)
List saved exploration journals (read-only, idempotent)
List saved backtest / optimize results (read-only, idempotent)
List all registered strategies (read-only, idempotent)
Run backtest on a strategy with given symbol and date range (with progress notification)
Run Monte Carlo simulation to evaluate risk metrics and drawdown distributions (with progress notification)
Run parameter optimization on a strategy (with progress notification)
Run walk-forward test to assess out-of-sample robustness (with progress notification)
Register or update a strategy from JSON body (with progress notification)
No explicit documentation of which tools are idempotent (safe to retry) vs stateful (side effects). The rubric indicates all 17 tools carry a Risk annotation (READ_ONLY or WRITE) but tool descriptions do not emphasize idempotency for safe read operations.
run_backtest, run_optimize, run_walk_forward, run_monte_carlo, and fetch_data execute long-running operations (potentially hundreds of seconds) but tool descriptions do not document expected duration, timeout behavior, or how to interpret progress notifications.