Problem

mcp/ currently exposes exactly one tool, backtest, which takes a strategy name plus raw OHLCV arrays inlined in the call. There's no way to compute a single named indicator (SMA, MACD, RSI, ...) outside of writing Go code against the library directly, and no CLI comparable to cmd/indicator-backtest or cmd/indicator-sync for indicators.

This makes the library harder to use both for humans scripting against it and for AI agents driving it through MCP: an agent has to already know which Go type implements an indicator and how to wire it to OHLCV data, instead of just naming it.

Proposal

• A new registry package (root module) providing a name -> indicator lookup: given an indicator name, a set of string parameters (e.g. Period=14), and a channel of asset.Snapshot, compute the indicator and return its named output series (e.g. macd/signal, or upper/middle/lower for Bollinger Bands), aligned with dates.
• A new cmd/indicator-cli command, matching the shape of indicator-backtest/indicator-sync (-source-name/-source-config for the asset repository), that looks up an indicator by name via the registry and writes the result as CSV to stdout.
• A new indicator tool on the MCP server, built on the same registry, so the CLI and MCP stay in sync as indicators are added instead of duplicating lookup/parameter-binding logic in each front end.

Why this shape

• Reuses existing patterns already in the codebase: asset.NewRepository(name, config)'s name->builder factory, and mcp/strategy_factory.go's CreateStrategy name->constructor switch.
• Keeps mcp/ a thin adapter — it imports the registry the same way it already imports strategy/trend/etc., no new module boundaries.
• Indicator parameters are passed as repeated Name=Value pairs (CLI flags, or an array of strings over MCP), which maps directly onto reflection-based field assignment (including nested indicators, e.g. Ema1.Period on MACD) without needing a bespoke schema per indicator.

Scope

Initial registration covers a representative slice across categories and input/output shapes (sma, ema, macd, cci, rsi, bollinger_bands, obv, vwap) to prove the pattern. Extending coverage to the rest of the indicator catalog is mechanical follow-up work, one registry.Register(...) call per indicator.