trading-swarm-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ALPACA_SECRET | No | Alpaca API secret. Required only if SWARM_MCP_BYOK=1 on swarm-data-mcp. | |
| ALPACA_API_KEY | No | Alpaca API key. Required only if SWARM_MCP_BYOK=1 on swarm-data-mcp. | |
| SWARM_MCP_BYOK | No | Set to '1' to fetch directly from Alpaca/Finnhub instead of the hosted relay (swarm-data-mcp only). Public users should leave unset. | 0 |
| FINNHUB_API_KEY | No | Finnhub API key. Required only if SWARM_MCP_BYOK=1 on swarm-data-mcp. | |
| SWARM_MCP_LOCAL_TOKEN | No | Local development bootstrap token. For operators of this repo, set to the same value as SWARM_MCP_ACCESS_TOKEN to skip token verification against the site. | |
| SWARM_MCP_ACCESS_TOKEN | Yes | Access token issued by https://1.21initiative.com/. Required for all three servers. Every tool call is gated on this token; clients can list tools without it, but calls return ACCESS_REQUIRED. | |
| SWARM_MCP_TELEMETRY_OPT_IN | No | Set to 'opt-in' to enable telemetry. Counters only; no symbols, genomes, prices, or credentials. | 0 |
| SWARM_MCP_TOKEN_VERIFY_URL | No | URL used for access-token verification. Only the token is sent. | https://1.21initiative.com/api/mcp/verify |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| warden.validate_orderA | Validate a proposed order against the house floors (max position 25%, gross cap 60%). order: {symbol, notional, side: buy|sell}; current_positions: {symbol: notional}. Per-fund overrides are allowed but the response always reports the deviation from the house floors. Rejections quote the exact floor — the same function gating live capital. |
| warden.audit_featuresA | Audit a feature manifest for lookahead leakage and provenance violations. manifest: [{name, source, value_ts, as_of}]. Flags banned actuals sources (open-meteo.archive etc.), features predating tape start, and unknown features fail closed to tier C. Optional coverage check vs MIN_COVERAGE=0.90 for challenger-selected symbols against the archived snapshot universe. |
| warden.cost_checkA | Convert a claimed gross edge into net-of-cost reality under the pessimistic fill model. Spread + slippage + adverse selection are charged at both entry and exit, always against the position — the same model the gym scores every episode with. |
| warden.validate_genomeA | Validate a genome against the bounded schema and return its canonical genome_hash. The hash is the reproducible strategy identity used as challenger_id in the hosted tournament and in audit_request blocks. |
| warden.explain_sizingA | Step-by-step mirror of the live C# risk engine sizing: ATR sizing, position-notional cap, overnight-gap halving, weekend gross headroom. Reports the house floors and any deviation when per-fund overrides are supplied. |
| warden.promotion_verdictA | Request a promotion verdict. Always INDETERMINATE_LOCAL: the selection machinery is server-side. Names the exact missing statistical inputs and emits an audit_request plus a cloud_job spec for the hosted tournament. |
| warden.optimize_portfolioA | Computes volatility-targeted dual-momentum, hierarchical risk parity, or shrinkage mean-variance portfolio weights under the house concentration and turnover caps. Residual capital is swept to the defensive cash proxy; never places or routes trades. Pro tool. |
| warden.plan_rebalanceA | Checks the portfolio drawdown circuit breaker, feature drift guard, 3% turnover drift buffer, and bid-ask spread gate. Sequences sell reductions before buy additions with marketable limit collars; never routes trades. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| pre_trade_check | The full pre-trade gate sequence (validate_order, cost_check, explain_sizing) with every verdict quoted verbatim; refusals are never softened. |
| audit_my_strategy | Genome audit: validate_genome plus audit_features findings quoted exactly, then the tournament path a promotion claim actually requires. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Methodology | How the PIT significance verdicts are computed (neutralization, Newey-West inference, scale-free variants, staleness, placebo). |
| Verdict semantics | SIGNIFICANT / NOT_SIGNIFICANT / NOT_JUDGED / UNVERIFIED - exactly what each verdict means and never means. |
| Plans | Free/Pro plan limits and the credit rate card. |
TDQS
Scored across 8 tools
Each tool targets a distinct artifact or check: order validation, feature audit, rebalance planning, cost conversion, genome validation, sizing explanation, promotion verdict, and portfolio optimization. There is mild thematic overlap in the risk/sizing family (validate_order, explain_sizing, plan_rebalance all touch risk gates), but descriptions make the boundaries clear enough that misselection is unlikely.
Every tool follows a uniform dot-prefixed snake_case convention (warden.<name>). Most are verb_noun (validate_order, audit_features, plan_rebalance, validate_genome, explain_sizing, optimize_portfolio), with a couple noun-first variants (cost_check, promotion_verdict) that remain clearly readable and consistent in style.
Eight tools is well-scoped for a risk/validation gatekeeper domain. Each tool covers a distinct responsibility (order gating, feature audit, rebalance, cost model, genome identity, sizing, promotion, optimization) with no obvious redundancy.
The surface covers the core risk-gating lifecycle from order validation through rebalance planning, cost modeling, sizing, and promotion verdicts, and explicitly documents that it never routes trades (a deliberate boundary, not a gap). Minor gaps exist around state/query operations (e.g., fetching current floors or drift history), but agents can work around them.