Skip to main content
Glama

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

VaR and CVaR

workflow.run_var_cvar
Read-only

Parametric Value at Risk (VaR) and Conditional VaR / Expected Shortfall (CVaR), the variance-covariance method (assumes normally distributed returns), plus Modified VaR (Cornish-Fisher skew/kurtosis correction, Boudt/Peterson/Croux) when a return series is supplied. Supply either a return series or a mean/stdev pair directly, at a confidence level. Output is at the same periodicity as the input (no automatic annualization) - a daily return series gives a daily VaR/CVaR. Edge cases: give returns (at least 2 values) or both mean and stdev (stdev zero or more), never neither; confidence strictly between 0 and 1 (default 0.95); Modified VaR needs at least 3 returns; a flat series (zero standard deviation) is an error. Not covered: historical or Monte Carlo VaR, fat tails beyond the Cornish-Fisher correction, portfolio aggregation, scaling to another horizon (the result stays in the period of the input). Use when user asks "what's my VaR at 95%/99%?", "what's my expected shortfall on this position?", or "does my Sharpe/VaR estimate need a fat-tails correction?". Returns: var, cvar (both positive loss magnitudes; cvar >= var always), z, mean, stdev, skewness, excess_kurtosis (both null unless 3+ returns were supplied), var_modified (skew/kurtosis-adjusted VaR; null when skewness is, OR when this series' skew/kurtosis are too extreme for the Cornish-Fisher expansion to be a valid quantile - skewness/excess_kurtosis are still returned in that case).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "workflow.run_var_cvar"
  }
}

Input Schema

NameRequiredDescriptionDefault
meanNoMean return, if not supplying returns[] directly
stdevNoStandard deviation of returns, if not supplying returns[] directly
returnsNoReturn series (e.g. daily % returns as decimals). Provide this OR mean+stdev, not both.
confidenceNoConfidence level, 0-1 exclusive (default 0.95)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/non-destructive/closed-world, and the description adds real behavioral context beyond them: results stay in the input periodicity with no annualization, a flat series is an error, and the conditions under which var_modified returns null. Edge-case handling (min 2 returns, min 3 for Modified VaR, stdev zero-or-more, confidence strictly inside 0-1) is disclosed rather than left to guesswork.

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 the core method and assumption, then inputs, then edge cases, then returns — a sensible order with no filler. It is a dense run-on paragraph, however, and could be broken into shorter segments for scanability.

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 describing the returned fields (var, cvar, z, mean, stdev, skewness, excess_kurtosis, var_modified), their signs and relation (cvar >= var) and the null conditions is essential and is done thoroughly. For a 4-parameter statistics tool the definition leaves nothing an agent needs unanswered.

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; the description earns above that by adding the exclusivity rule (returns[] OR mean+stdev, "never neither"), the min-3-returns threshold for Modified VaR, and the confidence bound. It adds constraint semantics the schema does not encode, though it does not clarify units or what happens if both modes are supplied.

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?

States a specific verb+resource: parametric VaR and CVaR by variance-covariance, plus Modified VaR via Cornish-Fisher. It also names the method assumptions (normal returns) and the alternative input mode, which separates it from siblings like run_evt_tail_risk, run_monte_carlo and run_portfolio_risk.

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 explicit trigger phrases ("what's my VaR at 95%/99%?", "expected shortfall on this position?") and an explicit exclusion list (no historical/Monte Carlo VaR, no fat tails beyond Cornish-Fisher, no portfolio aggregation, no horizon scaling), which routes the agent to the right sibling. When-to-use and when-not-to-use are both present.

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.