mcp

Run the adversarial signal gauntlet

assay_gauntlet

Destructive

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 Schema

TableJSON Schema

Name	Required	Description
`spec`	Yes	Executable JSON DSL strategy to run the full battery on.
`api_key`	No	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 key in this tool argument without a Bearer prefix. Create an account at https://api.alphaassay.com/account; the current free allowance and prices are published at https://api.alphaassay.com/v1/meta/pricing. Paid MCP calls use API-key credits; x402 buys only the separate REST POST /x402/v1/gauntlet and is not MCP billing.
`request_id`	No	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 idempotency_conflict.
`sketch_opt_out`	No	True to skip the return sketch (data minimisation).
`ohlcv_by_symbol`	Yes	Your candles per symbol for the gauntlet.
`fee_bps_per_side`	No	Round-trip cost in bps/side.
`variants_in_call`	No	Sibling-variant count for family trial accounting.
`adv_by_symbol_usd`	No	Average daily dollar volume per symbol, for the capacity / market-impact stress.
`funding_by_symbol`	No	Per-symbol funding-rate series so the funding-edge stage can net carry out of the edge.
`sigma_by_symbol_pct`	No	Per-symbol volatility (%) input for the risk/capacity cells when you have it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses key behavioral traits beyond annotations: it is code-computed and ledger-dependent, trial counts count fully toward the family budget, and it consumes budget. It explains idempotency guarantees (byte-identical output for same request_id) and that new calls can change the family budget. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with the description's implication that this tool is a paid, destructive check. No contradictions.

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

Conciseness4/5

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

The description is relatively long (~200 words) but front-loaded with the primary purpose. It uses bullet-like lists and clear terminology. Every sentence adds value, though some sections could be more concise (e.g., funding_by_symbol details). The structure is logical, starting with usage, then parameter explanations, then behavioral notes. It is appropriately sized for the complexity of the tool.

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

Completeness5/5

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

Given the tool's complexity (10 parameters, 2 required, nested objects, and an output schema), the description is remarkably complete. It covers when to use, what the output contains (failure_codes, placebo percentile, capacity ceiling), optional parameter usage (funding, sigma, ADV), pricing, idempotency, data minimisation, and budget impact. The presence of an output schema means return values need no additional explanation. No gaps.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds contextual meaning beyond the schema for parameters like api_key (explaining transport differences), request_id (idempotency semantics), funding_by_symbol (how funding erases edge), and sketch_opt_out (data minimisation). It also describes the relationship between parameters like adv_by_symbol_usd and capacity gate. This extra context raises the score above baseline.

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

Purpose5/5

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

The description clearly states the tool runs a comprehensive adversarial battery on a strategy, listing overfitting, leakage, costs, regimes, and a matched-random placebo. It explicitly distinguishes itself as the 'whole reality-check battery' and emphasizes it produces a demote-only dossier, not buy/sell advice. The verb 'run' and resource 'adversarial signal gauntlet' are specific and differentiate it from sibling tools like assay_backtest or assay_falsify.

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

Usage Guidelines5/5

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

The opening sentence explicitly tells when to use this tool: 'when you want the whole reality-check battery on a strategy in one call'. It provides context about what it does and what it returns (failure_codes, placebo percentile, etc.). It also explains optional parameters like funding_by_symbol for perpetuals and sketch_opt_out for data minimization. There is clear guidance on idempotency via request_id, pricing, and that it is demote-only, never buy/sell advice.

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

All mcp tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a distinct, well-defined purpose (e.g., single backtest vs. batch sweep, PBO overfitting detection vs. Romano-Wolf survivor identification). Despite many tools in the same domain, descriptions clearly differentiate them, and no two tools appear to do the same thing.

Naming Consistency5/5

All tools follow a consistent 'assay_<descriptive_noun>' pattern, using snake_case for multi-word descriptors. No mixing of conventions (e.g., camelCase), making tool names predictable and easy to understand.

Tool Count4/5

21 tools cover a broad range of quantitative finance validation tasks, which is appropriate for the server's depth. While slightly above the typical 3-15 range, each tool provides unique value and the count is not excessive given the domain's complexity.

Completeness5/5

The toolset covers the full lifecycle of strategy validation: backtesting, overfitting detection, falsification, pre-registration, verification, and risk model auditing. Free tools (assay_demo, assay_preflight, assay_graveyard) lower barriers. Missing operations are minimal for the stated purpose.

Resources

Need Help?