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

Pre Trade Check

workflow.run_pre_trade_check

Read-only

Full pre-trade decision card: orchestrates position sizing, breakeven, liquidation, and funding cost in one call. Edge cases: entry_price, leverage above zero; account_balance 0 or more; give desired_size, or stop_loss together with risk_pct, otherwise an error; funding_rate is a decimal per interval (0.0001 is 0.01%) and is read live from the exchange when omitted and exchange (and symbol) are given; hold_hours above zero (default 8); fees 0 to 0.05; mmr 0 to 0.2. Not covered: slippage, tiered margin (use workflow.run_liquidation_live), a funding rate that changes during the hold, and anything about where price will go; the verdict covers setup safety only. Use when user describes a full trade setup and asks "should I take this trade?" or "run the numbers on this setup". Provide exchange+symbol to fetch live funding rate automatically. For an R:R-graded verdict on an entry, stop and target, see workflow.run_risk_reward. Returns: positionSize, breakeven, liquidationPrice, fundingCost, overnightBreakevenShift, verdict. liquidation_price and the liquidation distance are null when the position cannot be liquidated (an inverse short at 1x or less): check for null before using them.

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": {
      "side": "<side>",
      "entry_price": "<entry_price>",
      "stop_loss": "<stop_loss>",
      "account_balance": "<account_balance>",
      "risk_pct": "<risk_pct>",
      "leverage": "<leverage>"
    },
    "name": "workflow.run_pre_trade_check"
  }
}

Input Schema

Name	Required	Description
`mmr`	No	Maintenance margin rate, default 0.005
`side`	Yes	Trade direction: "long" or "short"
`mmBase`	No	Value the maintenance margin is taken on: "liquidation" = position value at the liquidation price (default), "entry" = entry value.
`symbol`	No	Perpetual symbol, e.g. "BTCUSDT".
`exchange`	No	Exchange code, e.g. "binance" or "bybit". Used to fetch the live funding rate if funding_rate is omitted, and to set funding_interval_hours when that is omitted (1 for Hyperliquid, dYdX, Kraken and Backpack, whose rates are per hour; pass funding_interval_hours: 8 if you supply a rate that is per 8 hours). With funding_rate omitted and fetched live, funding_interval_hours is ignored and the interval the exchange reports for the symbol is used.
`leverage`	Yes	Leverage multiplier
`risk_pct`	Yes	Risk as % of balance, e.g. 1.0 = 1%
`stop_loss`	Yes	Stop-loss price (positive)
`hold_hours`	No	Expected hold time in hours for overnight shift calc. Default 8.
`liqFeeRate`	No	Liquidation fee as a fraction of position value, default 0, max 0.05; added to mmr.
`entry_price`	Yes	Entry price (positive)
`contractType`	No	linear = USDT-margined (default), inverse = coin-margined (e.g. Bybit BTCUSD). All returned figures (notional, margin, risk_amount, funding_cost_*) stay USD-denominated either way; recommended_size is USD notional (contracts) for inverse.
`fee_open_pct`	No	Opening fee fraction, default 0.0002
`funding_rate`	No	Funding rate per funding interval as decimal, e.g. 0.0001. If omitted, fetched live from exchange.
`fee_close_pct`	No	Closing fee fraction, default 0.0005
`account_balance`	Yes	Total account balance in USDT
`funding_interval_hours`	No	Hours per funding payment, the period funding_rate covers: 8 on most venues, 1 on Hyperliquid, dYdX, Kraken and Backpack, 4 or 2 on some symbols of Binance, Bybit, OKX, Gate, KuCoin, MEXC, Aster and Phemex. When funding_rate is omitted and fetched live (exchange and symbol given), any value passed here is ignored: the interval of that symbol as the exchange reports it is used (else the exchange default). Omitted otherwise: when you pass funding_rate yourself, the exchange default (1 for hourly venues, else 8), so pass funding_interval_hours for a symbol that pays every 4 or 2 hours.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / liqFeeRate

Added value: +{
+  "description": "Liquidation fee as a fraction of position value, default 0, max 0.05; added to mmr.",
+  "type": "number"
+}

addedInput schema / properties / mmBase

Added value: +{
+  "description": "Value the maintenance margin is taken on: \"liquidation\" = position value at the liquidation price (default), \"entry\" = entry value.",
+  "enum": [
+    "liquidation",
+    "entry"
+  ],
+  "type": "string"
+}

Changed5 schema fields changedOct 24, 2026

changedInput schema / properties / exchange / description

Previous value: -"Exchange code, e.g. \"binance\" or \"bybit\". Used to fetch the live funding rate if funding_rate is omitted, and to set funding_interval_hours when that is omitted (1 for Hyperliquid, dYdX and Kraken, whose rates are per hour; pass funding_interval_hours: 8 if your rate is per 8 hours)."New value: +"Exchange code, e.g. \"binance\" or \"bybit\". Used to fetch the live funding rate if funding_rate is omitted, and to set funding_interval_hours when that is omitted (1 for Hyperliquid, dYdX, Kraken and Backpack, whose rates are per hour; pass funding_interval_hours: 8 if you supply a rate that is per 8 hours). With funding_rate omitted and fetched live, funding_interval_hours is ignored and the interval the exchange reports for the symbol is used."

