com.alphaassay/mcp
REMOTE · MCP.ALPHAASSAY.COM · SCANNED AUG 3
Fail-closed backtest/signal validation: overfitting, leakage, deflated Sharpe. NOT financial advice.
Available components
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. How we score →
Endpoint Security66
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (assay_signal). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability20
- AI-judged instruction clarity (poor).Fail
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · mcp.alphaassay.com
claude mcp add --transport http com-alphaassay-mcp https://mcp.alphaassay.com/mcp
[mcp_servers.com-alphaassay-mcp] url = "https://mcp.alphaassay.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-alphaassay-mcp": {
"type": "remote",
"url": "https://mcp.alphaassay.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-alphaassay-mcp --url https://mcp.alphaassay.com/mcp --transport streamable-http
mcp_servers:
com-alphaassay-mcp:
url: "https://mcp.alphaassay.com/mcp" {
"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.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Aug 26 +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.
- 31 Jul 26 +4
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 29 Jul 26 +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.
- 28 Jul 26 +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.
- 27 Jul 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 51
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://mcp.alphaassay.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.alphaassay.com | CN=YE2,O=Let's Encrypt,C=US | 6 Jul 2026 | 4 Oct 2026 | ECDSA 256 | ECDSA-SHA384 | 59a35b13ce88d4059cfb46aa83a6e7cbda5 |
| SANs: mcp.alphaassay.com | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
DNSSEC secure
Validation of mcp.alphaassay.com. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| alphaassay.com. | present | 64146 | 13 | Verified |
| mcp.alphaassay.com. | Verified address RRset verified with the apex keys |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| content-security-policy | default-src 'none'; frame-ancestors 'none' |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | geolocation=(), camera=(), microphone=() |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.alphaassay.com/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.alphaassay.com/mcp | HTTPS enforced | 308 | https://mcp.alphaassay.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
assay_backtest Run a family-deflated backtest assay ~669
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 | — | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_batch Assay a parameter sweep as one batch ~691
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_calibration Read the validator calibration snapshot ~173
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_certificate_verify Verify an AlphaAssay certificate against platform trust ~215
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.
| Name | Type | Req | Description |
|---|---|---|---|
| certificate | object | yes | The separately issued signed certificate/document object to verify against current platform trust. |
| public_key_pem | string | yes | Caller-supplied signer-key evidence in PEM form; it is not a platform trust root. |
| signature_b64 | string | yes | Its base64 Ed25519 signature. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_conformal Audit conformal interval coverage ~675
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Lower bounds of your prediction intervals, per point. |
| intervals_upper | array | yes | Upper bounds of your prediction intervals, per point. |
| outcomes | array | yes | 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_cpcv Run combinatorial purged cross-validation ~658
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_demo Inspect a sample AlphaAssay verdict ~196
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | All three documented demo responses under one closed public contract. |
No examples provided.
assay_falsify Falsify a strategy against synthetic nulls ~500
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 | — | yes | Executable JSON DSL strategy to attack with the survival map. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_forensics Diagnose signal timing leakage ~467
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 | yes | Signal decisions with the schema-accepted fields {decision_time, symbol, direction, confidence?} to test for timing leakage. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_gauntlet Run the adversarial signal gauntlet ~784
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 | — | yes | Executable JSON DSL strategy to run the full battery on. |
| variants_in_call | integer | — | Sibling-variant count for family trial accounting. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_graveyard Inspect anonymised strategy-family mortality ~235
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_pbo Measure probability of backtest overfitting ~654
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | T x N matrix: per-period returns for each of your N grid/sweep configurations -- the raw material for probability-of-backtest-overfitting (CSCV). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_preflight Lint an assay payload before spending credit ~339
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_provider_protocol Read the signal-provider falsification protocol ~287
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_register Pre-register a sealed strategy hypothesis ~704
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | — | yes | 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_reproduce Reproduce a claimed track record ~729
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_signal Validate a trading signal or track record ~909
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_survivors Run a stepwise survivor reality check ~637
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_tradelog Audit a trade log for contradictions ~584
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_var_es Backtest VaR and expected shortfall forecasts ~929
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…
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Realised per-period returns (the outcomes your risk model was forecasting for). |
| var_forecasts | array | yes | Your model's ex-ante VaR forecasts (positive loss thresholds at level alpha) to backtest for breaches. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.
assay_verdict Evaluate a matured pre-registration ~497
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Post-registration candles per symbol to evaluate the sealed strategy on. |
| prereg_id | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | object | yes | — |
No examples provided.