Skip to main content
Glama

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

Ladder Max Leg

workflow.run_ladder_max_leg
Read-only

Largest equal leg, in whole contracts, for a scale-in ladder of D legs (linear perpetuals, cross margin). Edge cases: linear perpetuals and cross margin only; legs, step or steps, equity and leverage must describe a real ladder, and an unknown symbol or an unreachable exchange gives available false. Result is capped at 10,000,000 contracts. Not covered: isolated margin, inverse contracts, fees, funding, slippage between legs, and the exchange own liquidation engine; liq_buffer is our model of cross margin. Use when user asks "how many contracts per leg can I put on a ladder of 8 legs at 3x with this equity?". Legs chain from currentPrice: each is step further against the position (a short ladder climbs, a long ladder falls); an existing position (existingCt) is leg 1, the other legs-1 are new; oppositeCt is a hedge on the other side (adds to exposure, its PnL moves with price). equity is the account equity measured at currentPrice. mode "leverage" (default): after every leg, gross contracts x ctSize x price <= leverage x equity at that price (equity includes the loss of every position at that price); liquidation does not take part; fees are not in equity. mode "liq_buffer": the cross-margin liquidation price of the full ladder, from the exchange's live maintenance-margin tiers (exchange and symbol, same tables as workflow.run_liquidation_live), must stay beyond the last leg by at least bufferPct (0.3 for 30%); on OKX pass liqFeeRate (the taker fee rate). Mode liq_buffer does not apply the leverage cap (exposureOverEquityAtLastLeg shows the result) and respects the exchange's largest position (checked at each leg's own price after it fills, not at a later mark); it is our model of cross margin (the opposite side is a fixed oppositeMaintenanceMargin), not the exchange's engine, and the exchange may report no liquidation price for a hedged account. It looks for liquidation in the ladder's adverse direction only: when none exists (noLiquidationInLadderDirection true, for example a larger opposite hedge) the buffer is not a safety statement. Give step (one fraction for every gap) or steps (legs - 1 fractions). Returns: available (false + error when the symbol is unknown or the exchange cannot be reached), maxLegCt (0 when nothing fits, with reason), newLegs, legs [{leg, price, newCt, ladderCt, load}], bindingLeg (leverage), capped (true when the 10,000,000-contract ceiling of the tool was hit), liq_buffer: liqPrice, noLiquidationInLadderDirection, note, limitedBy (buffer, exchange_max_position or ceiling), actualBufferPct, requiredLiqLevel, exposureOverEquityAtLastLeg, tierTable.

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>",
      "currentPrice": "<currentPrice>",
      "equity": "<equity>",
      "legs": "<legs>",
      "ctSize": "<ctSize>"
    },
    "name": "workflow.run_ladder_max_leg"
  }
}

Input Schema

NameRequiredDescriptionDefault
legsYesD: total legs, the existing position counts as leg 1
modeNoWhich definition of "the leg fits"; default leverage
sideYesLadder side
stepNoOne fraction for every gap between legs, 0.01 for 1%
stepsNoOne fraction per gap, legs - 1 values (instead of step)
ctSizeYesBase units per contract, e.g. 0.01 for OKX BTC-USDT-SWAP
equityYesAccount equity in the quote currency at currentPrice
symbolNoliq_buffer: symbol as the exchange writes it
exchangeNoliq_buffer: exchange whose tiers are read
leverageNoLeverage cap on gross exposure / equity. Required for mode leverage; not used by mode liq_buffer
bufferPctNoliq_buffer: required distance of the liquidation price beyond the last leg, a fraction
existingCtNoContracts already held on the ladder side, default 0
liqFeeRateNoliq_buffer, OKX only: forced-liquidation fee rate, a fraction
oppositeCtNoContracts held on the other side, default 0
currentPriceYesPrice of leg 1 (the existing position is valued from here)
oppositeMaintenanceMarginNoliq_buffer: maintenance margin of the other side, default 0

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Well beyond the readOnly/openWorld annotations, it discloses that results are capped at 10,000,000 contracts, that liq_buffer mode does not apply the leverage cap, that liquidation is searched only in the ladder's adverse direction, and that a hedged account may return no liquidation price. It is explicit that liq_buffer is a model of cross margin rather than the exchange's engine, and that fees are excluded from the leverage-mode equity check.

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?

Nearly every claim carries information, but it is delivered as a dense block of long run-on sentences with no line breaks, bullets, or mode-separated sections, making it hard to scan. There is also repetition: the cross-margin model caveat appears twice and the perpetual/cross-margin-only constraint is restated in the not-covered list.

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 16 parameters, no output schema, and live exchange-tier dependencies, the description carries the full burden and discharges it: it enumerates the return fields (available, maxLegCt, bindingLeg, capped, liq_buffer details) and explains failure behavior when the symbol is unknown or the exchange is unreachable. Nothing an agent needs to call it correctly 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 already 100%, but the description adds genuine semantics the schema does not: legs chain from currentPrice with each leg `step` further against the position, existingCt counts as leg 1, oppositeCt adds exposure on the other side, equity is measured at currentPrice, and step vs steps are mutually exclusive forms of the same gaps. These are relational constraints, not restatements of field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names the specific quantity and object: the largest equal leg in whole contracts for a D-leg scale-in ladder on linear perpetuals with cross margin. The sibling set contains adjacent tools (run_position_sizing, run_max_leverage, run_liquidation_safety), and the description never names one to contrast against, so differentiation is inferred from subject matter rather than stated.

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?

It supplies a concrete trigger phrase ("how many contracts per leg can I put on a ladder of 8 legs at 3x with this equity?") and clear scope exclusions (isolated margin, inverse contracts, fees, funding, slippage excluded). It also explains which mode to pick and what each mode means. The gap is that it never routes the agent to an alternative tool for the cases it excludes.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.