Skip to main content
Glama
Sign In

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

by io.github.SKalinin909
OverviewDiscussionsAdmin

Hedge Ratio

primitive.hedge_ratio
Read-only

Calculate the short perpetual futures position size needed to hedge a spot holding. Default USDT-linear: sizes and costs in USD. With contractType "inverse" (coin-margined, needs entryPrice) the short is the same USD contracts and margin and funding come back in the base coin. Edge cases: spotSize above zero (USD value); hedgeRatio 0 to 200 percent (default 100); leverage 1 or more (default 1); fundingRatePct in percent per interval (0.01 is 0.01%, default 0.01); intervalHours 0.25 to 24 (default 8); an inverse contract needs entryPrice. Not covered: basis risk between spot and the perp, rebalancing as prices move, margin calls, and a funding rate that changes. Use when user asks "how much should I short to hedge my BTC?" or "what margin do I need for a 100% hedge?". Returns: perpNotional, requiredMargin, dailyFundingCost, annualFundingCost, hedgeCoverage, contractType and costUnit ("USD", or "base_coin" for inverse: read it before showing margin or funding as dollars). Inverse converts at the one entryPrice you give, so the coin figures assume the price stays there.

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": {
      "spotSize": "<spotSize>"
    },
    "name": "primitive.hedge_ratio"
  }
}

Input Schema

NameRequiredDescriptionDefault
leverageNoLeverage on the perp short. Default 1.
spotSizeYesSpot position value in USDT
entryPriceNoCoin price in USD. Required for contractType inverse (converts the USD margin and funding to coin); ignored for linear.
hedgeRatioNoPercentage of spot to hedge, e.g. 100 for full hedge, 50 for half. Default 100.
contractTypeNolinear = USDT-margined (default). inverse = coin-margined: spotSize stays the USD value of the holding, requiredMargin and the funding costs are returned in the base coin.
intervalHoursNoHours between funding payments, the period fundingRatePct covers. Default 8 (3 payments a day); 1 on Hyperliquid, dYdX, Kraken and Backpack (per-hour rates); 4 or 2 on some symbols of Binance, Bybit, OKX, Gate, KuCoin, MEXC, Aster and Phemex.
fundingRatePctNoCurrent funding rate per funding interval in PERCENT: 0.01 means 0.01%, so a quoted 0.0125% is 0.0125 (per 8h unless intervalHours says otherwise). Used for cost estimate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / fundingRatePct / description
      Previous value: -"Current funding rate per funding interval as a percentage, e.g. 0.01 (per 8h unless intervalHours says otherwise). Used for cost estimate."New value: +"Current funding rate per funding interval in PERCENT: 0.01 means 0.01%, so a quoted 0.0125% is 0.0125 (per 8h unless intervalHours says otherwise). Used for cost estimate."
  2. Changed4 schema fields changed
    • addedInput schema / properties / contractType
      Added value: +{
+  "description": "linear = USDT-margined (default). inverse = coin-margined: spotSize stays the USD value of the holding, requiredMargin and the funding costs are returned in the base coin.",
+  "enum": [
+    "linear",
+    "inverse"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / entryPrice
      Added value: +{
+  "description": "Coin price in USD. Required for contractType inverse (converts the USD margin and funding to coin); ignored for linear.",
+  "type": "number"
+}
    • changedInput schema / properties / fundingRatePct / description
      Previous value: -"Current 8h funding rate as percentage, e.g. 0.01. Used for cost estimate."New value: +"Current funding rate per funding interval as a percentage, e.g. 0.01 (per 8h unless intervalHours says otherwise). Used for cost estimate."
    • addedInput schema / properties / intervalHours
      Added value: +{
+  "description": "Hours between funding payments, the period fundingRatePct covers. Default 8 (3 payments a day); 1 on Hyperliquid, dYdX, Kraken and Backpack (per-hour rates); 4 or 2 on some symbols of Binance, Bybit, OKX, Gate, KuCoin, MEXC, Aster and Phemex.",
+  "maximum": 24,
+  "minimum": 0.25,
+  "type": "number"
+}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare it a safe local read; the description goes well beyond them by disclosing the unit model (USD for linear, base coin for inverse), the inversion assumption ('converts at the one entryPrice you give, so the coin figures assume the price stays there'), and an explicit warning to read costUnit before presenting margin or funding as dollars. This is exactly the kind of interpretive context an agent needs to avoid misreporting results.

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?

Purpose is front-loaded and every clause carries information (edge cases, units, caveats, return fields). The middle edge-case sentence is a dense run-on that an agent must parse carefully, but no sentence is filler.

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, yet the description enumerates the returned fields (perpNotional, requiredMargin, dailyFundingCost, annualFundingCost, hedgeCoverage, contractType, costUnit) and explains how to interpret costUnit. Combined with the unit caveats and stated limitations, an agent can call this correctly and present results without additional context.

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 adds cross-parameter meaning the schema does not, notably that an inverse contract requires entryPrice, that spotSize remains the USD value even in coin-margined mode, and that fundingRatePct is percent per interval rather than per day. Some of the constraint restatement (ranges, defaults) duplicates the schema, keeping it below a 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?

Starts with a specific verb and resource: 'Calculate the short perpetual futures position size needed to hedge a spot holding.' The scope is unambiguous (hedge sizing, not entry pricing or PnL), and the linear/inverse distinction signals it is not one of the generic workflow run_* calculators.

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 concrete trigger phrasings ('how much should I short to hedge my BTC?', 'what margin do I need for a 100% hedge?') and an explicit 'Not covered' list (basis risk, rebalancing, margin calls, variable funding) that tells the agent when to decline or caveat. No sibling tool is named as an alternative for adjacent hedging questions, so it stops short of full routing guidance.

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