Skip to main content
Glama

quant-swarm

PyPI PyPI Downloads Licence Smithery Official MCP Registry

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: Momus-MCP

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. See warden.audit_features and features.build provenance 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-mcp on POSIX): finalized sessions are never re-fetched, in-progress sessions refresh at most every 60 s, earnings/news are append-only on fetched_at, and features.build runs the no-lookahead guard on every row (each feature must equal a fresh causal recomputation at as_of).

  • Pessimistic execution. warden.cost_check and 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

swarm-data-mcp

Derived-only market signals plus point-in-time feature building

market.pulse, market.sentiment, market.climate, market.regime, market.microstructure, volume.forecast, market.screen, market.rank, pit.analysis, features.build, cache.warm, cache.stats, cache.offline

swarm-warden-mcp

Pre-trade invariant + leakage gate — the live-capital floors and the point-in-time guards

warden.validate_order, warden.audit_features, warden.cost_check, warden.validate_genome, warden.explain_sizing, warden.promotion_verdict

swarm-gym-mcp

Regime fragility locally, then the Shadow Tournament against the swarm's live champion

gym.label_regimes, gym.probe_fragility, gym.paired_preview, gym.estimate_cloud_run, tournament.submit, tournament.verdict, tournament.leaderboard

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, lag ceil(horizon/5) — 1m/6m horizons overlap, so the naive IR·√n t 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_of are 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:

  1. Validate locally — warden.validate_genome returns the genome_hash; nothing is sent.

  2. Submit — tournament.submit(genome, contribute=false|true). The site charges credits (200, or 100 with contribute=true) and dispatches the job to the hosted runner. contribute=true is the genome-contributor tier (vector licensed as an external challenger). Add disclosure and/or strategy_code to 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.

  3. 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_1day panel (above MIN_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, or INCONCLUSIVE.

  4. 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.

  5. 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 (/data/bars, /data/enrich, /data/pit)

1

any symbol count within your plan cap counts as one call

Hosted single-shot Pro tool (features.build, warden.promotion_verdict, gym.label_regimes, gym.estimate_cloud_run)

1

charged only on the hosted endpoint

Hosted gym episode (gym.probe_fragility, gym.paired_preview)

1 per episode

5 regimes × per_regime × seeds (× 2 genomes for the paired preview); gym.estimate_cloud_run prices any geometry before you run it

Shadow Tournament (tournament.submit)

200 — 100 with contribute=true

fixed price for the full 100-paired-episode geometry vs the champion

tournament.verdict, tournament.leaderboard, all warden checkers, cache.*, local stdio runs of any tool

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.analysis lite (one symbol per call, headline counts + top families; Pro unlocks 10 symbols, every family, full per-horizon detail and historical as_of), cache.stats, cache.offline, and tournament.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, and tournament.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-mcp on 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 earlier as_of.

  • Per-provider token buckets + 429 exponential backoff (1s·2ⁿ).

  • features.build runs the no-lookahead guard on every row (each feature must equal a fresh causal recomputation at as_of) and the provenance guards on every field. Tier-B/C fields without recorded point-in-time evidence come back UNSCORABLE — never neutral-filled with 0.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 as Authorization: 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.md OAuth gate) — use header auth until that check passes.

  • stdio — uvx --from quant-swarm swarm-data-mcp (and swarm-warden-mcp, swarm-gym-mcp); set SWARM_MCP_ACCESS_TOKEN in 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_TOKEN in the server's env. Clients still list the tools without a token; every call returns an ACCESS_REQUIRED envelope 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_TOKEN unlocks the relay-backed and hosted tools; without it tools still list and calls return the ACCESS_REQUIRED envelope.

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-mcp

