Skip to main content
Glama

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

Strategy Picker

workflow.run_strategy_picker
Read-only

Ranks option strategies for a price forecast and a volatility view. You give the spot price, the price you expect at expiry, days to expiry and the market implied volatility; optionally your own volatility forecast (default: the market's, so the view is on price only). Every strategy is built from strikes on a grid around spot, each leg priced with Black-Scholes at the one implied volatility (no skew, no dividends), and the best-fitting version of each family is kept: long call, long put, short put (cash-secured), covered call, protective put, long straddle, long strangle, bull call spread, bear call spread, bull put spread, bear put spread, long call butterfly, short iron condor, short iron butterfly; with allowUnlimitedLoss also naked short call, short straddle and short strangle. The view is a lognormal distribution whose mean is targetPrice and whose volatility is forecastVolPct. Per 1 unit of the underlying (multiply by contract size), each strategy returns its legs, net premium, max profit and max loss (null = unlimited), breakevens, expected profit under the view, probability of profit, and return on risk (expected profit / max loss). rankBy: expectedPnl (default), returnOnRisk (favours far out-of-the-money options) or probabilityOfProfit. Not a recommendation: the result is only as good as the forecast, and premiums are not discounted. Prices are computed, nothing is fetched; for equity options with quoted premiums use workflow.run_options_position. Edge cases: spot and targetPrice 1e-9 to 1e9; daysToExpiry above zero and at most 3650; impliedVolPct and forecastVolPct above zero and at most 1000; riskFreeRatePct 0 to 100; strikeStep above zero, and a step that gives fewer than 3 or too many strikes is an error with the step to use. Not covered: skew, dividends, early exercise, bid-ask spread, commissions, margin, taxes, and strategies with different expiries.

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": {
      "spot": "<spot>",
      "targetPrice": "<targetPrice>",
      "daysToExpiry": "<daysToExpiry>",
      "impliedVolPct": "<impliedVolPct>"
    },
    "name": "workflow.run_strategy_picker"
  }
}

Input Schema

NameRequiredDescriptionDefault
spotYesCurrent price of the underlying, from 0.000000001 to 1000000000
rankByNoRanking key. Default expectedPnl.
strikeStepNoStrike spacing. Default: a round step that gives about 16 strikes across the range, plus one past each end. The grid must hold 3 to 60 strikes.
targetPriceYesPrice you expect at expiry (the mean of your view), from 0.000000001 to 1000000000
daysToExpiryYesDays to expiry, above 0 and at most 3650
impliedVolPctYesMarket implied volatility in percent per year (e.g. 30), used to price every option, at most 1000
forecastVolPctNoYour own volatility forecast in percent per year. Default: impliedVolPct (no volatility view).
riskFreeRatePctNoAnnual risk-free rate in percent, 0 to 100. Default 0.
allowUnlimitedLossNoInclude naked short call, short straddle and short strangle. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Prices are computed, nothing is fetched.' It goes well beyond annotations by disclosing the pricing model (Black-Scholes, no skew, no dividends, no early exercise), the lognormal view construction, per-strategy return fields, and an explicit 'not covered' list.

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 purpose, then model, then return semantics, then caveats — a logical order. It is dense and long, particularly the strategy enumeration, but nearly every sentence adds genuine information rather than restating structured fields.

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 carries the return contract itself and does so thoroughly (legs, net premium, max profit/loss with null=unlimited, breakevens, expected profit, probability of profit, return on risk). Edge-case bounds and the 'not covered' list close the remaining gaps for a 9-parameter tool.

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 schema already documents each parameter. The description still adds meaning beyond the schema: rankBy's behavioral effect ('returnOnRisk favours far out-of-the-money options'), the forecastVolPct default semantics, allowUnlimitedLoss unlocking specific families, and the strikeStep error contract.

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 and resource — 'Ranks option strategies for a price forecast and a volatility view' — then enumerates the exact strategy families considered. An agent knows precisely what the tool computes and can distinguish it from pricing or payoff siblings.

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 explicit when-to-use context (forecast-driven ranking) and names the alternative: 'for equity options with quoted premiums use workflow.run_options_position.' It also carries the disclaimer 'Not a recommendation,' steering interpretation appropriately.

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.