Skip to main content
Glama
Sign In

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

by io.github.SKalinin909
OverviewDiscussionsAdmin

Max Pain

workflow.run_max_pain
Read-only

Max pain of an option expiry: the settlement price at which holders of all calls and puts together would be paid the least, from the open interest per strike (1 contract = 1 unit of the underlying). Two modes. LIVE (omit strikes): reads one expiry's open interest from Deribit (BTC, ETH; coin-settled, payouts shown in USD), Binance (BTC, ETH, XAU, XAG; USDT) or Bybit (BTC, ETH; USDT); one venue per result, venues are never merged; omit expiry to get the nearest expiry that has open interest. An expiry with no open interest yet, or where the venue leaves a contract's open interest unstated, comes back with available false and the reason, never a number. YOUR OWN DATA (pass strikes): max pain from the open interest you supply, nothing is fetched; optional spotPrice adds how far max pain sits from it. Returns maxPainStrike (the lowest if several tie; tiedStrikes lists all), the minimum and maximum total payout, total call and put open interest, the put/call open-interest ratio, and the payout at every strike (callPayoutUsd, putPayoutUsd, totalPayoutUsd). Max pain is a descriptive statistic of open positions, not a forecast of the settlement price; who holds which side, early exercise and the venue's settlement-price method are not modelled. Edge cases: your own data takes strikes (strike above zero, open interest 0 or more, finite) and an optional spotPrice, never together with exchange, underlying or expiry; ties go to the lowest strike and all tied strikes are listed. Not covered: who holds which side, hedging, early exercise and the venue settlement-price method. Use when the user asks for the max pain strike of BTC or ETH options for an expiry, or for max pain from open interest they have.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "workflow.run_max_pain"
  }
}

Input Schema

NameRequiredDescriptionDefault
expiryNoLive mode: expiry as YYMMDD, e.g. 261225. Omit for the nearest expiry that has open interest. Not with strikes.
strikesNoYour own data: one row per strike, { strike: number > 0, callOpenInterest: number >= 0, putOpenInterest: number >= 0 }. A strike is listed once; at least one open interest must be above 0.
exchangeNoLive mode: venue to read. Default deribit. Not with strikes.
spotPriceNoYour own data: optional price today, adds the distance from max pain to it
underlyingNoLive mode: Deribit BTC or ETH; Binance BTC, ETH, XAU or XAG; Bybit BTC or ETH. Default BTC. Not with strikes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive; the description goes far beyond that by naming the venues read, stating that only one venue is used per result and venues are never merged, and disclosing that a missing open interest yields available=false with a reason rather than a fabricated number. It also disclaims modelling limits (side-holders, hedging, early exercise, venue settlement method) and the tie-breaking rule, which are exactly the behavioural details an agent needs to interpret output honestly.

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?

The opening definition and the LIVE/YOUR OWN DATA split are well front-loaded and the output-field list is efficient. However, the exclusion list is stated twice — 'who holds which side, early exercise and the venue's settlement-price method are not modelled' and then again as 'Not covered: who holds which side, hedging, early exercise and the venue settlement-price method' — a full duplicated clause that wastes space in an already dense description.

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, so the description must describe returns, and it does: maxPainStrike, tiedStrikes, min/max total payout, total call and put open interest, put/call ratio, and per-strike callPayoutUsd/putPayoutUsd/totalPayoutUsd. Combined with the mode rules, error behaviour (available=false plus reason), and stated modelling limits, nothing an agent needs to call and interpret this tool is missing.

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 description coverage is 100%, so the schema already carries baseline semantics; the description still adds meaning the schema does not, namely that omitting expiry returns the nearest expiry with open interest, that spotPrice reports distance from max pain, and that ties resolve to the lowest strike with tiedStrikes listing all. It does not add much on individual validated fields (strike > 0, OI >= 0) beyond the schema.

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?

The description opens with a precise definition of the computed quantity ('the settlement price at which holders of all calls and puts together would be paid the least, from the open interest per strike') and then states the exact resource scope for both modes. An agent can distinguish this from generic options tools like run_options_payoff or run_option_greeks because the input domain is explicitly open-interest-per-strike, not positions or volatilities.

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 states explicitly when to use it ('the user asks for the max pain strike of BTC or ETH options for an expiry, or for max pain from open interest they have') and gives a crisp mode-selection rule: omit strikes for LIVE, pass strikes for YOUR OWN DATA, and never mix them with exchange/underlying/expiry. No sibling tool is named as an alternative, but the mode branches cover the main routing decision an agent faces.

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