Skip to main content
Glama
Sign In

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

by io.github.SKalinin909
OverviewDiscussionsAdmin

Deflated Sharpe Ratio

workflow.run_dsr
Read-only

Deflated Sharpe Ratio (Bailey & Lopez de Prado): given how many strategy variants you tried (and how correlated they are), what Sharpe ratio would the best of N clear by luck alone, and does your actual strategy still clear that higher bar? Edge cases: returns at least 3; give either trial_sharpes (at least 2 values, per period; identical values are an error) or n_trials (a whole number from 2 to 1e9); avg_correlation 0 to below 1 (default 0) works only with n_trials; null_mean works only with trial_sharpes; an effective trial count of 1 or less is an error. Not covered: the real number of trials you ran if you do not state it (the result is only as honest as n_trials), multiple testing across strategies you did not count, and out-of-sample proof. Use when user asks "is my backtested Sharpe ratio real, or did I get lucky trying many variants?" or "how many independent trials does this really represent?". Provide either trial_sharpes[] (the N trials' own observed Sharpe ratios, most rigorous) or n_trials (+ optional avg_correlation to correct for correlated trials via Kish's design effect). Two limits to know. n_trials assumes the paper's illustrative case (trial Sharpes with mean 0 and variance 1, in per-period units), which is a very high bar for a low-frequency series: the threshold is about 1.6 at N=10, 2.5 at N=100 and 3.3 at N=1000, while a daily series has a per-period Sharpe of order 0.05, so dsr comes out effectively 0; use trial_sharpes there. trial_sharpes centers the threshold on the trials' own mean Sharpe plus their dispersion times the expected-maximum factor; this answers "does my strategy beat the best of N trials drawn from the spread I observed", not the zero-skill-null variant; pass null_mean true for that variant (mean fixed at 0, spread still taken from the trials); the two thresholds differ by exactly the trials' mean Sharpe. Returns: expected_max_sharpe (the luck-alone threshold), dsr (probability your strategy's true Sharpe exceeds it, 0-1), n_trials_effective.

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_dsr"
  }
}

Input Schema

NameRequiredDescriptionDefault
returnsYesThe candidate strategy's own return series
n_trialsNoNumber of strategy variants tried, if trial_sharpes were not tracked individually. Assumes trial Sharpes with mean 0 and variance 1 (per-period units): too strict for daily series, prefer trial_sharpes there.
null_meanNoOnly used with trial_sharpes. true = centre the luck threshold on 0 (zero-skill null) instead of on the trials' own mean Sharpe; the spread still comes from the trials. Default false.
trial_sharpesNoObserved Sharpe ratios of all N trials tried, if tracked. Takes priority over n_trials if both are given.
avg_correlationNoAverage pairwise correlation between trials, 0-1 (default 0 = independent). Only used with n_trials; lowers the effective trial count via Kish's design effect.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / null_mean
      Added value: +{
+  "description": "Only used with trial_sharpes. true = centre the luck threshold on 0 (zero-skill null) instead of on the trials' own mean Sharpe; the spread still comes from the trials. Default false.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / n_trials / description
      Previous value: -"Number of strategy variants tried, if trial_sharpes were not tracked individually"New value: +"Number of strategy variants tried, if trial_sharpes were not tracked individually. Assumes trial Sharpes with mean 0 and variance 1 (per-period units): too strict for daily series, prefer trial_sharpes there."
  3. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds genuine behavioral detail beyond that, including error conditions (fewer than 3 returns, identical trial_sharpes, effective trial count <= 1) and the statistical assumptions behind n_trials (mean 0, variance 1) that make results misleading for low-frequency series. However, the description overstates itself somewhat, calling out thresholds like 1.6 at N=10 while the schema already repeats the same caveat for n_trials, so a 3 reflects partial redundancy rather than pure added value.

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?

The content is front-loaded with the core question, but the body is heavy and repetitive: the trial_sharpes-versus-n_trials tradeoff is stated at least three times (edge cases, "Provide either...", and "Two limits to know"), and the n_trials mean-0/variance-1 caveat appears in both the description and the schema. A tighter single pass over the two input modes would preserve all the substance.

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, and the description compensates by naming all three return fields and their meaning (expected_max_sharpe as the luck-alone threshold, dsr as a 0-1 probability, n_trials_effective). For a five-parameter statistical tool with subtle preconditions, nothing an agent needs in order to call it correctly or interpret the result is missing.

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%, so the baseline would be 3, but the description adds real meaning: it states that trial_sharpes takes priority when both are given, that avg_correlation is only valid with n_trials and ranges 0 to below 1, that null_mean only applies with trial_sharpes and shifts the threshold by exactly the trials' mean, and that an effective trial count of 1 or less is an error. These are constraint relationships the schema cannot express.

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 the specific metric (Deflated Sharpe Ratio, Bailey & Lopez de Prado) and frames the exact question it answers: what Sharpe the best of N would clear by luck alone, and whether the strategy still clears it. That multiple-testing framing distinguishes it functionally from workflow.run_sharpe_stats and the other statistical siblings, which report raw statistics rather than a luck-adjusted threshold.

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 user-phrasing triggers ("is my backtested Sharpe ratio real, or did I get lucky trying many variants?") and an explicit "Not covered" list of what the tool cannot tell you. It also routes between the two input modes (trial_sharpes for tracked trials, n_trials with optional avg_correlation when they were not tracked), which is the key usage decision.

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

All TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources