Skip to main content
Glama

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

Spread Payoff

workflow.run_spread_payoff
Read-only

Payoff, breakeven(s), and max profit/loss for a Deribit BTC/ETH vertical spread (2 legs, same option type, opposite direction, e.g. a bull call spread) or an iron condor/butterfly (4 legs: 2 calls + 2 puts) at a scenario price. Coin-settled, and the max profit/loss are genuinely NOT the flat, textbook USD-settled values: because each leg's own payoff is divided by the settlement price, (1) a debit vertical spread's peak payoff occurs exactly at its short strike, not "anywhere beyond it" - and its profit is a finite WINDOW that closes again at a high enough price, decaying back toward a full loss of the premium paid, and (2) an iron condor/butterfly's max loss is genuinely UNBOUNDED toward price->0 (maxLossCoin: null) if it has a put wing, unlike the "capped at wing width" USD-settled result - only the call side is actually bounded. Use when user asks about a bull/bear call/put spread, vertical spread, iron condor, or iron butterfly, e.g. "what's my max loss on this BTC call spread?" or "where do my iron condor breakevens sit?". Returns: structureType (vertical_spread/iron_condor/iron_butterfly, inferred from the legs given), netDebitCoin (negative = credit received), scenarioPayoffCoin, scenarioPnlCoin/Usd, breakevenPrices (0-3, ascending), maxLossCoin/maxProfitCoin (null = unbounded), isProfitable.

Input Schema

NameRequiredDescriptionDefault
legsYesExactly 2 legs (same option type, opposite position - a vertical spread) or 4 legs (2 calls + 2 puts - an iron condor/butterfly). Each leg: { optionType: call|put, position: long|short, strike: number, premiumCoin: number }.
currencyNoUnderlying coin. Default BTC.
quantityYesNumber of spread/condor units
scenarioPriceYesUnderlying price in USD to evaluate the payoff at

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / legs / items / properties / optionType / description
      Added value: +"Option type: \"call\" or \"put\""
    • addedInput schema / properties / legs / items / properties / position / description
      Added value: +"Option position: \"long\" (bought) or \"short\" (sold)"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint/openWorldHint/destructiveHint), yet the description goes further with genuinely important behavior: coin-settlement effects that make max P&L differ from textbook USD-settled values, the finite profit window of a debit vertical, and unbounded loss (maxLossCoin: null) when a put wing is present. This is exactly the non-obvious behavior an agent would otherwise get wrong.

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 core purpose and ends with a clean structured Returns list, so it is easy to scan. The middle coin-settlement sentence is dense and run-on, but its content is load-bearing rather than 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?

With no output schema, the description fully enumerates the return fields (structureType, netDebitCoin, scenarioPayoffCoin, scenarioPnlCoin/Usd, breakevenPrices, maxLossCoin/maxProfitCoin, isProfitable) and flags null semantics for unbounded values, leaving nothing an agent needs to call or interpret this correctly.

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 interpretation beyond the raw schema: it defines the valid leg combinations (2 same-type opposite-position legs, or 2 calls + 2 puts), states that structureType is inferred from the given legs, and notes netDebitCoin is negative for a credit received.

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?

States a specific verb (compute payoff/breakeven/max P&L) and resource (Deribit BTC/ETH vertical spread or iron condor/butterfly), and explicitly delimits the structure into 2-leg vs 4-leg cases. This distinguishes it from siblings like run_options_payoff, run_straddle_strangle, and run_spread_reader without opening 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?

Clear usage context is given (bull/bear call/put spread, vertical spread, iron condor, iron butterfly) plus concrete triggering queries. However it never names the nearest alternatives or states when NOT to use it, so a 4 rather than a 5.

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.