remote (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_request block — genome hash + violation summary, no proprietary payload;

  • a cloud_job spec that is the tournament.submit call 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, override SWARM_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.submit sends the genome vector, its hash and the contribute flag — 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.json

Vendoring 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

8 tools
warden.audit_featuresAudit Feature ManifestA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
manifestYesFeature manifest: [{name, source, value_ts, as_of}] to audit.
tape_startedNoOptional tape start date (YYYY-MM-DD); features predating it are flagged.
selected_symbolsNoOptional challenger-selected symbols for the coverage check.
snapshot_universeNoOptional archived snapshot universe to measure coverage against.

Output Schema

NameRequiredDescription
howNo
toolNo
errorNo
accessNo
verdictNo
coverageNo
featuresNo
provenanceNo
violationsNo
request_access_atNo
banned_actuals_sourcesNo

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral substance beyond that: banned actuals sources (open-meteo.archive), fail-closed treatment of unknown features to tier C, and the MIN_COVERAGE=0.90 threshold used for the optional coverage check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the manifest shape, then the checks, then the optional mode. Dense and largely waste-free, though the second paragraph is a run-on sentence that could be split for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and annotations cover safety. The description covers the checks, fail-closed behavior, and the coverage threshold. It could be more explicit about severity/format of the flags, but nothing an agent must know to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3, but the description goes further by naming the manifest item shape {name, source, value_ts, as_of}, which the schema does not expose (items are additionalProperties:true with no declared properties). It also explains the semantics of the coverage parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (audit) plus resource (feature manifest) and the two things it checks: lookahead leakage and provenance violations. It is clearly distinct from the sibling family (validate_order, plan_rebalance, promote/validate_genome, etc.), so an agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The domain implies when to use it (pre-flight review of a feature manifest), and it hints at a conditional mode ('optional coverage check for challenger-selected symbols'), but it never says when-not or names an alternative tool. Usage context is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

warden.cost_checkCost CheckA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
spread_bpsYesAverage bid-ask spread in bps.
slippage_bpsYesExpected slippage in bps.
gross_edge_bpsYesClaimed gross edge in basis points before costs.
adverse_selection_bpsYesAdverse-selection drag in bps.

Output Schema

NameRequiredDescription
howNo
toolNo
errorNo
accessNo
verdictNo
provenanceNo
gross_edge_bpsNo
net_return_bpsNo
one_way_cost_bpsNo
request_access_atNo
round_trip_cost_bpsNo

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral semantics beyond them: the cost model is 'pessimistic,' costs are charged at BOTH entry and exit, and 'always against the position' (i.e. never credited in the trader's favor). That materially changes how an agent should interpret the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the core transformation before the mechanics. No filler; the closing gym reference is a slight flourish but reinforces model consistency. Slightly jargon-dense but appropriately sized for the task.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, read-only math tool with an output schema and full annotation coverage, the description supplies what's needed: purpose, cost model, and application semantics. Return values need not be explained since an output schema exists. Only explicit sibling routing is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each bps parameter is already documented. The description still adds value by explaining how the parameters combine and are applied twice (spread + slippage + adverse selection charged at entry and exit), which goes beyond the flat per-parameter definitions in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: 'Convert a claimed gross edge into net-of-cost reality.' An agent can immediately tell this is an edge-cost computation rather than a validation/planning/sizing tool like its siblings. It stops short of explicitly naming any alternative (e.g. explain_sizing), so it isn't a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the word 'claimed' suggests it is for stress-testing a user-supplied edge, and 'the same model the gym scores every episode with' hints at consistency with scoring. There is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

warden.explain_sizingExplain SizingA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
closeYesCurrent close/reference price.
atr_14Yes14-bar average true range of the instrument.
equityYesAccount equity (base currency).
overnight_gapNoExpected overnight gap (price units); gaps above 1.2x ATR halve size.
gross_exposureNoCurrent portfolio gross exposure in currency.
floor_overridesNoOptional per-fund overrides; deviation from house floors is reported.
weekend_approachingNoTrue when the position would be held into the weekend (gross headroom applies).

Output Schema

NameRequiredDescription
howNo
qtyNo
toolNo
errorNo
stepsNo
accessNo
safetyNo
reasonsNo
verdictNo
notionalNo
provenanceNo
trail_stopNo
house_floorsNo
request_access_atNo
overrides_deviationNo

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the exact decision chain applied (notional cap, gap halving above 1.2x ATR, weekend gross headroom) and that it surfaces house floors plus any deviation when overrides are supplied. It stops short of stating deterministic/purity guarantees or how overrides are keyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core identity (mirror of the live C# risk engine sizing) front-loaded and the override/deviation behavior appended. The step list doubles as mechanism description rather than padding, though the run-on enumeration is dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value explanation is not required, and the description covers the algorithm stages plus floor/override reporting for a 7-parameter financial calculator. Remaining gaps are minor: no statement of units, determinism, or that inputs must match the live engine's configuration to reproduce a size.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so 3 is the baseline; the description goes beyond the schema by linking mechanics to parameters — overnight_gap to 'overnight-gap halving', weekend_approaching/gross_exposure to weekend gross headroom, floor_overrides to house-floor deviation reporting. That causal linkage is real meaning the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (explain/mirror) and resource (the live sizing algorithm) and enumerates exactly which computations it reproduces: ATR sizing, position-notional cap, overnight-gap halving, weekend gross headroom. This is unmistakably distinct from siblings such as validate_order, cost_check, or plan_rebalance, which compute or check rather than explain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The framing as a 'step-by-step mirror of the live C# risk engine' implies this is the tool to call when you want to understand or justify a size calculation, and the mention of reporting deviations with per-fund overrides implies a diagnostic use case. However, it never states when to use this versus a sibling like validate_order, nor does it name any alternative or exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

warden.optimize_portfolioOptimize Portfolio WeightsA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
top_kNoMaximum number of active risk slots to select.
methodNoAllocation method: vol_target_momentum | hrp | mvo_shrinkage.vol_target_momentum
candidatesYesCandidate risk assets: [{symbol, momentum_score, realized_vol_annual, above_trend_sma?, chandelier_triggered?, current_weight?}].
turnover_capNoMaximum one-way portfolio turnover fraction per rebalance.
floor_overridesNoOptional per-fund overrides {max_position_pct, max_gross_exposure_pct}.
cash_proxy_symbolNoDefensive cash proxy ticker receiving unallocated weight.SGOV
target_volatilityNoTarget annualized portfolio volatility (e.g. 0.12 for 12%).
cash_momentum_scoreNoComposite momentum score of the defensive cash proxy.

Output Schema

NameRequiredDescription
howNo
toolNo
errorNo
accessNo
methodNo
safetyNo
verdictNo
provenanceNo
filtered_outNo
house_floorsNo
target_weightsNo
cash_proxy_symbolNo
cash_sweep_weightNo
request_access_atNo
overrides_deviationNo
selected_risk_assetsNo
gross_risk_exposure_pctNo
estimated_turnover_one_wayNo
estimated_portfolio_vol_annualNo

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real behavioral context: residual capital is swept to the defensive cash proxy, house concentration and turnover caps are enforced, and it explicitly declares it never places or routes trades. That last point is valuable disambiguation from order-execution siblings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with the core computation front-loaded, plus a short exclusions clause. 'Pro tool.' is terse but arguably conveys tiering; nothing is bloated, though the trailing fragment is slightly cryptic.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be described. With 8 fully documented params, read-only annotations, and stated caps and cash-sweep behavior, the definition is nearly complete; it only lacks guidance on choosing between this and the rebalance/explain siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 8 params, so the baseline is 3. The description echoes the three method names and mentions caps and the cash proxy, but adds no syntax, units, or interaction guidance (e.g., how floor_overrides interact with the house caps) beyond what the schema documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb ('Computes') and resource ('portfolio weights'), and enumerates the three distinct allocation methods (dual-momentum, HRP, shrinkage mean-variance). This is far more precise than siblings like explain_sizing or plan_rebalance, letting an agent route correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage: the tool computes weights and never routes trades, so an agent can infer it slots before plan_rebalance/validate_order. But there is no explicit 'use this when X, use sibling Y instead' guidance, and 'Pro tool' hints at gating without saying how it affects selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

warden.plan_rebalancePre-Trade Rebalance Risk GateA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
equityYesCurrent account equity in base currency.
quotesNoOptional quote snapshot {symbol: {bid, ask} or {mid, spread_bps}}.
feature_psiNoOptional Population Stability Index of input features (>0.25 halts risk additions).
max_spread_bpsNoMaximum allowed bid-ask spread in bps before rejecting execution.
target_weightsYesTarget portfolio weights {symbol: weight_fraction}.
drift_thresholdNoMinimum weight drift fraction required to trigger a rebalance step.
high_water_markYesPortfolio historical high-water mark equity.
limit_collar_bpsNoMarketable limit price collar around midprice in bps.
cash_proxy_symbolNoDefensive cash sweep ticker.SGOV
current_positionsNoOptional current position notionals {symbol: notional}.
max_drawdown_limitNoMaximum drawdown from high-water mark before circuit-breaker liquidation.

Output Schema

NameRequiredDescription
howNo
toolNo
errorNo
accessNo
safetyNo
verdictNo
provenanceNo
drawdown_pctNo
house_floorsNo
sequenced_planNo
psi_drift_trippedNo
request_access_atNo
spread_violationsNo
circuit_breaker_trippedNo
effective_target_weightsNo
skipped_within_drift_bandNo

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=true, idempotent=true, destructive=false and closed-world, so safety is covered. The description adds real behavioral substance beyond that: the four named gates, the sell-before-buy sequencing intent, and the explicit statement that it never routes trades. It does not, however, say what happens on a breach (halt vs. partial plan vs. rejection), which is the key operational behavior an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with no filler, and the enumeration of checked guards is front-loaded. The jargon load is high but each clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, nested-object planning tool with an output schema (so return format needn't be explained), the description gives enough to know the decision logic involved. The gap is the post-evaluation contract — what a breach produces and how the ordered sell/buy steps are surfaced — which the output schema may cover.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 11 parameters and the baseline is 3. The description gestures at several parameters — the 3% turnover buffer (drift_threshold), marketable limit collars (limit_collar_bps), the bid-ask spread gate (max_spread_bps), the drawdown breaker (max_drawdown_limit) — but without syntax, units, or interaction detail beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Checks') plus a precisely enumerated resource: the drawdown circuit breaker, feature drift guard, turnover drift buffer, and spread gate. The closing clause 'never routes trades' clearly separates it from an execution tool. It stops short of naming which sibling (e.g., validate_order) to prefer, so it is clear but not sibling-differentiating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The title 'Pre-Trade Rebalance Risk Gate' and the gate-checking framing imply this belongs before order submission, but the description never states when to call it versus warden.validate_order or warden.cost_check. Usage must be inferred from the tool's name and position in a pipeline.

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 VerdictA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
champion_genomeNoOptional current champion genome; mutation tiers vs it are reported.
challenger_genomeYesThe challenger genome under evaluation.

Output Schema

NameRequiredDescription
howNo
whyNo
toolNo
errorNo
accessNo
safetyNo
verdictNo
cloud_jobNo
audit_requestNo
missing_inputsNo
regimes_requiredNo
request_access_atNo

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds high-value behavioral disclosure beyond them: the tool never decides locally, it names missing statistical inputs, and it emits an audit_request plus a cloud_job spec. It does not discuss auth or the hosted-tournament submission lifecycle, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the request action and immediately followed by the key caveat before the emission details. No filler, though the phrasing is slightly compressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still flags the invariant INDETERMINATE_LOCAL outcome and the emitted artifacts, which is exactly the extra completeness an agent needs. For a two-param nested-genome tool it is nearly complete, missing only where the emitted cloud_job goes next.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 champion_genome and challenger_genome, including default null and mutation-tier reporting. The description adds nothing about parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Request') and resource ('promotion verdict'), and adds a crucial semantic detail: the tool's local result is always INDETERMINATE_LOCAL because selection is server-side. It doesn't name or distinguish sibling tools like validate_genome or audit_features, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The always-INDETERMINATE_LOCAL statement implies this is a local triage/request tool rather than a decision tool, which gives some usage context. However, it never says when to reach for this versus validate_order, plan_rebalance, or the other siblings, and offers no exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

warden.validate_genomeValidate GenomeA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
genomeYesGenome object (bounded schema, versioned).

Output Schema

NameRequiredDescription
howNo
noteNo
toolNo
errorNo
validNo
accessNo
errorsNo
genome_hashNo
schema_versionNo
request_access_atNo
schema_version_currentNo
evaluated_schema_versionNo

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine non-obvious context beyond that: the hash is a reproducible strategy identity reused as challenger_id and in audit_request blocks, which is behavior an agent could not infer from the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with the verb and result front-loaded, followed by the one piece of downstream context that matters. No filler, no repetition of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the annotations cover safety, so the description need not explain return shapes or side effects, and the hash semantics are covered anyway. The one omission is failure behavior — what a validation rejection looks like — which matters for a validator but is a minor gap given the structured coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'genome' parameter is documented as a versioned bounded schema, so the schema carries the meaning. The description only restates 'validated against the bounded schema' without adding format, version, or constraint detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Validate a genome') and names the concrete output ('return its canonical genome_hash'), so the agent knows exactly what it gets back. It is implicitly distinguished from the sibling warden.validate_order by resource, but no sibling is named or contrasted explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the seven siblings. Usage is only implied by the note that the hash feeds the hosted tournament and audit_request blocks, which hints at the workflow context without stating it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

warden.validate_orderValidate OrderA
Read-onlyIdempotent
Inspect

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.

NameRequiredDescriptionDefault
orderYesProposed order: {symbol, notional, side: buy|sell}.
equityYesAccount equity (base currency) used for the exposure floors.
floor_overridesNoOptional per-fund overrides {max_position_pct, max_gross_exposure_pct}; the response always reports the deviation from the house floors.
current_positionsNoOptional {symbol: notional} map of current positions.

Output Schema

NameRequiredDescription
howNo
toolNo
errorNo
accessNo
safetyNo
verdictNo
provenanceNo
violationsNo
house_floorsNo
fund_overridesNo
post_gross_pctNo
rejection_quoteNo
post_position_pctNo
request_access_atNo

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description earns credit for adding real behavior: per-fund overrides are permitted but the response always reports deviation from house floors, and rejections quote the exact floor. The 'same function gating live capital' note is meaningful operational context that the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the actual floor thresholds, then input shapes, then override/rejection behavior. Dense and mostly waste-free, though the order/current_positions restatement duplicates the schema rather than adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary. The description covers the key behavioral edges an agent needs — overrides, deviation reporting, exact-floor rejection text, and live-capital gating — though it says nothing about units, edge cases such as missing symbols, or whether validation is purely advisory.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so order, equity, floor_overrides, and current_positions are already documented in the schema. The description restates the order and current_positions shapes verbatim and repeats the floor_overrides deviation wording, adding essentially no semantics beyond the structured fields. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Validate a proposed order') and immediately grounds it in concrete domain semantics (house floors: max position 25%, gross cap 60%). It does not explicitly name a sibling to contrast with, but the pre-trade order-validation purpose is distinct from plan_rebalance, validate_genome, and explain_sizing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'the same function gating live capital' signals this is the pre-trade check before capital is committed. There is no explicit when-to-use, when-not-to-use, or named alternative among the seven siblings.

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.

  1. 3 tool updatesv0.6.2
    • Addedwarden.optimize_portfolio
    • Addedwarden.plan_rebalance
    • Changedwarden.validate_genome3 fields changed
      • addedOutput schema / properties / evaluated_schema_version
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "integer"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "title": "Evaluated Schema Version"
        +}
      • addedOutput schema / properties / schema_version / anyOf
        Added value: +[
        +  {
        +    "type": "integer"
        +  },
        +  {
        +    "type": "string"
        +  },
        +  {
        +    "type": "null"
        +  }
        +]
      • removedOutput schema / properties / schema_version / type
        Removed value: -"integer"
  2. 6 tool updatesv0.4.1
    • First observedwarden.audit_features
    • First observedwarden.cost_check
    • First observedwarden.explain_sizing
    • First observedwarden.promotion_verdict
    • First observedwarden.validate_genome
    • First observedwarden.validate_order

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    A 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    MCP 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.
    1
    Apache 2.0