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

Sharpe Ratio Statistics

workflow.run_sharpe_stats

Read-only

Sharpe ratio with the Lo (2002) serial-correlation-aware annualization correction, computed in its lag-1 form rather than the full multi-lag sum (the naive sqrt(periods_per_year) scaling overstates or understates the true annualized Sharpe when returns are autocorrelated), plus the Probabilistic Sharpe Ratio (Bailey & Lopez de Prado): the probability the true Sharpe exceeds a benchmark, adjusted for the sample's skewness/kurtosis and length, not just its point estimate. Edge cases: at least 3 returns; periods_per_year from 1 to 100,000,000 (default 365, the crypto convention); benchmark_sharpe is per period, not annualized (default 0); a flat series (zero standard deviation) is an error. Not covered: the multi-lag Lo correction beyond lag 1, a risk-free rate series (the benchmark is one number), transaction costs, and any statement about future Sharpe. The result describes the sample you give. Use when user asks "what's my real annualized Sharpe, not the naive one?" or "how confident can I be this Sharpe ratio is actually good?". Returns: sharpe_period, sharpe_annualized_naive, sharpe_annualized_lo, autocorrelation_lag1, psr, skewness, kurtosis.

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

Input Schema

Name	Required	Description
`returns`	Yes	Return series, one value per period
`benchmark_sharpe`	No	Benchmark Sharpe ratio for the PSR test, same periodicity as returns (default 0)
`periods_per_year`	No	Periods per year for annualization (default 365, crypto convention - trades every day). Any number from 1 to 100 million, e.g. 365.25.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 23, 2026

changedInput schema / properties / periods_per_year / description

Previous value: -"Periods per year for annualization (default 365, crypto convention - trades every day)"New value: +"Periods per year for annualization (default 365, crypto convention - trades every day). Any number from 1 to 100 million, e.g. 365.25."

addedInput schema / properties / periods_per_year / maximum
```
Added value: +100000000
```
addedInput schema / properties / periods_per_year / minimum
```
Added value: +1
```

AddedSep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/no-destructive/closed-world, and the description goes well beyond them: minimum sample size of 3, the periods_per_year bounds and crypto default, the fact that benchmark_sharpe is per-period not annualized, and that a zero-variance series is an error. It also enumerates the returned fields and warns that results describe only the supplied sample.

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 core purpose is front-loaded, but the opening sentence is a long run-on with nested parentheticals that is hard to parse on first read. Nearly every clause is substantive, yet it could be restructured into shorter sentences or bullets for faster scanning.

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?

With no output schema, the description compensates by listing all seven return fields, the input constraints, the error case, and an explicit scope boundary. Nothing an agent needs 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.

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 weight to the most error-prone parameter, stressing that benchmark_sharpe is per period rather than annualized and that a flat series is rejected. Most other parameter detail (range, default, periodicity) duplicates the schema, so it is not a full 5.

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 computation: Sharpe ratio with the Lag-1 Lo (2002) correction plus Probabilistic Sharpe Ratio, and states exactly which variant is produced. An agent can distinguish it from siblings like run_dsr, run_garch, or run_portfolio_tearsheet without opening any schema.

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

Usage Guidelines4/5

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

Gives explicit trigger phrases ('what's my real annualized Sharpe, not the naive one?', 'how confident can I be this Sharpe ratio is actually good?') and a 'Not covered' list that rules out multi-lag Lo, risk-free rate series, transaction costs, and forecasting. It stops short of naming a sibling tool to use instead for those excluded cases, which keeps it from a 5.

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 tools Inspect

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.