Skip to main content
Glama
simoneb

ibkr-risk-mcp

by simoneb

stress_whatif

Read-onlyIdempotent

Run what-if stress scenarios with added option legs, revealing how the portfolio's worst P&L point moves. Compares baseline, protected, and difference curves.

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.

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
shocksYesUnderlying moves as fractions, as above.
vol_bumpNo
vol_modeNosticky_strike
fetch_skewNo
default_betaNo
date_offset_daysNo
bond_rate_shift_bpNo
bond_duration_yearsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it explains that hypothetical options are priced off IB's current model greeks, that unresolved legs are reported in legProblems and excluded, that the comparison has a subtle 'trough of the difference' caveat, and that 'nothing is sent to IB's order path' — pure local repricing. This far exceeds the read-only/idempotent hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and each paragraph earns its place: the trough-reading caveat, the pricing-model transparency, unresolved-leg behavior, and the safety/margin distinction all add value. It is longer than a single sentence but contains no filler or redundant restatements of the schema.

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?

The description thoroughly covers output semantics (three troughs, legProblems), safety (local repricing), and the main comparison caveat, and an output schema is available. However, with 10 parameters and low schema coverage, several optional parameters remain unexplained, making the description incomplete for deeper parameter-level use.

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

Parameters2/5

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

With only 20% schema description coverage, the description needed to explain the many optional parameters, but it does not. It gives a high-level example for legs and mentions legProblems for unresolved legs, yet parameters like betas, vol_bump, vol_mode, fetch_skew, default_beta, date_offset_days, bond_rate_shift_bp, and bond_duration_years receive no added meaning beyond their names/defaults.

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 immediately states the tool's specific function: 'The same stress run, with hypothetical legs added — three curves and three troughs...' and frames it as replacing manual Risk Navigator What-If reading. It clearly distinguishes the tool from siblings by contrasting with whatif_order for margin cost and by implying a stress-only comparison use case.

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?

The description gives clear usage context and a concrete example ('if I add N puts at strike K expiring E'), and explicitly points to an alternative: 'For what the structure costs in margin, use whatif_order.' It does not explicitly state when to prefer stress_portfolio over this tool, so it stops short of a 5.

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

Install Server

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