trading-swarm-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@trading-swarm-mcpAudit this AAPL order: 200 shares, would be 22% of equity"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
quant-swarm
Risk-first pre-trade checks that gate live capital — point-in-time data, invariant and leakage audits, regime probes — plus the Shadow Tournament: score your strategy genome against a live, self-evolving trading swarm's champion on identical market paths.
Built by a Principal Quantitative Technologist
Authored by the Principal Quantitative Technologist at The 1.21 Initiative — the same code path that gates live promotion and execution decisions in the trading swarm. Every tool exists because production trading systems fail in two repeatable ways: lookahead leakage in research and an oversized position in production. quant-swarm ships the checkers that prevent both, so you can audit your own work with the exact logic that guards deployed capital.
Related MCP server: financial-trading-risk-aiops-assistant
Your backtest is static. The swarm is not.
Behind this package is a swarm that does not hand-tune strategies. A champion genome runs live; every cycle the swarm breeds challengers (tier-capped mutations), replays champion and challenger on the identical episode-seed matrix across five labelled market regimes (high-vol, drawdown, chop, melt-up, gap-heavy), and records the paired outcome in an ELO ledger. A surrogate prior pre-scores candidates so expensive replays are spent where they matter. Nothing is promoted on a single good backtest: promotion requires MIN_EPISODES=20 paired episodes, a Wilcoxon-significant delta, a positive worst-regime margin (maximin, not mean), a deflated-Sharpe margin against the monotonic count of every trial ever attempted, and a PBO cap. This is the champion/challenger, self-play-style loop popularised by AlphaZero-style systems, applied honestly to markets — with the two things that do not transfer stated plainly: the market does not react to us, so there is no true self-play, and there is no learned dynamics model or tree search; selection is done by paired replay, ELO and statistical gates.
Replay is only half of it. Every Sunday the swarm also runs a forward league: each league genome — the champion, the top-ELO challengers, contributed genomes, and a planner entrant whose weekend moves are chosen by a learned model — seals its positions for the coming week from Friday's causal features, and the SHA-256 commitment is stored before the week happens. The next cycle marks every sealed position against the realised closes (net of each genome's own cost model), ranks the field on the identical real week, and updates ELO on that. Sealed forecasts cannot be overfit to the week that follows; that is the swarm's ground truth, and it feeds a replay buffer where every position is decomposed into its component moves (screen, entry, size, weekend) so credit is assigned per move and regime, not to the strategy as a blob. The forward league started on 2026-09-02; the first realised settlements land mid-September, and the swarm runs untouched for eight weeks to collect them.
What that means for you: a local backtest tells you how a strategy did on one path. The Shadow Tournament tells you whether it beats an evolving champion on the same paths, in the regime that hurts it most, at a sample size that can actually have an opinion — and your result enters the swarm's ELO ledger. Opt in as a contributor and your genome becomes an external challenger in the swarm's next breeding cycle (at half price), scored in replay and, if it earns a league seat, on real weeks. That is the flywheel: every honest submission makes the champion harder to beat, and every user gets a harder benchmark.
Why risk-first
Risk gates are not post-hoc reports — they are the pre-condition for every action. The package is organized around that constraint:
Fail-closed by default. Unknown features map to tier C, missing provenance returns
UNSCORABLE(never neutral-filled), and unverifiable tokens are refused on the hosted path. Seewarden.audit_featuresandfeatures.buildprovenance guards.Pinned, non-drifting invariants. Order sizing floors (per-name 25%, gross 60%), fill model (spread + slippage + adverse selection, both legs, always against you), and hard-constraint checks are vendored at pinned commit SHAs (
.github/pins.json, verified byte-for-byte by CI). A parity test pins the three copies of the floors (Python/MCP, C# live engine, Terraform) so they cannot drift.Point-in-time provenance. SQLite WAL cache at
%LOCALAPPDATA%\1.21-initiative\swarm-mcp\cache.db($XDG_CACHE_HOME/1.21-initiative/swarm-mcpon POSIX): finalized sessions are never re-fetched, in-progress sessions refresh at most every 60 s, earnings/news are append-only onfetched_at, andfeatures.buildruns the no-lookahead guard on every row (each feature must equal a fresh causal recomputation atas_of).Pessimistic execution.
warden.cost_checkand the simulator model the fill that hurts you; there is no optimistic fill path to inflate backtests.No order-placement code path. No tool can place, cancel, or route an order — this repository cannot trade, only refuse unsafe trades.
Statistically honest refusals. Promotion verdicts are never issued locally. Statistically undecidable outputs return
INDETERMINATE_LOCAL/UNDERPOWERED/UNSCORABLE, name the exact missing inputs (MIN_EPISODES=20, PBO, DSR, worst-regime margins), and hand off to the hosted Shadow Tournament (tournament.submit).Local-first, BYO-key: your Alpaca/AltData keys are read from env only when operating in BYOK mode; otherwise data flows through the hosted relay.
Your symbols, bars, features and orders never leave your machine. What can leave is only what you explicitly pass to
tournament.submit: the genome parameter vector (public schema fields), and — for the strategy-contributor tier — an author-written disclosure and/or your strategy code. Submitted code is never executed: it is treated as inert text, read statically by the hosted LLM reviewer, reduced to a structured explanation plus a code hash, and the raw code is discarded after review. By default even the vector is deleted from the hosted side once scored.
One-click install on Smithery:
the listing is blink-kt/quant-swarm (package and Smithery slug are both quant-swarm); the Smithery stdio launcher starts swarm-data-mcp, and the hosted streamable-HTTP endpoints below serve all three servers. Configuration is optional — without a token the servers still start and list every tool; the first call points you at the free signup. Add a token any time to unlock the relay-backed and hosted tools.
The servers
Server | Hook | Tools |
| Derived-only market signals plus point-in-time feature building |
|
| Pre-trade invariant + leakage gate — the live-capital floors and the point-in-time guards |
|
| Regime fragility locally, then the Shadow Tournament against the swarm's live champion |
|
Raw bar/enrichment access (get_bars / enrich_symbol) is internal only and no longer
registered as tools — those paths echo raw provider values, and the data policy is
derived-only: ratios, percentile ranks, labels, buckets and counts. market.pulse and
market.sentiment are the general-purpose replacements; both accept an optional bars
argument so you can supply your own OHLCV rows for symbols we don't carry.
PIT significance, explained (pit.analysis)
pit.analysis answers the question every alternative-data buyer should ask first: is this
signal real, and how do you know? It reads the release-gated pit_analysis/v2 store — the
same artifact whose rows carry the significance output for the funnel — and, per underlying,
explains every (dataset|metric|horizon) family with no guessing:
rolling_ir (52-week Spearman cross-sectional rank IC on a size/sector-neutralized metric vs neutralized forward returns), Newey-West two-sided p (
t_hac, lagceil(horizon/5)— 1m/6m horizons overlap, so the naiveIR·√nt is anti-conservative), n_obs, the research_only coverage flag and any staleness caveat.An explicit verdict per horizon: SIGNIFICANT (an L1 survivor of the same run: rolling IR > 0 and Benjamini-Hochberg q ≤ 0.05), NOT_SIGNIFICANT (with the reason — negative IR, or a nominal p that does not survive multiple-testing correction), NOT_JUDGED (below the 26-observation floor, stale release, or diagnostic-only raw level) or UNVERIFIED (no gate artifact, gate from another run, or a failed placebo — a raw p-value is never upgraded on its own).
Point-in-time: release points after
as_ofare ignored, and raw metric values are never returned — derived statistics only.
Free plans get a lite answer (one symbol per call, headline counts and the top families); Pro
unlocks 10 symbols per call, every family, full per-horizon detail and historical as_of.
The v2 methodology (neutralization + overlap-corrected inference + scale-free accounting
variants + staleness caps + a shuffled-date placebo) is recorded in every run manifest, and
v1 stores are refused rather than silently reused. Not investment advice.
Operating-area weather (market.climate)
market.climate is area-specific weather research for weather-exposed underlyings. For
each symbol it fetches the keyless Open-Meteo 14-day forecast and the same 14 calendar
days one year earlier for every operating area where the product is made and/or sold
(a shipped 10-K-style exposure-weighted registry of energy, agriculture, airline/travel,
retail, utility and homebuilder footprints), then exposure-weights per-area temperature
anomaly, HDD/CDD, precipitation/snow, wind and freeze/heat-day counts into symbol
aggregates — per-area detail is preserved so a heat wave in one harvest region stays
visible. The weather is tied to the underlying's actual geographies, never the listing
exchange or HQ city: a London forecast is not substituted for a product made and sold in
New York. For underlyings outside the shipped registry, pass areas (made/sold
geographies) and market.climate researches exactly those. Free tool, no provider
credentials; returns derived sums/means/ratios/counts/buckets only, never raw per-day
series. Forecast values are current research context and are never valid for past decision
dates.
The Shadow Tournament
gym.paired_preview is honest about being underpowered: at most 8 seeds × 2 per regime on
your cached window, every statistic labelled UNDERPOWERED, never a verdict. tournament.submit
is how a genome leaves that ceiling:
Validate locally —
warden.validate_genomereturns thegenome_hash; nothing is sent.Submit —
tournament.submit(genome, contribute=false|true). The site charges credits (200, or 100 withcontribute=true) and dispatches the job to the hosted runner.contribute=trueis the genome-contributor tier (vector licensed as an external challenger). Adddisclosureand/orstrategy_codeto enter the strategy-contributor tier: author-written decision logic and/or code for a static LLM review — the code is never executed, and leaderboard attribution plus league-seat eligibility follow review.Hosted replay on identical paths — the runner replays your genome and the swarm's current champion over the same 5 regimes × 4 per regime × 5 seeds = 100 paired episodes on the hosted
bars_1daypanel (aboveMIN_EPISODES=20), computes the Wilcoxon paired p-value, bootstrap CI, per-regime deltas and the worst-regime margin, counts hard-constraint and lookahead violations, and classifies the outcome:CHALLENGER_BEATS_CHAMPION,CHALLENGER_LOSES, orINCONCLUSIVE.ELO — the outcome updates your genome's rating against the champion (K=16, start 1500) and the champion's rating against the field.
tournament.leaderboard(free) shows the anonymised board: 12-char hash prefixes only.Poll —
tournament.verdict(job_id); no charge to poll. Runs take about two minutes.
The outcome is a tournament result, not a promotion. The promotion gate — deflated-Sharpe margin, PBO cap, the monotonic trials ledger — runs inside the swarm's private registry on genomes that qualify. That boundary is deliberate (see The IP boundary below). Replay results are the swarm's fast signal; forward-league settlements on real weeks are its slow, unfakeable one — a contributed genome that beats the champion in replay is what earns a league seat, and only realised weeks can keep it there.
What is sent: the genome parameter vector, its hash, and the contribute flag — plus, on the
strategy-contributor tier only, a disclosure and/or strategy_code (code is never executed;
the hosted reviewer reads it statically with an LLM and keeps only the structured explanation
and a code hash). Never symbols, bars, features, orders, or credentials. Retention: with
contribute=false the vector is deleted from the job record once scored — hash and outcome
remain. With contribute=true (genome or strategy tier) you license the vector and outcome to
the swarm's evolution loop, where it is registered as an external challenger
(origin=external_contribution) and put through the same tier-capped tournament and promotion
gates as the swarm's own mutants. That is why contributors pay half: your genome is the swarm's
proposer diversity, and every accepted contribution makes the next champion harder to beat — for
everyone. The strategy tier's disclosure is what additionally earns leaderboard attribution and
a league seat after review — a contributed genome that beats the champion in replay earns the
seat, and only realised forward-league weeks can keep it there.
Plans and the credit rate card
Access is tokened through https://1.21initiative.com/mcp/. One credit is the unit for everything that costs us money — a relay data call, one simulated episode of hosted compute, or a tournament run — so a pack buys a bounded amount of all of it and we never run hosted compute at a loss.
What | Credits | Notes |
Relay data call ( | 1 | any symbol count within your plan cap counts as one call |
Hosted single-shot Pro tool ( | 1 | charged only on the hosted endpoint |
Hosted gym episode ( | 1 per episode | 5 regimes × per_regime × seeds (× 2 genomes for the paired preview); |
Shadow Tournament ( | 200 — 100 with | fixed price for the full 100-paired-episode geometry vs the champion |
| 0 | local execution is never metered — your CPU, your electricity |
Free (instant token at signup): all warden checkers, the derived snapshots
market.pulse/market.sentiment/market.climate/market.regime,pit.analysislite (one symbol per call, headline counts + top families; Pro unlocks 10 symbols, every family, full per-horizon detail and historicalas_of),cache.stats,cache.offline, andtournament.leaderboard(10 symbols/call, 250 relay calls/month, 365-day backfill). No hosted compute, no GCP spend on your behalf beyond the relay allowance.Pro — one-time credit packs, self-serve: 10,000 credits for £19 or 100,000 for £149, valid 90 days, no subscription, no unlimited plan. Unlocks
features.build,cache.warm, the Pro derived tools (market.microstructure,volume.forecast,market.screen,market.rank; 50 symbols/call, full backfill), all gym tools,warden.promotion_verdict, andtournament.submit/tournament.verdict. A Starter pack is 50 tournaments — 100 as a contributor.Institutional (custom-quoted): Strategy Validation Audit engagements, custom universes, hosted league runs, SLA.
A Pro token whose pool is empty or past its 90-day window verifies with status: exhausted /
expired and the free feature set — Pro tools refuse until you buy again. Plan limits are
enforced server-side (the relay, /api/mcp/meter, /api/mcp/verify, and the hosted
streamable-HTTP endpoint return structured 402 refusals with an upgrade_url). This open-source
client's plan check is advisory: a free token calling a Pro tool gets an UPGRADE_REQUIRED
envelope — the tool still lists, and the attempt points at the upgrade page. No DRM; the free plan
is deliberately the zero-cost surface.
Point-in-time data, for real
LLM-driven research re-runs cells constantly; each re-run burns AltData (60 req/min) and
Alpaca (200 req/min) budgets re-pulling identical history — and then silently builds
features from data that did not exist at decision time. swarm-data-mcp fixes both:
SQLite (WAL) cache at
%LOCALAPPDATA%\1.21-initiative\swarm-mcp\cache.db($XDG_CACHE_HOME/1.21-initiative/swarm-mcpon POSIX).Finalized sessions are never re-fetched — zero-cost replays forever. The in-progress session refreshes at most every 60 s; enrichment every 300 s.
Earnings/news are append-only on
fetched_at: a later fetch can never rewrite an earlieras_of.Per-provider token buckets +
429exponential backoff (1s·2ⁿ).features.buildruns the no-lookahead guard on every row (each feature must equal a fresh causal recomputation atas_of) and the provenance guards on every field. Tier-B/C fields without recorded point-in-time evidence come backUNSCORABLE— never neutral-filled with0.0.
Every response carries coverage (cache vs API, oldest/newest session per symbol) and
limits (your local depth in weeks vs the tape-depth gates: 8 weeks for the tier-A
fast path, 26 weeks for tape eligibility). Below the gates you get an escalation
block naming the hosted bars_1day panel that satisfies them. Tape-tier replay is
roadmap, not available — we will not imply otherwise.
The warden
warden.validate_order is the same function that rejects live orders: per-name 25% of equity,
gross cap 60%. Per-fund overrides are allowed, but the response always reports your
deviation from the house floors. warden.audit_features flags banned actuals sources
(open-meteo.archive and friends return actuals, not what the forecast said on a past
Friday), features predating tape start, and unknown features fail closed to tier C.
warden.cost_check converts a claimed gross edge into net-of-cost reality under the pessimistic
fill model (spread + slippage + adverse selection, both legs, always against you).
warden.explain_sizing is a step-by-step mirror of the C# live risk engine, and a parity test
pins the floors against terraform and guardrails so the three copies cannot drift.
The gym
gym.probe_fragility replays your genome over the deterministic tier-A simulator and reports
per-regime net bps, the worst regime, turnover, and hard-constraint violations — never a
promotion. Seeds are capped at 8 and per_regime at 2: statistical honesty, not
artificial scarcity. Tier-B/C mutations against a champion raise the gym's
TierScoringRefusal (UNSCORABLE) instead of silently neutral-filling features the price
panel cannot provide. gym.paired_preview compares champion vs challenger on identical
market paths with the promotion gate bypassed and every statistic labelled
UNDERPOWERED, naming the exact seed count needed to clear MIN_EPISODES=20 — and every
undecidable result ends with a cloud_job block that is literally the tournament.submit call
that resolves it.
Install
Requires Python ≥ 3.11. Two ways to connect:
Remote — the hosted streamable-HTTP endpoints (same URLs as the registry entry):
https://swarm-mcp-503318750546.europe-west1.run.app/mcp/data(and/mcp/warden,/mcp/gym). Pass the token asAuthorization: Bearer <token>(or?apiToken=<token>). Claude Code:claude mcp add --transport http swarm-data https://swarm-mcp-503318750546.europe-west1.run.app/mcp/data --header "Authorization: Bearer <token>"OAuth browser-consent for web connectors is not verified yet (see
docs/DISTRIBUTION.mdOAuth gate) — use header auth until that check passes.stdio —
uvx --from quant-swarm swarm-data-mcp(andswarm-warden-mcp,swarm-gym-mcp); setSWARM_MCP_ACCESS_TOKENin the env. See the Cursor / Claude Code blocks below.One kind of credential: an access token (all three servers, optional at connect time) issued at https://1.21initiative.com/mcp/ — request access there (that's also the Strategy Validation Audit booking flow), then set
SWARM_MCP_ACCESS_TOKENin the server'senv. Clients still list the tools without a token; every call returns anACCESS_REQUIREDenvelope pointing back to the site. The token is verified against the site, and that verification is the usage meter — only the token itself is ever sent, never symbols, genomes, prices, or provider keys.
Agent snippet
Agent snippet (paste into a system prompt when wiring an agent to these tools):
Use quant-swarm MCP tools for market data, pre-trade risk checks and strategy
evidence. For alternative-data significance, call pit.analysis and quote its
verdict sentences verbatim (SIGNIFICANT / NOT_SIGNIFICANT / NOT_JUDGED /
UNVERIFIED); never upgrade a raw p-value to "significant"; its verdicts are
cross-sectional, not a forecast for one symbol. Risk refusals are final.Access token (all three servers, optional at connect time). Covered above:
SWARM_MCP_ACCESS_TOKENunlocks the relay-backed and hosted tools; without it tools still list and calls return theACCESS_REQUIREDenvelope.
The same token also feeds the hosted data relay: swarm-data-mcp serves bars and
enrichment through https://1.21initiative.com/api/mcp/..., so no Alpaca or AltData
credentials are required — the site holds the provider keys behind the relay and caches
historical bars in GCS. The relay is fail-closed: a rejected or unverifiable token means a
refused data fetch, never partial rows. The point-in-time cache semantics on the client
side are unchanged — finalized sessions are immutable in local SQLite regardless of which
data path filled them.
Official MCP Registry
Registry name io.github.blink1217/quant-swarm (this README.md carries the
mcp-name marker). Registry-aware clients get 3 stdio packages
(uvx --from quant-swarm swarm-{data,warden,gym}-mcp) plus the 3 hosted
streamable-HTTP remotes above. SWARM_MCP_ACCESS_TOKEN is optional at connect
time — without one, tools still list and calls return the access-required
envelope.
Smithery
Install blink-kt/quant-swarm from
Smithery — one listing, one token, all three servers. Smithery forwards apiToken as the
SWARM_MCP_ACCESS_TOKEN env var (stdio) or as ?apiToken= on the hosted endpoints; the
token is optional at connect time.
Cursor
Settings → MCP → Add server (or .cursor/mcp.json — a checked-in example lives at
.cursor/mcp.json):
{
"mcpServers": {
"swarm-data": {
"command": "uvx",
"args": ["--from", "quant-swarm", "swarm-data-mcp"],
"env": {
"SWARM_MCP_ACCESS_TOKEN": "<token from https://1.21initiative.com/>"
}
},
"swarm-warden": {
"command": "uvx",
"args": ["--from", "quant-swarm", "swarm-warden-mcp"],
"env": { "SWARM_MCP_ACCESS_TOKEN": "<token from https://1.21initiative.com/>" }
},
"swarm-gym": {
"command": "uvx",
"args": ["--from", "quant-swarm", "swarm-gym-mcp"],
"env": { "SWARM_MCP_ACCESS_TOKEN": "<token from https://1.21initiative.com/>" }
}
}
}Prefer a deeplink? scripts/make_deeplinks.py prints cursor://…/mcp/install links for
all three servers (base64 of the stdio config, so they cannot drift from the JSON above);
the generated list is checked in at .cursor/DEEPLINKS.md.
Claude Desktop
claude_desktop_config.json — identical mcpServers block as above.
Claude Code
stdio:
claude mcp add swarm-data --env SWARM_MCP_ACCESS_TOKEN=<token> -- uvx --from quant-swarm swarm-data-mcp
claude mcp add swarm-warden --env SWARM_MCP_ACCESS_TOKEN=<token> -- uvx --from quant-swarm swarm-warden-mcp
claude mcp add swarm-gym --env SWARM_MCP_ACCESS_TOKEN=<token> -- uvx --from quant-swarm swarm-gym-mcpremote (header auth):
claude mcp add --transport http swarm-data https://swarm-mcp-503318750546.europe-west1.run.app/mcp/data --header "Authorization: Bearer <token>"Windsurf
~/.codeium/windsurf/mcp_config.json — the same stdio JSON shape as the Cursor block
above. For the hosted endpoints use the serverUrl form instead:
{
"mcpServers": {
"swarm-data-remote": {
"serverUrl": "https://swarm-mcp-503318750546.europe-west1.run.app/mcp/data"
}
}
}(The hosted endpoints accept the token as Authorization: Bearer <token> or as
?apiToken=<token>.)
The warden and gym are pure checkers and the data server fetches through the hosted relay, so no server needs provider keys — only the access token.
Local development: operators of this repo can bootstrap offline by setting
SWARM_MCP_LOCAL_TOKEN to the same value as SWARM_MCP_ACCESS_TOKEN (documented
bypass; token verification against the site is skipped and the token gets the full
Pro entitlement — it is a local override on your own machine).
Swarm operators (internal): to fetch directly from the providers instead of the
relay, set SWARM_MCP_BYOK=1 plus ALPACA_API_KEY/ALPACA_SECRET/ALTDATA_API_KEY
on swarm-data-mcp. Public users should leave SWARM_MCP_BYOK unset.
Hosting the remote endpoint yourself: swarm-mcp-http validates the Host header
(DNS-rebinding protection). The defaults allow 1.21initiative.com, the project's Cloud
Run hostname, the Smithery gateway, and localhost; SWARM_MCP_ALLOWED_HOSTS
(comma-separated) extends the defaults — it never replaces them, so a custom domain
cannot accidentally lock out the Cloud Run URL. SWARM_MCP_REMOTE_URL overrides the
advertised endpoint base, and SWARM_MCP_TOKEN_VERIFY_URL overrides the verify endpoint.
See the Dockerfile for the container form.
The hosted endpoint meters compute (swarm_mcp/metering.py): before a Pro compute tool runs it
charges POST {SWARM_MCP_RELAY_URL}/meter with the caller's token, and refuses (JSON-RPC -32003,
HTTP 402/429/503) when the meter refuses or is unreachable — hosted compute is never served
unmetered. The Shadow Tournament runner lives in the same service: the site dispatches jobs to
POST /internal/tournament/run guarded by the shared secret SWARM_MCP_INTERNAL_KEY, the runner
fills its panel through the relay with SWARM_MCP_SERVICE_TOKEN (an institutional token, so
users are never billed for the runner'"'"'s own data), scores against SWARM_MCP_CHAMPION_GENOME
(path to the registry's current champion — required via SWARM_MCP_CHAMPION_GENOME;
no packaged fallback is shipped), and calls back POST {relay}/tournament/complete. SWARM_MCP_TOURNAMENT_UNIVERSE and
SWARM_MCP_TOURNAMENT_LOOKBACK_DAYS shape the hosted panel. The runner scores in a background task
after answering 202, so the Cloud Run service must run with CPU always allocated
(--no-cpu-throttling) and a request timeout of at least 300 s; with request-based CPU the task
starves after the response and the job is refunded as failed.
The IP boundary (what ships, what doesn't)
This repository ships checkers only: order checks, provenance guards, the
pessimistic fill model, the genome schema, provenance tiers, hard-constraint checking,
gate thresholds, the tier-A gym simulator, and the regime labeller — vendored at pinned
commit SHAs (.github/pins.json, verified by CI).
The selection machinery stays server-side and is not in this repo: objective scoring,
deflated-Sharpe estimation, and the promotion-gate decision. Any request for a promotion
verdict returns INDETERMINATE_LOCAL with the exact missing statistical inputs
(MIN_EPISODES=20, PBO ≤ 0.30 via combinatorially-symmetric splits, DSR margin with the
monotonic trials ledger, worst-regime margin across all 5 regimes × seeds), plus:
an
audit_requestblock — genome hash + violation summary, no proprietary payload;a
cloud_jobspec that is thetournament.submitcall which resolves it.
The Shadow Tournament runner in this repo computes paired statistics and an outcome on
identical paths; it does not contain, and a CI test (tests/test_ip_boundary.py) forbids, the
objective, the DSR estimator, or the promotion decision. Contributed genomes that beat the
champion are handed to the swarm's private registry, where those gates run. The Strategy
Validation Audit at https://1.21initiative.com/ remains the
route for multi-genome league runs, custom universes, and NDA'"'"'d live metrics.
Telemetry
Off by default, opt-in only (SWARM_MCP_TELEMETRY_OPT_IN=opt-in), counters only
(tool name, success flag, coarse duration). Never symbols, genomes, prices, or
credentials. Institutional buyers read the source; silent phone-home destroys the wedge.
Contributors additionally disclose telemetry scope in their submission (see the
strategy-contributor tier above).
The exceptions are by contract and explicit:
Access-token verification. When a token is set and no local bootstrap token matches, the token is POSTed to the verify endpoint (default
https://1.21initiative.com/api/mcp/verify, overrideSWARM_MCP_TOKEN_VERIFY_URL), at most once per 5 minutes per process. Only the token is sent; the gate fails closed if the endpoint is unreachable or rejects the token.Relay data calls carry the token plus the symbols/days you asked for (that is the request). Relay calls are metered server-side per call.
tournament.submitsends the genome vector, its hash and thecontributeflag — the one tool that ships a strategy artefact, and it says so in its output every time.
Development
pip install -e ".[test]"
py -3.11 -m pytest # full suite (see Step 2 count in docs/DISTRIBUTION.md)
scripts\vendor.ps1 # re-vendor the pinned checker subset
py -3.11 scripts\check_pin.py # vendored tree == pins.jsonVendoring uses the sibling checkouts of the private repos at the pinned SHAs
(-FromWorktree bootstraps before the pin commit exists). CI mirrors the swarm's own
guardrails-invariants gate: it checks out the pinned SHAs and verifies the committed
vendored tree byte-for-byte (and the stripped subsets transform-for-transform), then runs
the guardrails' own invariant suite at the pinned SHA.
License
Wrapper code: MIT (see LICENSE). The vendored guardrails checker subset under
swarm_mcp/vendored/guardrails/ is distributed under the source-available terms in
swarm_mcp/vendored/guardrails/LICENSE.md. The excluded selection machinery is not
licensed.
The gym is the tier-A price subset. The tape_replay service does not exist publicly. Tier-B/C scoring is hosted-only. The Shadow Tournament returns paired outcomes, never promotions. Anything else would be fabricated evidence — and this repo refuses to fabricate.
Available Tools
6 toolswarden.audit_featuresAudit Feature ManifestARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest | Yes | Feature manifest: [{name, source, value_ts, as_of}] to audit. | |
| tape_started | No | Optional tape start date (YYYY-MM-DD); features predating it are flagged. | |
| selected_symbols | No | Optional challenger-selected symbols for the coverage check. | |
| snapshot_universe | No | Optional archived snapshot universe to measure coverage against. |
Output Schema
| Name | Required | Description |
|---|---|---|
| how | No | |
| tool | No | |
| error | No | |
| access | No | |
| verdict | No | |
| coverage | No | |
| features | No | |
| provenance | No | |
| violations | No | |
| request_access_at | No | |
| banned_actuals_sources | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail: it flags banned actuals sources, features predating tape start, unknown features fail closed to tier C, and an optional coverage check against MIN_COVERAGE=0.90. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core action is front-loaded, the manifest structure is given compactly, and the optional coverage check is described in one clause. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover the safety profile, the description is highly complete: it explains what gets flagged, the fail-closed behavior, and the optional coverage mode. Minor gaps such as what exactly 'tier C' means or how output is structured are covered by the schema or context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description enriches parameter meaning by explaining the manifest shape ({name, source, value_ts, as_of}) and the purpose of selected_symbols/snapshot_universe in the coverage check with the absolute MIN_COVERAGE=0.90 threshold.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Audit a feature manifest for lookahead leakage and provenance violations.' It then details the exact checks performed, which clearly distinguishes this tool from sibling tools like cost_check, validate_order, and promotion_verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when you need to audit a feature manifest for lookahead/provenance issues. However, it never explicitly states when not to use it or names alternative tools that might be more appropriate for related validation tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warden.cost_checkCost CheckARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spread_bps | Yes | Average bid-ask spread in bps. | |
| slippage_bps | Yes | Expected slippage in bps. | |
| gross_edge_bps | Yes | Claimed gross edge in basis points before costs. | |
| adverse_selection_bps | Yes | Adverse-selection drag in bps. |
Output Schema
| Name | Required | Description |
|---|---|---|
| how | No | |
| tool | No | |
| error | No | |
| access | No | |
| verdict | No | |
| provenance | No | |
| gross_edge_bps | No | |
| net_return_bps | No | |
| one_way_cost_bps | No | |
| request_access_at | No | |
| round_trip_cost_bps | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: costs are charged at both entry and exit, always against the position, and the model matches the gym's scoring. This goes beyond the annotations and clarifies the pessimistic nature of the calculation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core purpose, the second explains the model. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculation tool, the description covers the model, and the output schema is present (not shown but indicated). Annotations cover safety. There is nothing an agent needs to invoke it correctly that is missing; the cost model is fully disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions, so the baseline is 3. The description adds meaning by stating that all costs (spread, slippage, adverse selection) are applied at both entry and exit, which clarifies how the parameters are used together. This is useful but not deeply per-parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Convert') and a clear resource ('a claimed gross edge into net-of-cost reality'), and it distinguishes itself from siblings by naming the 'pessimistic fill model' that the gym uses. This is unambiguous and separates it from validation or audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies when to use it (when you have a gross edge and want the net after costs), but it does not explicitly state when NOT to use it or name alternatives. Sibling tools like validate_order or explain_sizing have different purposes, so the context is somewhat inferable, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warden.explain_sizingExplain SizingARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| close | Yes | Current close/reference price. | |
| atr_14 | Yes | 14-bar average true range of the instrument. | |
| equity | Yes | Account equity (base currency). | |
| overnight_gap | No | Expected overnight gap (price units); gaps above 1.2x ATR halve size. | |
| gross_exposure | No | Current portfolio gross exposure in currency. | |
| floor_overrides | No | Optional per-fund overrides; deviation from house floors is reported. | |
| weekend_approaching | No | True when the position would be held into the weekend (gross headroom applies). |
Output Schema
| Name | Required | Description |
|---|---|---|
| how | No | |
| qty | No | |
| tool | No | |
| error | No | |
| steps | No | |
| access | No | |
| safety | No | |
| reasons | No | |
| verdict | No | |
| notional | No | |
| provenance | No | |
| trail_stop | No | |
| house_floors | No | |
| request_access_at | No | |
| overrides_deviation | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safe read-only profile is covered. The description adds valuable behavioral context: it is a step-by-step mirror of the live engine, covers specific sizing rules, and reports house floors plus any deviation when per-fund overrides are supplied. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool's core purpose, followed by a compact enumeration of the sizing components and the output behavior. Every phrase earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only explanatory tool with an output schema and fully documented parameters, the description provides enough context about the calculation components and updated behavior. It omits guidance on output shape, but that is handled by the output schema. The only meaningful gap is usage guidance versus siblings, which is captured in dimension 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add per-parameter detail beyond the schema, but it does connect parameters like atr_14, overnight_gap, and weekend_approaching to the algorithm narrative. It adds no new format, unit, or threshold information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what the tool does: it mirrors the live C# risk engine sizing step-by-step and reports house floors and deviations. It names specific components (ATR sizing, position-notional cap, overnight-gap halving, weekend gross headroom), which makes the purpose concrete. It doesn't explicitly contrast with sibling tools, but the resource and behavior are distinct enough that an agent can infer its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus siblings like warden.cost_check, validate_order, audit_features, validate_genome, or promotion_verdict. The description implies it is for explaining sizing calculations, but it does not state that explicitly, nor does it list exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warden.promotion_verdictRequest Promotion VerdictARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| champion_genome | No | Optional current champion genome; mutation tiers vs it are reported. | |
| challenger_genome | Yes | The challenger genome under evaluation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| how | No | |
| why | No | |
| tool | No | |
| error | No | |
| access | No | |
| safety | No | |
| verdict | No | |
| cloud_job | No | |
| audit_request | No | |
| missing_inputs | No | |
| regimes_required | No | |
| request_access_at | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral detail: the result is always INDETERMINATE_LOCAL, selection is server-side, missing statistical inputs are named, and the tool emits an audit_request plus a cloud_job spec. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the most important behavioral fact, and no filler. Every clause adds information about the outcome, outputs, or server-side behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, annotations cover safety, and the schema covers parameters. The description fills the behavioral gap with the invariant and emitted artifacts. Lacking only explicit context on when this tool should be preferred over the listed sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description mentions 'missing statistical inputs' and mutation tiers indirectly, but adds no per-parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Request') and resource ('promotion verdict'), and immediately states the defining invariant: 'Always INDETERMINATE_LOCAL'. This clearly distinguishes it from siblings like warden.validate_genome and warden.explain_sizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named. The only contextual clue is the title and the invariant, which imply a promotion-verdict use case, but the agent is left to infer when to choose this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warden.validate_genomeValidate GenomeARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| genome | Yes | Genome object (bounded schema, versioned). |
Output Schema
| Name | Required | Description |
|---|---|---|
| how | No | |
| note | No | |
| tool | No | |
| error | No | |
| valid | No | |
| access | No | |
| errors | No | |
| genome_hash | No | |
| schema_version | No | |
| request_access_at | No | |
| schema_version_current | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds value by explaining the hash's purpose and the bounded-schema constraint, which goes beyond the structured data. It does not repeat or contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary action and result are front-loaded, and the second sentence provides essential context about the hash's usage. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations cover safety, the output schema presumably defines the return format, and the description explains the hash's purpose, the tool is adequately complete. It does not cover failure modes, but those are likely in the output schema or not needed for a simple read-only validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema already describes the genome object as 'bounded schema, versioned.' The description echoes this without adding new parameter semantics, so it meets the baseline but adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (validate), a specific resource (genome), and a concrete outcome (return canonical genome_hash). It distinguishes from siblings like cost_check, validate_order, and audit_features by focusing on genome validation and the hash's role in tournament identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by explaining the hash's purpose (challenger_id, audit_request), but does not explicitly exclude alternatives or state when-not-to-use. The sibling names are clearly different, so context is sufficient though not explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warden.validate_orderValidate OrderARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | Proposed order: {symbol, notional, side: buy|sell}. | |
| equity | Yes | Account equity (base currency) used for the exposure floors. | |
| floor_overrides | No | Optional per-fund overrides {max_position_pct, max_gross_exposure_pct}; the response always reports the deviation from the house floors. | |
| current_positions | No | Optional {symbol: notional} map of current positions. |
Output Schema
| Name | Required | Description |
|---|---|---|
| how | No | |
| tool | No | |
| error | No | |
| access | No | |
| safety | No | |
| verdict | No | |
| provenance | No | |
| violations | No | |
| house_floors | No | |
| fund_overrides | No | |
| post_gross_pct | No | |
| rejection_quote | No | |
| post_position_pct | No | |
| request_access_at | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description reveals meaningful behavior: the response always reports deviation from house floors, rejections quote the exact floor, and this same function gates live capital. This adds decision-relevant context that the annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core purpose first, then briefly enumerates the key inputs and behaviors. Every sentence contributes useful information, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core validation thresholds, input shapes, override semantics, output behavior, and production relevance. Since an output schema exists, return values do not need to be spelled out here, and the annotation set already covers safety and idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds extra semantic value by explaining the house-floor numbers, the order shape, and that overrides still report deviations from the house floors rather than the overridden values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Validate'), a resource ('a proposed order'), and the exact scope ('against the house floors', max position 25%, gross cap 60%). It clearly distinguishes this from the sibling tools by stating the validation semantics and noting it is 'the same function gating live capital.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's intended use obvious: validate a proposed order against exposure floors, with optional per-fund overrides and current positions. It does not explicitly name when to prefer this over siblings like cost_check or validate_genome, but the context is clear enough that an agent should not confuse them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v0.4.1- First observed
warden.audit_features - First observed
warden.cost_check - First observed
warden.explain_sizing - First observed
warden.promotion_verdict - First observed
warden.validate_genome - First observed
warden.validate_order
TDQS
Scored across 6 tools
Each tool targets a distinct risk/validation concern: cost modeling, order validation, feature auditing, genome validation, sizing, and promotion verdicts. The shared warden prefix reinforces domain cohesion without making the tools interchangeable.
All names are snake_case with a consistent warden. prefix, and most follow a verb_noun pattern like validate_order and audit_features. cost_check and promotion_verdict are minor deviations from the verb-first convention, but the overall style is still predictable and readable.
With six tools, the server is well-scoped for its purpose: validating, sizing, auditing, and gating trading swarm decisions. Every tool has a clear role, and none feels like redundant filler.
The set covers the core workflow: cost adjustment, order gating, feature provenance, genome identity, sizing logic, and promotion intake. Minor gaps exist around directly inspecting live positions or submitting the emitted audit/cloud jobs, but agents can work around these with input parameters and external follow-up.
Maintenance
Related MCP Connectors
A paid remote MCP for hosted MCP server, built to return verdicts, receipts, usage logs, and audit-r
Remote MCP for A2A failure replay MCP, structured receipts, audit logs, and reviewer-ready evidence.
A paid remote MCP for Equibles, built to return verdicts, receipts, usage logs, and audit-ready JSON
A paid remote MCP for HyperFrames, built to return verdicts, receipts, usage logs, and audit-ready J
Related MCP Servers
- AlicenseAqualityAmaintenanceLocal-first production-readiness MCP server for AI-built apps. It runs read-only checks, produces an evidence-based readiness score, and guides fixes before launch.115Apache 2.0
- AlicenseNot gradedqualityAmaintenanceProvides read-only MCP tools for market snapshots, position risk, order reconciliation, and daily report previews with deterministic financial calculations, evidence chains, and audit trails.MIT
- AlicenseNot gradedqualityAmaintenanceA local-first, deterministic, read-only MCP server that audits test suites for false-green tests, tautological assertions, and mock-contract drift, ensuring tests truly validate production code. It provides tools to detect test fidelity issues, verify mock drift, and synthesize strict mock contracts.MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for natural-language daily stock/ETF strategy backtesting. It provides constrained tools for strategy specification, data validation, queue-based backtests, and verifiable result artifacts.1Apache 2.0