changedInput schema / properties / funding_interval_hours / description

Previous value: -"Hours per funding payment: 8 or 1 (Hyperliquid, dYdX and Kraken, whose rate is per hour). Omitted: taken from exchange when given, else 8. When funding_rate is also omitted and fetched live, the exchange interval is always used, since the fetched rate is quoted per it."New value: +"Hours per funding payment, the period funding_rate covers: 8 on most venues, 1 on Hyperliquid, dYdX, Kraken and Backpack, 4 or 2 on some symbols of Binance, Bybit, OKX, Gate, KuCoin, MEXC, Aster and Phemex. When funding_rate is omitted and fetched live (exchange and symbol given), any value passed here is ignored: the interval of that symbol as the exchange reports it is used (else the exchange default). Omitted otherwise: when you pass funding_rate yourself, the exchange default (1 for hourly venues, else 8), so pass funding_interval_hours for a symbol that pays every 4 or 2 hours."

removedInput schema / properties / funding_interval_hours / enum
```
Removed value: -[
-  8,
-  1
-]
```
addedInput schema / properties / funding_interval_hours / maximum
```
Added value: +24
```
addedInput schema / properties / funding_interval_hours / minimum
```
Added value: +0.25
```

Changed3 schema fields changedOct 23, 2026

changedInput schema / properties / exchange / description

Previous value: -"Exchange code, e.g. \"binance\" or \"bybit\". Used to fetch live funding rate if funding_rate is omitted."New value: +"Exchange code, e.g. \"binance\" or \"bybit\". Used to fetch the live funding rate if funding_rate is omitted, and to set funding_interval_hours when that is omitted (1 for Hyperliquid, dYdX and Kraken, whose rates are per hour; pass funding_interval_hours: 8 if your rate is per 8 hours)."

addedInput schema / properties / funding_interval_hours

Added value: +{
+  "description": "Hours per funding payment: 8 or 1 (Hyperliquid, dYdX and Kraken, whose rate is per hour). Omitted: taken from exchange when given, else 8. When funding_rate is also omitted and fetched live, the exchange interval is always used, since the fetched rate is quoted per it.",
+  "enum": [
+    8,
+    1
+  ],
+  "type": "number"
+}

changedInput schema / properties / funding_rate / description

Previous value: -"Funding rate per 8h as decimal, e.g. 0.0001. If omitted, fetched live from exchange."New value: +"Funding rate per funding interval as decimal, e.g. 0.0001. If omitted, fetched live from exchange."

Changed1 schema field changedOct 20, 2026
- addedInput schema / properties / side / description
```
Added value: +"Trade direction: \"long\" or \"short\""
```

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / contractType

Added value: +{
+  "description": "linear = USDT-margined (default), inverse = coin-margined (e.g. Bybit BTCUSD). All returned figures (notional, margin, risk_amount, funding_cost_*) stay USD-denominated either way; recommended_size is USD notional (contracts) for inverse.",
+  "enum": [
+    "linear",
+    "inverse"
+  ],
+  "type": "string"
+}

AddedApr 6, 2026

TDQS

A4.5/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, and the description correctly reinforces that this is an analysis-only tool ("the verdict covers setup safety only"). It adds genuinely non-obvious behavior: live funding rate fetched from the exchange when omitted, funding_interval_hours overridden by the exchange-reported interval, and a null-return contract for liquidation_price on non-liquidatable positions. The one blemish is the error clause referencing "desired_size", a parameter that does not exist in the input schema, which muddies the documented failure mode.

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 one-line purpose before the edge-case catalogue, and every clause carries information (constraints, live-fetch behavior, exclusions, return keys, null handling). It is dense rather than padded, though the edge-case sentence is a long run-on that would scan better as a short list for a 17-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter, no-output-schema workflow tool, the description covers the inputs, the live-data dependency, the out-of-scope boundary, the returned keys, and the null case for liquidation values. The only real completeness gap is the incorrect "desired_size" alternative, which an agent could misread as a valid way to satisfy the sizing requirement.

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 3 is the floor; the description goes beyond it by supplying validity constraints the schema omits entirely (entry_price and leverage above zero, account_balance 0 or more, hold_hours above zero with default 8, fees 0 to 0.05, mmr 0 to 0.2) and by clarifying that funding_rate is a per-interval decimal. The mention of an undocumented "desired_size" parameter slightly undercuts the otherwise precise parameter guidance.

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 framing ("Full pre-trade decision card: orchestrates position sizing, breakeven, liquidation, and funding cost in one call") that immediately separates it from the single-purpose siblings like workflow.run_position_sizing, workflow.run_breakeven_planning and workflow.run_funding_cost. It further pins down its identity by naming the alternative for an R:R verdict.

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 an explicit trigger ("Use when user describes a full trade setup and asks 'should I take this trade?'"), an explicit routing rule ("For an R:R-graded verdict on an entry, stop and target, see workflow.run_risk_reward"), an explicit out-of-scope list (slippage, tiered margin -> workflow.run_liquidation_live), and a practical instruction to pass exchange+symbol for live funding. When-to-use, when-not-to-use, and alternatives are all present.

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.