Skip to main content
Glama

TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures

EVT Tail Risk

workflow.run_evt_tail_risk
Read-only

Extreme Value Theory tail risk (Peaks-Over-Threshold): fits a Generalized Pareto Distribution to the losses beyond a high threshold via Grimshaw's (1993) profile-likelihood MLE, then extrapolates VaR/Expected Shortfall at the requested confidence, without assuming a normal distribution. Edge cases: at least 100 finite returns; threshold_percentile strictly between 0 and 100 (default 90); confidence strictly between 0 and 1 (default 0.99); at least 10 returns beyond the threshold, otherwise an error; if the tail fit does not converge, the call is an error suggesting another threshold. Not covered: a tail model for gains, time-varying volatility, the choice of the best threshold (try several), and the risk beyond what the sample has seen. Use when user asks "what's my tail VaR without assuming normality?" or "how fat is my loss tail, really?". Complements workflow.run_var_cvar (parametric, normal-distribution VaR/CVaR) for exactly the fat-tailed-return case that assumption understates. threshold_percentile (default 90) sets which percentile of the loss distribution (losses = -returns) becomes the threshold u; confidence must be deep enough into the fitted tail (1-confidence < the threshold's own exceedance rate) or the call throws. Returns: threshold, n_exceedances, exceedance_rate, xi (GPD shape: 0=exponential tail, >0=heavy/fat tail, <0=bounded tail; values <= -1 are excluded from the fit domain as a known non-regular/unbounded-likelihood case, Smith 1985), beta (GPD scale), xi_asymptotically_normal (false when xi<=-0.5: the fit is still valid but the usual MLE confidence-interval theory doesn't apply, per that same Smith 1985 result), var, es (null when xi>=1, where Expected Shortfall is mathematically undefined).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "returns": "<returns>"
    },
    "name": "workflow.run_evt_tail_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
returnsYesReturn series, one value per period, at least 100 values (POT needs real sample depth in the tail)
confidenceNoVaR/ES confidence level, 0-1 exclusive. Default 0.99. Must satisfy 1-confidence < the threshold's own exceedance rate.
threshold_percentileNoPercentile (0-100 exclusive) of the loss distribution used as the POT threshold u. Default 90.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond them: minimum sample sizes, the requirement of at least 10 exceedances, the 1-confidence < exceedance-rate constraint, and the explicit error paths on non-convergence with a suggestion to change the threshold. It also explains null/degenerate output conditions (es null when xi>=1, xi<=-1 excluded from the fit domain).

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

Conciseness4/5

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

Front-loaded with what the tool does, then constraints, then exclusions, then returned fields — a sensible order for a dense statistical tool. It is long, and a few facts (the 100-return minimum, the confidence/threshold relationship) repeat what the input schema already states, but almost every clause carries real information.

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?

There is no output schema, so the description carries the return contract itself, and it does: threshold, n_exceedances, exceedance_rate, xi with its interpretation and Smith (1985) caveats, beta, xi_asymptotically_normal, var, and es with its null condition. Combined with the stated error cases, an agent has enough to call and interpret this correctly.

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 the baseline is 3, but the description adds interpretive meaning: losses are -returns and the threshold is set on the loss distribution, and confidence must be deeper into the tail than the threshold's own exceedance rate. The constraint linking confidence and threshold_percentile is genuinely extra semantics not fully spelled out by the schema.

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

Purpose5/5

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

Names a specific method and output: 'Extreme Value Theory tail risk (Peaks-Over-Threshold)' fitting a GPD via Grimshaw's profile-likelihood MLE, then extrapolating VaR/Expected Shortfall. It also explicitly separates itself from the sibling 'workflow.run_var_cvar (parametric, normal-distribution VaR/CVaR)', so an agent can pick the right one without opening either schema.

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?

Gives verbatim trigger phrasing ('what's my tail VaR without assuming normality?'), an explicit alternative and the condition that selects it (fat-tailed returns that the normal assumption understates), and a 'Not covered' list including the recommendation to try several thresholds. When-not guidance is present rather than implied.

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.