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

Monte Carlo Simulation

workflow.run_monte_carlo

Read-only

Monte Carlo simulation of a portfolio: geometric Brownian motion with a contribution (or withdrawal) at the end of every step, up to 10,000 paths (paths x steps at most 5 million), deterministic for a given seed. Returns the spread of final values (percentiles 5 to 95, mean with its standard error and the exact expected value, probability of ending below the net amount invested, probability of ending a step at or below a ruin level) and a fan of 5th, 50th and 95th percentile bands over time, instead of one number. A value that would go below zero is floored at zero. Constant return and volatility, no fees or taxes: a model of spread, not a forecast. Edge cases: initialValue 0 to 1e12 (0 needs a positive contribution); contributionPerStep -1e12 to 1e12 (negative is a withdrawal, paid at the end of each step); annualReturnPct -100 to 500; volatilityPct 0 to 500; years above 0 and at most 50; stepsPerYear a whole number 1 to 365; years times stepsPerYear a whole number of at most 18,250; paths a whole number 100 to 10,000 and paths times steps at most 5,000,000; seed a whole number (default 1, the same seed gives the same result). Not covered: fat tails and volatility clustering (returns are lognormal), taxes, inflation, fees, sequence-of-returns beyond the simulated model, and any forecast. Use when user asks "what range of outcomes can my portfolio end in", "how likely is it that I run out of money withdrawing X a month" or "simulate my savings plan".

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": {
      "initialValue": "<initialValue>",
      "annualReturnPct": "<annualReturnPct>",
      "volatilityPct": "<volatilityPct>",
      "years": "<years>"
    },
    "name": "workflow.run_monte_carlo"
  }
}

Input Schema

Name	Required	Description
`seed`	No	Random seed, 0 to 4294967295; the same input and seed give the same result. Default 1.
`paths`	No	Simulated paths, 100 to 10000 (paths x steps at most 5 million). Default 2000.
`years`	Yes	Horizon in years, above 0 and at most 50. years x stepsPerYear must be a whole number.
`ruinBelow`	No	A path counts as ruined once it ends a step at or below this value. Default 0.
`initialValue`	Yes	Starting value, 0 to 1e12. 0 is allowed only with a positive contribution.
`stepsPerYear`	No	Steps (and contributions) per year, 1 to 365. Default 12.
`volatilityPct`	Yes	Annual volatility sigma in percentage points, 0 to 500.
`annualReturnPct`	Yes	Expected growth mu in percentage points per year, -100 to 500.
`contributionPerStep`	No	Added at the END of every step; negative is a withdrawal. Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.3/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, yet the description still adds real behavioral facts: determinism per seed, the 10,000-path and 5-million paths×steps caps, the zero floor on negative values, and a precise enumeration of what is returned (percentiles 5–95, mean with standard error, exact expected value, ruin probability). It also flags the model as 'a model of spread, not a forecast', which manages over-trust.

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?

Purpose and output shape are correctly front-loaded in the first two sentences, but the middle 'Edge cases' run-on duplicates numeric ranges the schema already enforces and reads as a dense clause stack rather than scannable structure. Roughly a third of the text earns its place only by redundancy with structured fields.

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?

For a 9-parameter simulation tool with no output schema, the description compensates fully: it specifies the stochastic model, contribution timing, ruin semantics, determinism, resource caps, and the full return payload, plus explicit model limitations. An agent has everything needed to decide whether this tool answers the user's question and to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, and most of the description's edge-case listing (initialValue 0–1e12, annualReturnPct -100–500, volatilityPct 0–500, stepsPerYear 1–365, seed default 1) restates bounds already present in the schema. The genuinely additive parts — withdrawal timing at end of step, the ruin definition being 'ends a step at or below' a level — are also largely mirrored in the parameter descriptions, so this sits at the schema-driven baseline.

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?

Opens with a specific verb and resource: 'Monte Carlo simulation of a portfolio' under geometric Brownian motion, and immediately names the output shape (spread of final values plus percentile fan, 'instead of one number'). That distinguishes it from single-point siblings like run_var_cvar, run_future_value or run_portfolio_risk without needing their schemas.

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 three concrete trigger phrasings ('what range of outcomes can my portfolio end in', 'how likely is it that I run out of money withdrawing X a month', 'simulate my savings plan') and an explicit when-not list of what the model does not cover (fat tails, volatility clustering, taxes, inflation, fees, forecasts). It stops short of naming a sibling alternative for overlapping cases such as run_scenario_planning or run_var_cvar.

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.