Skip to main content
Glama
simoneb

ibkr-risk-mcp

by simoneb

stress_whatif

Read-onlyIdempotent

Simulate hypothetical options under market stress to compare your portfolio's worst-case P&L with and without the added legs, revealing how the trough moves.

Instructions

The same stress run, with hypothetical legs added — three curves and three troughs: the portfolio as it stands, the portfolio plus the legs, and the difference.

This is what replaces reading Risk Navigator's What-If by hand: "if I add N puts at strike K expiring E, where does the trough move to?"

Read all three troughs. The trough of the difference is not the difference of the troughs — adding protection moves where the worst point sits as well as how deep it is, and comparing only the depths hides the move. A structure that lifts the bottom by very little may still have pushed it from −8% out to −15%, which is the part that matters.

Hypothetical options are priced off IB's current model greeks for those exact contracts, so both curves start from the same volatilities and the difference is the structure alone. A leg that cannot be resolved or priced is reported in legProblems and left out of the second curve; the comparison then covers only the legs that did resolve, and says so.

With breakdown='expiry' all three curves are broken out by settlement date, and the difference curve's pnl_by_expiry is where the structure actually landed: the expiry you traded against moves and the ones you did not read zero, which is how a hedge is told apart from a change of subject. A short expiry whose row goes to roughly nothing in withLegs is one the structure has closed out.

Nothing is sent to IB's order path here — this is pure local repricing. For what the structure costs in margin, use whatif_order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
legsYesHypothetical legs to add. Each is either a conid, or symbol+secType+expiry+strike+right, with action BUY/SELL and a quantity.
betasNo
scopeNoequity
shocksYesUnderlying moves as fractions, as above.
vol_bumpNo
vol_modeNosticky_strike
breakdownNoWhich per-point P&L breakdowns to return. 'symbol' — the default and what this server has always returned — groups by root, which on an options book collapses every ES expiry under one 'ES' key. 'expiry' groups by the option's SETTLEMENT date instead ('ES 2026-10-30'), which is the breakdown that answers 'which expiry is holding the trough down, and which short do I buy back'. 'both' returns the two of them and 'none' neither. Positions with no expiry get a key naming their class ('ES (future)', 'AAPL (equity)') so the breakdown still sums to the point's total and can be checked against it. Responses are large: a book on nine expiries pays for the second dictionary at every one of twenty-six shocks, so ask for 'both' only when you want both, and 'none' when you only want the curve.symbol
fetch_skewNo
risk_groupsNo
default_betaNo
vol_slope_upNo
valuation_dateNoValue the curve at this ISO date, e.g. '2026-09-30', instead of counting the days out by hand into date_offset_days. Mutually exclusive with it. No calendar magic: the date is the date, weekend or not, and time to expiry is ACT/365 throughout. The P&L is still measured FROM today at today's prices and volatilities, with the clock rolled forward — it is decay, not a forecast.
vol_slope_downNo
date_offset_daysNo
bond_rate_shift_bpNo
bond_duration_yearsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark the operation read-only and idempotent, and the description adds substantial behavioral context: it is pure local repricing with no IB order-path interaction, hypotheticals are priced off current IB model greeks, unresolved legs surface in legProblems and are excluded, and the trough-of-difference caveat is explicitly warned about. It also clarifies how breakdown='expiry' changes what the curves mean.

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?

The description is front-loaded with the core output, then proceeds through caveats, pricing behavior, breakdown semantics, and safety in a logical order. It is long but dense with useful information; a few sentences could be tightened, but none feel like padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter tool, the description plus the existing output schema and annotations gives an agent enough to understand the primary use case, the required legs and shocks inputs, breakdown behavior, failure reporting, and the safety profile. Advanced parameters remain under-specified, but they have defaults and are not essential to the core scenario the description targets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25%, so the description must compensate. It does meaningfully explain legs and breakdown behavior, including unresolved-leg exclusion and pnl_by_expiry interpretation. However, it leaves many parameters such as betas, scope, vol_mode, vol_bump, fetch_skew, risk_groups, and the bond/rate/date parameters effectively unexplained, so the compensation is only partial.

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 states a specific operation: take the same stress run, add hypothetical legs, and return three curves/troughs (base portfolio, portfolio plus legs, and the difference). It clearly distinguishes this from whatif_order, which is explicitly called out for margin-cost questions.

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 frames the intended use case directly: answering What-If questions like 'if I add N puts at strike K expiring E, where does the trough move to?' It also gives an explicit exclusion, directing margin-cost needs to whatif_order and noting that no orders are sent. It does not enumerate every sibling, but the key alternative is named.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/simoneb/ibkr-risk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server