Skip to main content
Glama

Backtest VaR and expected shortfall forecasts

assay_var_es
Destructive

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 answers insufficient_evidence instead of a hollow pass). Works for any asset class. 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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
alphaNoTail level, e.g. 0.05 for a 95% VaR (0.001-0.25). Sets the Basel traffic-light expectation.
api_keyNoAPI 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.
returnsYesRealised per-period returns (the outcomes your risk model was forecasting for).
request_idNoOptional 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.
es_forecastsNoOptional matching expected-shortfall forecasts; enables the joint (VaR, ES) e-process tail test.
var_forecastsYesYour model's ex-ante VaR forecasts (positive loss thresholds at level alpha) to backtest for breaches.
benchmark_es_forecastsNoOptional benchmark ES forecasts; switches the EPA test to the joint FZ0 loss.
benchmark_var_forecastsNoOptional 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations (destructiveHint=true), the description details that the tool is paid, charges per check, requires an API key, and fails closed on malformed input. It also explains the demote-only philosophy and what outputs to expect (traffic-light zones, flags, advisories). This provides rich behavioral context beyond what annotations convey.

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

Conciseness3/5

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

While the description is front-loaded with the main purpose, it is quite lengthy (multiple paragraphs) and includes detailed explanations of statistical tests and pricing. Some redundancy (e.g., repeating 'not financial advice') could be trimmed. It would benefit from a more structured or abbreviated form focusing on key points.

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 (8 parameters, conditional requirements, output schema present), the description covers purpose, input semantics, validation rules, pricing, error handling, and output flags. It even explains the Basel zones and specific flags (VAR_BREACH_RATE_EXCESS, ES_TAIL_UNDERSTATED, etc.). The presence of an output schema relieves the need to describe return values, and the description provides all necessary context for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, and the description adds substantial meaning by explaining the roles of each parameter (e.g., returns as outcomes, var_forecasts as ex-ante thresholds, benchmark forecasts for comparison). It also clarifies conditional requirements (e.g., if benchmark_es_forecasts supplied, then es_forecasts and benchmark_var_forecasts required) and provides examples of tail levels (0.05 for 95% VaR).

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 states the specific verb 'backtest' and resource 'VaR and expected shortfall forecasts'. It clearly distinguishes from siblings by emphasizing it is a risk-forecast audit, not buy/sell advice, and mentions the types of claims produced (risk numbers vs. return claims).

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 description explicitly opens with 'Use this when you have VaR or Expected-Shortfall forecasts and need to know whether reality breached them...' and clarifies it is not buy/sell advice. It also explains when to supply benchmark forecasts for equal predictive ability testing and warns about insufficient data. Though it does not name specific sibling tools, the context is sufficient for appropriate selection.

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

Try in Browser

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