# com.alphaassay/mcp (remote · mcp.alphaassay.com)

Fail-closed backtest/signal validation: overfitting, leakage, deflated Sharpe. NOT financial advice.

- Trust score: 59/100 (low)
- Change this week: +7
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.alphaassay.com`: 59/100 (this document), [markdown](https://verifymcp.io/servers/com-alphaassay-mcp/mcp.md), [page](https://verifymcp.io/servers/com-alphaassay-mcp/mcp)

## Channel facts

- Endpoint: `https://mcp.alphaassay.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.6.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 66/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (assay_signal).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 20/100
  - AI-judged instruction clarity (poor).
  - Context-footprint check failed: tool/resource definitions use about 11990 tokens (~570/item across 21 items; 21 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-alphaassay-mcp https://mcp.alphaassay.com/mcp
```

### Codex

```toml
[mcp_servers.com-alphaassay-mcp]
url = "https://mcp.alphaassay.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-alphaassay-mcp": {
      "type": "remote",
      "url": "https://mcp.alphaassay.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-alphaassay-mcp --url https://mcp.alphaassay.com/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-alphaassay-mcp:
    url: "https://mcp.alphaassay.com/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-alphaassay-mcp": {
      "type": "http",
      "url": "https://mcp.alphaassay.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 59, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 58, +4)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 54, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 54, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 53, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 52, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 51)

First indexed and scored.

## MCP tools (21)

### `assay_demo` (~196 tokens)

Inspect a sample AlphaAssay verdict

Use this when you want to see AlphaAssay's exact verdict envelope --
schema, findings, leakage taxonomy -- on a built-in example before
spending a check. A methodology audit; no buy/sell advice.
Free demo verdict -- see AlphaAssay's full output shape in one call.

Runs the real fail-closed validator over a built-in 40-trade example and
returns the complete verdict envelope (verdict, qualitative findings,
leakage taxonomy, provenance hashes) plus the machine-readable
remediation explanation -- and a free synthetic-null preview: three
seeded no-edge worlds (Heston stochastic volatility, Merton jump
diffusion, symmetric drift bursts) showing the process-placebo
machinery the paid falsify battery attacks your strategy with. No
auth, no payment, no input needed. Use this first to understand the
schema before submitting your own strategy with assay_signal.
Price: free.

Output parameters:

- `result` (object): All three documented demo responses under one closed public contract.

### `assay_signal` (~909 tokens)

Validate a trading signal or track record

Use this when you have a backtest result or live track record (a
trades log, equity curve or QuantConnect export) and need to know
whether the edge is real or just overfitting, survivorship or luck.
Validate a trading strategy export: fail-closed statistical verdict.

Reality-check for backtest results, trade lists and equity curves
(overfitting detection, deflated Sharpe, multiple-testing deflation via
n_trials, cost stress, look-ahead signature, sample-size floor).
Accepts CSV text (trade list with pnl / return %, equity curve, signal
series) or a QuantConnect/LEAN backtest JSON -- crypto, stocks, futures,
FX alike. Returns pass / conditional / fail / insufficient_evidence with
qualitative findings and canonical provenance hashes; code-computed, no
LLM scoring. Declare n_trials honestly (omitting it earns a named TRIALS_UNDISCLOSED finding): it is the count of variants you
searched to find this one (best-of-N selection from a parameter sweep);
the verdict then answers whether the winner is real or an artifact of
the search. Optional pit_evidence attaches an
already-computed point-in-time / look-ahead guard report (e.g. a
same-session vs prior-settle rank-consistency check): an explicit
computed material_look_ahead verdict hard-fails the submission
(pit_lookahead); missing or inconclusive evidence changes nothing --
the field can demote, never bless. Optional source_rights attaches attested data-rights evidence: an explicit negative (source_rights_clean=false or a missing_source_rights status) withholds any positive outcome as insufficient_evidence with agent_action=owner_data_decision_required (a verdict on data you may not use is a liability, not evidence); fail stays fail, unclear evidence changes nothing. NOT a buy/sell signal. Price: per check; see https://api.alphaassay.com/v1/meta/pricing. Debited from your prepaid account (api_key required --
create one at https://api.alphaassay.com/account; the current allowance
is published by runtime pricing).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `equity_csv` (string): Equity-curve CSV (timestamp,equity) as an alternative to trades_csv; per-period returns are derived from it.
- `fee_bps_per_side`: Round-trip cost assumption in basis points per side (slippage + commission) for the net-of-cost reality check.
- `label` (string): Optional human label for the run (echoed back, not scored).
- `n_trials`: How many strategy variants you tried before this one (grid size / optimisation attempts). Drives the deflated-Sharpe multiple-testing correction -- under-reporting it inflates your own verdict.
- `out_of_sample`: True if the track record is genuine out-of-sample / walk-forward, not the in-sample fit.
- `pit_evidence`: Optional point-in-time / look-ahead attestation object; can only demote (flag pit_lookahead), never improve the verdict.
- `quantconnect_json`: Optional QuantConnect backtest export; parsed into trades/returns automatically.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `signals_csv` (string): Signal/position CSV if you have entries rather than realised pnl; converted to returns before grading.
- `source_rights`: Optional data-rights / provenance disclosure for the track record (licensing, vendor).
- `trades_csv` (string): Your realised trade log as CSV (pnl and/or return_pct per closed trade) -- the track record to put on trial for overfitting and luck.

Output parameters:

- `result` (object)

### `assay_reproduce` (~729 tokens)

Reproduce a claimed track record

Use this when someone hands you a claimed track record and you want
to recompute it yourself from the fills and candles -- an arithmetic
audit of the numbers, not buy/sell advice.
Independently recompute a claimed track record -- audit the
arithmetic, not the story.

New audit object: not the signal, the CALLER'S CALCULATION. Send the
trades (entry/exit time, price, side), the candles they were filled
on, and the claimed headline metrics (total_return_pct, win_rate,
max_drawdown_pct, n_trades, sharpe_annualized); the engine rebuilds
the equity book independently and grades the claim against disclosed
per-metric tolerances (published cross-engine divergence reaches
3.71%, so the band is explicit output, never a hidden judgment).
Checks every fill against its bar's [low, high] (a fill outside the
range was never physically available: FILL_OUTSIDE_BAR_RANGE), prices
formally undecidable stop/limit exits worst-case -- both bracket
levels inside one OHLC bar cannot be ordered (Maier-Paape/Platen) --
and reports that fill-ambiguity haircut (FILL_AMBIGUITY_MATERIAL when
worst-case pricing flips the book's sign). Also returns an
implementation-uncertainty interval: every fill pushed to the best and
worst end of its bar, the spread a legitimate re-implementation could
produce; a claim outside EVERY convention earns
RESULT_NOT_REPRODUCED. Demote-only: 'reproduced' means the numbers
follow from the fills -- it is NOT evidence of an edge and never
endorses a strategy. Code-computed; no ledger write (auditing
arithmetic is not a new trial). Timestamps must carry explicit
timezones; structurally invalid input is refunded. NOT financial
advice. Price: per check; see https://api.alphaassay.com/v1/meta/pricing
(api_key required -- account setup at
https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `claimed`: The performance the seller claims (e.g. total return / Sharpe) so the audit can confirm or refute it.
- `fee_bps_per_side`: Round-trip cost in bps/side for the recomputation.
- `ohlcv_by_symbol`: Candles per symbol {symbol: {time,open,high,low,close,volume}} the trades were supposedly filled on -- used to catch fills outside the bar range.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `trades`: The claimed fills to audit: entry/exit time, price and side per trade -- checked arithmetically against the bars.

Output parameters:

- `result` (object)

### `assay_tradelog` (~584 tokens)

Audit a trade log for contradictions

Use this when you have a raw fill or trade log and want it scanned
for internal contradictions -- look-ahead timestamps, pnl that
disagrees with the row's own prices, duplicate or out-of-order fills.
Interrogate a raw fill log for internal contradictions -- no
candles needed.

assay_preflight lints shape, assay_reproduce audits arithmetic
against candles; this tool needs nothing but the log itself and asks
whether it is internally consistent: exact duplicate fills (double
counting inflates every headline number: tradelog_duplicate_fills),
time travel (exits before entries, decisions stamped AFTER the entry
they supposedly caused: tradelog_time_travel -- the anatomy of a
look-ahead), PnL or return_pct contradicting the row's own prices
(tradelog_pnl_inconsistent), naive/unparseable/future timestamps
(tradelog_timestamps_invalid -- ambiguous clocks are the top source
of fake edges), and fills booked outside the declared calendar
(tradelog_outside_calendar, e.g. weekend fills under
trading_calendar='weekdays'). Checks run only where fields exist and
the report SAYS which ran (checks_run) -- an absent field is
untestable, never innocent. Demote-only: a defect-free log earns
'conditional', because internal consistency is NOT evidence of an
edge. Code-computed; no ledger write; structurally invalid input is
refunded. NOT financial advice. Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `trades`: Raw trade/fill rows to scan for defects: look-ahead timestamps, pnl or return contradicting the row's own prices, duplicate or out-of-order fills.
- `trading_calendar` (string): Supported market-calendar literal: '24/7' for continuous markets or 'weekdays' for a Monday-Friday calendar.

Output parameters:

- `result` (object)

### `assay_forensics` (~467 tokens)

Diagnose signal timing leakage

Use this when a signal looks good but you suspect leakage or
look-ahead and want to know WHY it fails, not just that it fails --
a diagnostic audit, it does not give buy/sell advice.
Leakage forensics: WHY your signal fails, not just that it fails.

Upload your own decision timestamps (symbol, decision_time with explicit
timezone, long/short) plus OHLCV candles and get a forensic diagnosis:
does the edge collapse with a realistic one-bar execution delay
(look-ahead leak)? Does the move happen BEFORE your decision
(front-loading / anticipation)? Does it beat matched random timing? Do
your trades collapse onto few independent events? Code-computed,
demote-only, plain-language explanations per finding. Naive timestamps
are rejected -- timezone ambiguity is the top source of fake edges.
Price: per check; see https://api.alphaassay.com/v1/meta/pricing
(api_key required -- account setup at
https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `ohlcv_by_symbol` (object, required): Candles per symbol the events are scored against for the look-ahead / front-loading forensics.
- `primary_horizon` (integer): Forward horizon in bars the signal claims to predict, for the leakage attribution.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `signal_events` (array, required): Signal decisions with the schema-accepted fields {decision_time, symbol, direction, confidence?} to test for timing leakage.

Output parameters:

- `result` (object)

### `assay_backtest` (~669 tokens)

Run a family-deflated backtest assay

Use this when you want a code-computed DSL backtest whose deflated-
Sharpe verdict still means something after repeated searching -- every
run is priced into your family's trial ledger. A research audit, not
buy/sell advice.
Ledger-aware DSL backtest with honest family-level trial accounting.

Define the strategy as an executable JSON DSL (indicators: sma, ema, rsi,
atr, roc, zscore, price; ops: cross_above, cross_below, gt, lt, and, or,
not), supply your own candles, and get net-of-cost per-bar returns plus a
deflated-Sharpe family verdict. Every call is recorded in your family's
trial ledger, so repeated searching deflates future verdicts -- that is
the feature, not a bug: the verdict stays meaningful. The ledger is
keyed to your authenticated account, never to a caller-supplied name.
Data minimisation on request: sketch_opt_out=true skips persisting the
32-bucket return sketch -- the honest price is that without provable
proximity this trial counts IN FULL toward the family budget (no
evidence, no discount; the response discloses sketch_retained). Included
in the flat price. The response is code-computed and ledger-dependent: a
new call can change the family budget. Byte-identical output is promised
only by stored replay of the same non-empty request_id with the same
canonical request. Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `fee_bps_per_side`: Round-trip cost in bps/side for net returns.
- `ohlcv_by_symbol` (object, required): Your candles per symbol to run the DSL rule on.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `sketch_opt_out` (boolean): True to skip persisting the 32-bucket return sketch (data minimisation); the trial then counts in full toward the family budget.
- `spec` (required): Executable JSON DSL strategy (indicators sma/ema/rsi/atr/roc/zscore/price; ops cross_above/cross_below/gt/lt/and/or/not) -- the rule to backtest and record in your family ledger.
- `variants_in_call` (integer): How many sibling variants this call represents, for honest family-level trial accounting.

Output parameters:

- `result` (object)

### `assay_gauntlet` (~784 tokens)

Run the adversarial signal gauntlet

Use this when you want the whole reality-check battery on a strategy
in one call -- overfitting, leakage, costs, regimes and a matched-random
placebo -- as a demote-only dossier, never buy/sell advice.
The full reality-check battery in ONE call -- validator, family
deflation, matched-random placebo, capacity ceiling and graveyard prior
chained into a single consolidated dossier. Instead of pass/fail you get
WHICH gate killed the signal first (machine-readable failure_codes), the
placebo percentile, the tradable capacity ceiling, how often the family
was already buried, and the family's remaining search budget. Built for
iterating agents: it is training feedback with budget economics, not a
bare verdict. Supply the strategy as an executable DSL spec plus your own
candles; optional per-symbol ADV in USD unlocks the capacity gate, and
optional per-symbol daily volatility (sigma_by_symbol_pct, percent) sharpens
its impact model for volatile assets. Trading perpetuals? Supply
funding_by_symbol ({symbol: [{ts, rate}, ...]}, decimal per-settlement
rates, positive = longs pay) and the funding_edge stage charges the
funding leg against every holding period: it kills what only looked
profitable because funding was ignored (funding_erases_edge) and what
is carry income masquerading as timing skill (edge_is_funding_carry);
a series that fails its own audit keeps the funding question open
instead of acquitting. Data minimisation on request: sketch_opt_out=true
skips persisting the 32-bucket return sketch, and the trial counts IN
FULL toward the family budget (no evidence, no discount -- disclosed in
the budget block). The response is code-computed and ledger-dependent: a
new call can change the family budget. Byte-identical output is promised
only by stored replay of the same non-empty request_id with the same
canonical request. Demote-only.
Price: per check; see https://api.alphaassay.com/v1/meta/pricing
(api_key required -- account setup at
https://api.alphaassay.com/account).

Input parameters:

- `adv_by_symbol_usd`: Average daily dollar volume per symbol, for the capacity / market-impact stress.
- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `fee_bps_per_side`: Round-trip cost in bps/side.
- `funding_by_symbol`: Per-symbol funding-rate series so the funding-edge stage can net carry out of the edge.
- `ohlcv_by_symbol` (object, required): Your candles per symbol for the gauntlet.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `sigma_by_symbol_pct`: Per-symbol volatility (%) input for the risk/capacity cells when you have it.
- `sketch_opt_out` (boolean): True to skip the return sketch (data minimisation).
- `spec` (required): Executable JSON DSL strategy to run the full battery on.
- `variants_in_call` (integer): Sibling-variant count for family trial accounting.

Output parameters:

- `result` (object)

### `assay_falsify` (~500 tokens)

Falsify a strategy against synthetic nulls

Use this when you want your strategy actively attacked -- execution
lag, cost stress, regime split, parameter neighbourhood, drift-burst --
to see what kills it first. Demote-only; it does not give buy/sell advice.
We do not check your signal -- we actively try to KILL it. An adversary
runs a battery of stress attacks against your strategy (execution-lag push,
cost stress, time jackknife, regime split, parameter-neighbourhood
perturbation, combinatorial purged CPCV partitions, synthetic no-edge
worlds, drift-burst window stripping -- does the PnL survive without
its flash-crash bars?) and returns a survival map: which attack kills
it first,
which it withstands and up to what limit, plus a weakest-link headline.
The graveyard sharpens the attack order -- families that mostly died of
cost get cost-stressed first. Surviving every attack is the strongest
evidence of robustness this platform can give (still not a profit promise).
Supply an executable DSL spec + your own candles. Code-computed,
demote-only. Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `fee_bps_per_side`: Round-trip cost in bps/side for the cost stress.
- `ohlcv_by_symbol` (object, required): Your candles per symbol for the attack battery.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `spec` (required): Executable JSON DSL strategy to attack with the survival map.

Output parameters:

- `result` (object)

### `assay_pbo` (~654 tokens)

Measure probability of backtest overfitting

Use this when you have the T x N returns of a grid search and want
the probability of backtest overfitting (PBO, CSCV) -- did the sweep
find an edge or manufacture one? A demote-only audit, not buy/sell advice.
Did your parameter sweep FIND an edge -- or manufacture one? PBO over
the whole trial matrix.

Submit the full T x N payoff matrix of every configuration you tried
(rows = time-ordered per-period returns, columns = the candidates from
your grid search / parameter sweep / optimisation run) and get the
Probability of Backtest Overfitting via combinatorial symmetric
cross-validation (CSCV, Bailey/Borwein/Lopez de Prado/Zhu 2017) with
purge and embargo against overlapping-label leakage: the fraction of
train/test splits in which your in-sample winner ranks at or below the
out-of-sample median. The dossier adds the performance-degradation slope
(does out-of-sample decay as in-sample shines?), the probability of
out-of-sample loss, and first-order stochastic dominance of your
selected picks versus the whole pool. Complements the trial ledger: the
ledger counts how many tries your family burned, PBO grades whether the
SELECTION PROCESS itself is overfit -- PBO >= 0.5 earns the named demote
PBO_HIGH. Exhaustive enumeration with nothing to seed,
fail-closed on undersized, oversized or non-numeric input. Demote-only:
it can kill a selection, never bless one. NOT a buy/sell signal.
Price: per check; see https://api.alphaassay.com/v1/meta/pricing
(api_key required -- account setup at
https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `embargo` (integer): Extra embargo bars after each test block.
- `n_groups` (integer): Number of CSCV partitions (even; combinatorial in/out-of-sample splits).
- `periods_per_year`: Annualisation factor for the reported Sharpes.
- `purge` (integer): Bars purged around each split to break serial-correlation leak.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `returns_matrix` (array, required): T x N matrix: per-period returns for each of your N grid/sweep configurations -- the raw material for probability-of-backtest-overfitting (CSCV).

Output parameters:

- `result` (object)

### `assay_var_es` (~929 tokens)

Backtest VaR and expected shortfall forecasts

Use this when you have VaR or Expected-Shortfall forecasts and need
to know whether reality breached them more often or deeper than your
claimed tail level allows -- a risk-forecast audit, not buy/sell advice.
Does your risk model's VaR/ES forecast survive contact with reality?
Exceedance backtest over YOUR forecasts -- a new claim type: risk
numbers, not return claims.

Submit realised per-period returns plus the VaR forecasts your model
produced ex ante (positive loss thresholds at tail level alpha, e.g.
0.05 for a 95% VaR), optionally the matching expected-shortfall
forecasts. The breach count is graded on the EXACT binomial Basel
traffic-light zones (Basel Committee 1996: green below cumulative
probability 0.95, yellow to 0.9999, red above) -- published boundaries,
no house thresholds; red earns the named demote VAR_BREACH_RATE_EXCESS.
Kupiec's proportion-of-failures LR (1995) and Christoffersen's
independence LR (1998) ride along -- clustered breaches flag the
advisory var_breaches_clustered (a model blind to volatility
clustering). If ES forecasts are supplied, a joint (VaR, ES) mixture
e-process (e-backtesting, Wang & Ziegel) grades breach DEPTH: crossing
Ville's anytime-valid 1% line earns ES_TAIL_UNDERSTATED. Supply
benchmark_var_forecasts (and optionally benchmark_es_forecasts, e.g. a
rolling historical quantile) and the assay also tests EQUAL PREDICTIVE
ABILITY: Diebold-Mariano (1995) on a strictly consistent loss (quantile
tick, or the joint FZ0 loss of Fissler & Ziegel 2016 when both sides
carry ES) -- a naive benchmark that beats your model past the one-sided
5% line earns RISK_FORECAST_DOMINATED_BY_BENCHMARK; the attention zone
to 10% is the advisory risk_forecast_lags_benchmark. Demote-only:
too many breaches can kill, too few is the mis-calibration advisory
var_breach_rate_sparse -- conservative models pass with a flag, never
a blessing. Code-computed end to end, fail-closed on malformed or
undersized input (a series too short to reach the red zone…

Input parameters:

- `alpha`: Tail level, e.g. 0.05 for a 95% VaR (0.001-0.25). Sets the Basel traffic-light expectation.
- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `benchmark_es_forecasts`: Optional benchmark ES forecasts; switches the EPA test to the joint FZ0 loss.
- `benchmark_var_forecasts`: Optional naive/benchmark VaR forecasts (e.g. a rolling historical quantile) for the Diebold-Mariano equal-predictive-ability test -- lose to it and the claim is demoted.
- `es_forecasts`: Optional matching expected-shortfall forecasts; enables the joint (VaR, ES) e-process tail test.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `returns` (array, required): Realised per-period returns (the outcomes your risk model was forecasting for).
- `var_forecasts` (array, required): Your model's ex-ante VaR forecasts (positive loss thresholds at level alpha) to backtest for breaches.

Output parameters:

- `result` (object)

### `assay_conformal` (~675 tokens)

Audit conformal interval coverage

Use this when your model emits prediction intervals or confidence
bands and you want to audit whether realised outcomes actually fall
inside them at the claimed coverage -- a calibration audit, not advice.
Does your model's confidence label survive contact with outcomes?
Coverage audit over prediction intervals -- confidence claims are the
third claim type after return claims and risk forecasts.

Submit the prediction intervals your ML model produced (lower and upper
bounds, one pair per point), the realised outcomes, and the coverage
the model claims (e.g. 0.9). The miss count is graded against the EXACT
distribution that claim implies: binomial for a pointwise claim, or --
when you disclose the split-conformal calibration_size -- the
beta-binomial the split-conformal guarantee actually promises (Vovk
2012: realised coverage is Beta-distributed around the claim), so a
CORRECT procedure with a small calibration set is never punished for
its honest variance. Zones reuse the same traffic-light boundaries as
the VaR cell (green below cumulative probability 0.95, yellow to
0.9999, red above); red earns the named demote
CONFORMAL_COVERAGE_SHORTFALL. Efficiency is disclosed, never assumed:
intervals wider than the whole observed outcome range flag the advisory
conformal_intervals_uninformative (coverage bought by construction),
over-conservative intervals flag conformal_overcovered -- advisories,
never kills, demote-only throughout. Code-computed end to end,
fail-closed on malformed, inverted, undersized or oversized input.
References: Vovk/Gammerman/Shafer 2005; Lei et al., JASA 2018. NOT
financial advice; no order path.
Price: per check; see https://api.alphaassay.com/v1/meta/pricing
(api_key required -- account setup at
https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `calibration_size`: Optional size of the calibration set used to build the intervals; enables the exact beta-binomial (small-sample-fair) grading.
- `claimed_coverage`: The coverage level you claim, e.g. 0.9 for 90% prediction intervals.
- `intervals_lower` (array, required): Lower bounds of your prediction intervals, per point.
- `intervals_upper` (array, required): Upper bounds of your prediction intervals, per point.
- `outcomes` (array, required): Realised outcomes each interval was meant to cover.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…

Output parameters:

- `result` (object)

### `assay_survivors` (~637 tokens)

Run a stepwise survivor reality check

Use this when you ran a grid or parameter sweep and want to know
WHICH variants survive family-wise error control (FWER) rather than
surfacing by chance -- an error-budget disclosure, not buy/sell advice.
WHICH variants of your sweep survive family-wise error control --
an error-budget disclosure, never a ranking.

Send the same T x N trial matrix assay_pbo grades (rows =
time-ordered periods, columns = every configuration you tried) and
get Romano-Wolf stepwise multiple testing over it: studentized
per-config statistics, circular block bootstrap over the time rows
(serial dependence respected), stepdown max-statistic critical values
(Romano/Wolf 2005, Econometrica; Hansen SPA 2005). Answer, per
variant IN INPUT ORDER: could this family's evidence kill it at
family-wise error rate alpha, and in which stepdown round? Survival-
map framing by construction: the verdict vocabulary is fail (nothing
survives: NO_SURVIVORS_AT_FWER), conditional (survivors disclosed --
explicitly NOT a pass) or insufficient_evidence (blocked with a named
reason); this tool structurally cannot bless, rank or recommend.
Natural partner of assay_pbo -- one matrix, two questions: is the
SELECTION overfit (pbo), and which variants does the error budget
leave standing (survivors). The bootstrap is seeded from the input
digest; fail-closed on size, budget and numerics; no ledger
write. NOT financial advice. Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `alpha`: Family-wise error rate to control (e.g. 0.05).
- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `block_length`: Stationary-bootstrap block length (bars) to preserve serial correlation.
- `n_bootstrap` (integer): Bootstrap resamples for the stepwise multiple test.
- `periods_per_year`: Annualisation factor for reporting.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `returns_matrix`: The same T x N trial matrix assay_pbo grades (rows = periods, columns = strategies) -- here for FWER survivor analysis: which survive multiple-testing.

Output parameters:

- `result` (object)

### `assay_cpcv` (~658 tokens)

Run combinatorial purged cross-validation

Use this when you have a return history and want the full
combinatorial purged cross-validation (CPCV) distribution -- not one
walk-forward number -- to see how path-dependent the edge really is.
The FULL combinatorial purged CV distribution over your return
history -- not one number, the whole picture.

The gauntlet's cpcv stage answers a single question; this tool hands
over everything behind it: the annualized Sharpe of EVERY purged
combinatorial half-partition of your history as quantiles (worst,
p05..p95, best) and a histogram, the number of recoverable full
backtest paths (phi = C(N, N/2) * (N/2) / N, Bailey/Lopez de Prado),
purge/embargo accounting, and the documented demote line: fewer than
60% of partitions with a positive Sharpe = cpcv_unstable
(Arian/Norouzi/Seco, Knowledge-Based Systems 305, 2024 --
combinatorial purged CV dominates walk-forward at false-discovery
prevention). Send a net-return series directly, OR a DSL spec +
candles (the series is computed with the same primitives the
gauntlet uses). Exhaustive enumeration with no RNG and nothing to seed;
fail-closed on every structural shortfall. Demote-only: a pass
means this one attack did not bite, never an endorsement. No ledger
write. NOT financial advice. Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `embargo` (integer): Embargo bars after each test block.
- `fee_bps_per_side`: Round-trip cost in bps/side.
- `n_groups` (integer): Number of combinatorial purged CV groups (even).
- `ohlcv_by_symbol`: Candles per symbol when a spec is supplied.
- `periods_per_year`: Annualisation factor for the reported Sharpes.
- `purge` (integer): Bars purged around each test block to stop leakage.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `returns`: Per-period returns of the strategy to cross-validate.
- `spec`: Optional DSL spec if you want CPCV to recompute from rules.

Output parameters:

- `result` (object)

### `assay_batch` (~691 tokens)

Assay a parameter sweep as one batch

Use this when you optimised over a grid and want to submit the WHOLE
sweep honestly -- every variant a ledger trial the family budget prices,
so selection bias cannot hide. A research audit, not buy/sell advice.
Submit your WHOLE parameter sweep honestly -- one call, every variant
a ledger trial.

You searched N variants; showing only the winner is exactly the
selection bias the family budget prices. This tool makes the honest
path the cheap path: send up to 25 DSL spec variants (as a specs list,
OR base_spec + grid of dot-paths like {"signal.left.window": [2,3,4]}
\-- the built-in sweep adapter expands it in canonical order), plus your
candles. Every variant is recorded in your family's trial ledger and
verdicted with the CUMULATIVE deflation its siblings created -- later
variants see the budget the earlier ones burned. The report is
demote-only by construction: survives/deflated_out counts and
per-variant verdicts, never a ranking, never a best pick. Metering is
per valid processed variant (journaled individually,
settle-before-run); if credit runs out mid-batch you get exactly what
was paid for and an explicit declined count -- no silent truncation.
Data minimisation on request: sketch_opt_out=true applies to every
variant -- no return sketches persisted, every variant counts IN FULL
toward the family budget (no evidence, no discount; disclosed per
variant). The response is code-computed and ledger-dependent: a new call
can change the family budget. Byte-identical output is promised only by
stored replay of the same non-empty request_id with the same canonical
request. NOT a buy/sell signal. Price: per valid variant; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `base_spec`: Base DSL spec to expand with grid instead of listing specs explicitly.
- `fee_bps_per_side`: Round-trip cost in bps/side.
- `grid`: Parameter grid {param: [values]} expanded against base_spec into the full variant set.
- `ohlcv_by_symbol`: Your candles per symbol for every variant.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `sketch_opt_out` (boolean): True to skip return sketches for every variant.
- `specs`: Explicit list of DSL strategy variants to submit as one honest sweep -- every variant a ledger trial the family budget prices.

Output parameters:

- `result` (object)

### `assay_register` (~704 tokens)

Pre-register a sealed strategy hypothesis

Use this when you want to seal a strategy and its success criteria
NOW, before the forward data exists, so that registration cannot be
adapted or backfilled against those later bars -- a commitment audit,
not buy/sell advice. Pre-register a signal NOW; freeze its terms before
the forward evidence exists.

Signal commitment: your strategy spec (executable JSON DSL) is canonically
hashed and committed in tenant state now, then queued for later daily
operator-published Merkle inclusion. The register response is not an
inclusion proof, and the built-in chain is not independent time evidence;
that requires a separately present and pinned external anchor. The
later verdict (assay_verdict) uses exclusively data from AFTER
registration. That prevents adapting this registration to those forward
bars, but does not prove the strategy or family was not selected through
earlier research or repeated trials; the family ledger and deflation
disclose and penalise those trials. v2: optionally seal a machine-writable HYPOTHESIS tuple
alongside the spec -- declared_pass_sharpe_annualized (your
pre-committed success bar), max_evaluation_bars (ex-ante window cap:
waiting longer than promised cannot improve the verdict),
fee_bps_per_side and trading_calendar (the sealed evaluation terms),
plus an optional rationale. The tuple is canonically hashed and bound
into the same queued commitment as the spec, and assay_verdict ENFORCES
it: deviating terms are recomputed under the seal and flagged
goalpost_moved -- success criteria chosen after seeing the data are
not criteria. Registrations are idempotent, withdrawals still count
toward your family's trial budget (anti-gaming). Registrations are
keyed to your authenticated account. Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key with the register
scope required -- account setup at
https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `embargo_bars` (integer): Bars after registration to embargo before evaluation.
- `hypothesis`: Your sealed success criteria (target metric, threshold, costs) so the later verdict cannot move the goalposts.
- `maturity_bars` (integer): Bars of forward data required before assay_verdict may evaluate it (the maturity window).
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `spec` (required): DSL strategy whose canonical hash and terms are committed to tenant state now, before forward data, and queued for later daily operator-published Merkle inclusion. The return is not an inclusion proo…

Output parameters:

- `result` (object)

### `assay_verdict` (~497 tokens)

Evaluate a matured pre-registration

Use this when a signal was pre-registered with assay_register and the
maturity window has passed -- get the post-cutoff verdict computed only
from data after registration. A sealed audit, it gives no buy/sell advice.
Post-cutoff verdict under the registration's sealed terms.

Evaluates a registration strictly on bars AFTER the registration cutoff,
with maturity floor and fail-closed data-gap handling (use
trading_calendar='weekdays' for equity daily bars so weekends do not
count as gaps; omit fee/calendar to use the registration's sealed
terms). The verdict embeds the family-deflated Sharpe: even an
anchored signal is deflated by how much its family was searched. For
v2 registrations with a sealed hypothesis, the verdict additionally
reports oos_sharpe_annualized against the pre-committed bar
(threshold_met -- a descriptive fact, never an endorsement) and flags
goalpost_moved when the requested terms deviate from the sealed ones
(the seal always wins). Price: per check; see
https://api.alphaassay.com/v1/meta/pricing (api_key required -- account
setup at https://api.alphaassay.com/account).

Input parameters:

- `api_key` (string): API key for a paid MCP check. Hosted Streamable HTTP clients should send it in the Authorization: Bearer transport header so the model never sees the secret; local stdio callers may supply the raw ke…
- `fee_bps_per_side`: Round-trip cost in bps/side.
- `ohlcv_by_symbol` (object, required): Post-registration candles per symbol to evaluate the sealed strategy on.
- `prereg_id` (string, required): Id returned by assay_register; the verdict uses ONLY data from after that registration.
- `request_id`: Optional idempotency key for this paid execution. Retry the same request_id with the same payload to replay one stored result without another charge; reuse with a different payload returns idempotenc…
- `trading_calendar`: Market calendar for the instrument.

Output parameters:

- `result` (object)

### `assay_graveyard` (~235 tokens)

Inspect anonymised strategy-family mortality

Use this when you want to check, for free, how often a signal family
(e.g. sma_cross) has already been falsified and what usually kills it,
before spending a check. Anonymised stats only -- no buy/sell advice.
Free lookup: how often has this signal family already died?

Anonymised falsification statistics per structural signal family --
tested / killed / survived counts, top kill reasons, and the crowd prior
your submission would be deflated by. Check BEFORE you spend weeks on an
idea whether the crowd already buried it. k-anonymous: families with
fewer than 5 distinct submitters fall back to coarser taxonomy stats.
Price: free.

Input parameters:

- `fingerprint` (string): Optional precomputed family fingerprint if you have it (skips the name lookup).
- `strategy` (string): Strategy family name to look up in the anonymised graveyard, e.g. 'sma_cross' -- what usually kills it.
- `timeframe` (string): Optional bar interval to filter the family stats.
- `variant`: Optional variant params to narrow the family lookup.

Output parameters:

- `result` (object)

### `assay_calibration` (~173 tokens)

Read the validator calibration snapshot

Use this when you want to inspect AlphaAssay's current public
calibration state for free rather than trust marketing. Calibration v0 is
a population/status disclosure, not an outcome score or track record.

Self-calibration of the validator's mature pre-registration population:
the published contract exposes a bucketed evaluated-registration counter,
an explicit forward-outcomes status of accumulating, and
honesty=insufficient_history until a separate mature-outcome metric exists.
It does not score historical audit, shape, or forensics results as forward
predictions. A fresh verified
snapshot is signed with the platform key; missing, expired or invalid
evidence fails closed as signed=false and stale=true with a reason code.
It is population and status evidence only, not a performance claim.
NOT financial advice. Price: free.

Output parameters:

- `result` (object)

### `assay_certificate_verify` (~215 tokens)

Verify an AlphaAssay certificate against platform trust

Use this when someone hands you a signed AlphaAssay certificate and
you want to verify both its Ed25519 signature and current platform trust.
A verification tool, not buy/sell advice.
Verify a signed AlphaAssay certificate against externally rooted public trust.

This hosted verifier evaluates full platform trust. The caller PEM is key
evidence, never a trust root. A full valid result additionally requires
the service's externally pinned signed keyring, complete revocation-head
history, retained certificate-purpose key and no matching revocation.
alphaassay-verify signature-only checks raw cryptographic evidence offline;
full offline trust also requires the signed trust bundle and independent
root/checkpoint pins. Price: free.

Input parameters:

- `certificate` (object, required): The separately issued signed certificate/document object to verify against current platform trust.
- `public_key_pem` (string, required): Caller-supplied signer-key evidence in PEM form; it is not a platform trust root.
- `signature_b64` (string, required): Its base64 Ed25519 signature.

Output parameters:

- `result` (object)

### `assay_provider_protocol` (~287 tokens)

Read the signal-provider falsification protocol

Use this when you want to judge ANY signal seller -- including us --
with a machine-readable seven-test falsification protocol you can run
in an afternoon. It scores methodology, not markets: no buy/sell advice.
Test ANY signal provider in an afternoon -- the falsification
protocol as machine-readable rules.

Seven falsifiable tests that separate edge from selection, runnable
against any signal seller (paid channel, platform, bot) without their
cooperation: provenance (tamper-proof timestamps or it did not happen),
survivorship (the full issue history incl. losers), pre-registration
(ten sealed forward calls), placebo (does random timing do as well?),
costs (profitable AFTER fees/spread/slippage?), trial accounting (one
winner out of how many quiet attempts?), and the examiner test (apply
it all to whoever grades the signals -- including AlphaAssay: golden
specimens, hosted full-trust certificate verification with separate raw
signature-only and full offline trust paths, current persisted calibration
snapshot).
Each
test carries a machine-checkable failure_condition, and tests 3-6 name
the AlphaAssay endpoint that automates them. Static and code-computed:
this tool hands you the checklist, it does not rate, score or rank any
provider and it never fetches external data. NOT financial advice.
Price: free.

Output parameters:

- `result` (object)

### `assay_preflight` (~339 tokens)

Lint an assay payload before spending credit

Use this when you want to lint the SHAPE of a submission (DSL spec,
candles or trades) for free before spending a check, so a typo never
costs you one. A format check only -- it gives no buy/sell advice.
Free payload lint -- fix your submission BEFORE spending a check.

Validates the SHAPE of what you are about to submit, with the same
machine-readable failure vocabulary the paid tools use: DSL schema
validity, OHLCV sanity (finite positive prices, aligned series,
strictly increasing timestamps), per-symbol data presence, trade-row
types, and an honest size warning when the sample is below the paid
gates' evidential floor. Send the same spec/ohlcv_by_symbol/trades you
would send to assay_gauntlet or assay_signal; get back ok plus named
findings (dsl_invalid, timestamps_not_monotonic,
ohlcv_non_finite_or_non_positive, ohlcv_series_misaligned,
symbol_data_missing, trades_rows_invalid, sample_below_engine_floor)
with plain-language details. Shape lint only -- a clean preflight is
NOT evidence of an edge and never blesses a signal; it just means your
paid check will not bounce on format. Code-computed, no ledger write,
no account needed. NOT financial advice. Price: free.

Input parameters:

- `ohlcv_by_symbol`: Candles per symbol to sanity-check (aligned, finite, positive).
- `spec`: DSL strategy to lint for shape/DSL errors before you spend a check.
- `trades`: Trade list to lint instead of a spec.

Output parameters:

- `result` (object)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-alphaassay-mcp/mcp#diagnostics

## Score history

- 2026-08-03: 59
- 2026-08-02: 59
- 2026-08-01: 58
- 2026-07-31: 58
- 2026-07-30: 54
- 2026-07-29: 54
- 2026-07-28: 53
- 2026-07-27: 52
- 2026-07-26: 51

## Links

- Remote endpoint: https://mcp.alphaassay.com/mcp
- Website: https://alphaassay.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-alphaassay-mcp/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-alphaassay-mcp/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-alphaassay-mcp/mcp