ibkr-risk-mcp

by simoneb

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation4/5
The three stress_* tools and two what-if tools live in the same conceptual neighborhood, so an agent must read carefully to pick between stress_portfolio, stress_curve, stress_whatif, and whatif_order. That said, each has a clearly distinct purpose—underlying-shock P&L, multi-volatility curves, hypothetical-leg P&L, and IB margin impact—and the descriptions draw those boundaries well.
Naming Consistency4/5
snake_case verb_noun names are the dominant pattern (check_connection, get_margin_summary, stress_portfolio, calibrate_vol_coord), but whatif_order breaks the verb convention and the stress_/get_/whatif_ prefixes are not uniformly aligned. Still, the names are predictable enough to group and search.
Tool Count5/5
Nine tools cover the server's stated risk-analysis scope without redundancy: connection health, margin, greeks, vol surface, stress curves, what-if, and calibration. Each tool occupies a distinct function and none feel like filler.
Completeness4/5
The risk workflow is well covered: users can check connectivity, inspect margin and greeks, fetch vol surfaces, stress the book, add hypothetical legs, and estimate margin impact. Minor gaps remain—there is no direct non-option position listing and no way to stress an individual underlying without running the whole portfolio—but these are workarounds rather than dead ends.
Average 4.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavior beyond these: undPrice is the forward IB used, multiplier is from the contract, settlementDate is the actual expiry, and missing greeks are listed rather than dropped. It also hints at data subscription requirements, providing rich behavioral context.
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 lengthy but structured and front-loaded with the core purpose, followed by a return field list and a bulleted list of key nuances. Every sentence carries substantive information, and the bullet format improves readability without padding.
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?
For a tool with an output schema and one well-documented optional parameter, the description is complete. It explains critical interpretation details (forward vs spot, multiplier scaling, settlement date vs last trade date, and missing-row behavior) that are not derivable from the schema alone. It fully covers the tool's context.
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?
The schema has 100% description coverage for its single optional parameter ('symbol'), with a clear description. The tool description adds no additional parameter-specific meaning, so the baseline of 3 applies because the schema already handles parameter semantics adequately.
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 specific verb and resource: 'IB's model greeks for every option position.' It clearly distinguishes the tool from siblings, such as get_vol_surface, by noting these are 'its numbers, not ones implied locally.' This makes the tool's purpose unambiguous.
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 provides clear context for when to use this tool—when broker model greeks are needed, not local implied ones—and explains caveats like settlement date and missing greeks. However, it does not explicitly mention sibling alternatives or state when not to use the tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description goes far beyond that, disclosing model internals: Black-76 repricing, flat volatility assumptions, how troughRefined interpolates, how reconciled is computed, what happens to excluded and unmodeled positions, and the modelVsMarket gap. This is exemplary transparency for a complex analytical tool.
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 long but front-loaded with the core purpose and primary output, then organized into clear behavioral bullets. Each sentence carries meaningful caveats, though some points (e.g., beta semantics, scope semantics) restate or extend schema text, adding a bit of redundancy. Still, it is dense and purposeful rather than padded.
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?
Given the tool's complexity — 15 parameters, multiple model assumptions, a reconciliation check, and a detailed output shape — the description is remarkably complete. It explains not only what is returned but how to interpret troughRefined, reconciled, excluded, warnings, pnl_by_expiry, and modelVsMarket. It also warns about known limitations relative to Risk Navigator, which an agent needs before quoting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already high at 93%, so the baseline is 3. The description adds substantial meaning on top: betas scale the shock per symbol and remove positions at zero; scope='equity' matches Risk Navigator's Equity tab; vol_slope_down is a user input, not a measurement; breakdown='expiry' returns each expiry's trough contribution. Nearly every parameter gains operational context beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Reprice the whole portfolio — options, equities, futures — across underlying shocks and return the P&L curve and its trough.' This clearly distinguishes the tool's scope. However, it does not explicitly contrast itself with sibling tools like stress_curve or stress_whatif, so it stops short of full sibling differentiation.
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 strong situational guidance: when to use equity scope, when betas are appropriate, when to set vol_slope_down, when breakdown='expiry' answers a different question, and when to trust the trough only if reconciled. It stops short of explicitly saying 'use this instead of stress_curve when...' or naming excluded conditions, so no direct alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses crucial behavioral traits: orders are never routed, never acknowledged as live, never appear in the order book, and return blocked when the gate is closed. It also surfaces a reliability caveat about multi-leg combos sometimes returning nothing, plus the Read-Only API failure mode — rich transparency beyond structured 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 longer than average, but every section earns its place: purpose, safety, return fields, view breakdown, interpretation warning, and troubleshooting. Bolded key takeaways and a clean bullet list make it scannable without padding.
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?
For a tool with complex margin semantics, the description explains return values (initMargin, maintMargin, equityWithLoan, commission, warningText), two output views, SPAN offset behavior, failure modes, and environment prerequisites. The output schema exists, but the description goes beyond it to give operational context, making it highly complete.
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?
The schema provides full description coverage: legs are explained as conid or descriptive fields with action and quantity. The tool description adds interpretive guidance ('Read the combined figure, not the sum of the legs') but does not meaningfully expand parameter semantics beyond the excellent schema documentation, so the baseline 3 applies.
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 a specific purpose: 'IB's own margin impact for a hypothetical structure.' It adds a strong differentiator with '**Nothing reaches the market.**' and explains that each order carries whatIf=True, clearly distinguishing it from live-order or simple read-only siblings.
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 implies when to use this tool — for hypothetical structures needing margin impact without market exposure — and includes practical caveats like the IBKR_ENABLE_WHATIF gate and the TWS Read-Only API check. It does not explicitly name an alternative tool or state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read nature is covered. The description adds valuable behavioral context beyond annotations: IB may sweep cash from securities to commodities, and a healthy total excess liquidity can still mask a segment-level shortfall. This teaches the agent how to interpret the returned numbers rather than just their type.
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 somewhat long but each sentence earns its place: a crisp opening, a field list, and a bolded explanation of why segments matter. The formatting is clean with a lead sentence, an em-dash separated detail, and a clear call to action.
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 zero parameters, an output schema present, and annotations covering safety, the description goes beyond the minimum by explaining the key subtlety of segment-level margin and how to act on it. The tool is fully contextualized for the agent, including a warning scenario and a reporting directive.
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?
The tool has zero parameters, so the input schema carries no burden; the baseline is 4. The description does not need to clarify parameters and instead focuses on explaining the output's segment semantics, which is appropriate.
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 'Margin and liquidity, split by segment,' which clearly names the resource (margin and liquidity) and the specific scope (segment breakdown). It then enumerates the exact fields returned, distinguishing this tool from siblings like stress_portfolio or get_position_greeks.
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?
The description explicitly tells the agent when to emphasize segment figures: 'Report the segment figures, not only the totals, whenever futures are involved.' It also explains why segments matter by describing the commodities-segment shortfall and forced-liquidation risk, giving the agent actionable context for choosing how to use the results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the critical side effect: unless persist=false, the fit is written to disk and becomes the standing calibration, and it names this as 'the only thing this server writes.' It also explains the asymmetric failure behavior around unreconciled portfolios and notes that nothing trades or quotes. This goes well beyond the structured annotations and adds genuinely important operational context.
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 long but earns its length: it front-loads the core purpose, uses bold to mark the most important caveats, and organizes content into workflow, persistence, and failure-mode sections. There is no filler, and every paragraph contributes either to correct invocation or to preventing misuse.
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?
For a complex calibration tool with eight parameters, the description covers the full invocation workflow, persistence semantics, failure conditions, and safety boundaries. It also references assumptions.volCoordDecaySource and the returned residuals, so with an output schema present, the agent has enough to call the tool correctly and interpret results.
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?
The description substantially enriches the meaning of key parameters: targets must be four or more points spread across the range, shocks are fractions, persist=false means trial-only, and risk_groups should match stress_curve. However, three parameters (betas, fetch_skew, default_beta) have no schema description and are not explained in the description either, leaving a small but real gap.
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 specific verb and resource: 'Fit `vol_coord_decay` to YOUR Risk Navigator, and keep the result.' It clearly distinguishes this calibration tool from siblings like stress_curve by explaining that the fitted decay becomes the default for all later stress_curve calls. The purpose is unmistakable and not a tautology.
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?
The 'What to do' section gives a numbered, actionable workflow, including where to read the curve in TWS, how many points to collect, and how to pass them. It also states when a fit is not stored (unreconciled portfolio) and how persist=false changes behavior. This is explicit, practical guidance an agent can follow directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds substantial behavioral context beyond that, such as the meaning of each connection state, the specific default ports checked, and the content of the `hint` field. No contradiction with annotations.
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 well-structured: a one-sentence purpose, a clear 'when to use' directive, and a bulleted list of states with concise explanations. Each sentence adds value and is front-loaded with the most critical information.
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 parameters and an output schema present, the description fully covers what an agent needs to know: the purpose, when to call, the possible states, and what `hint` provides. Nothing crucial is missing for a diagnostic tool of this complexity.
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?
The tool has zero parameters, so the schema coverage is trivially 100%. The description correctly focuses on behavior and output rather than parameters. A baseline of 4 is appropriate since no parameter clarification is needed.
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 clearly states the tool's purpose: 'Check whether TWS or IB Gateway is reachable and an account is logged in.' It also enumerates the five specific states it distinguishes, making the tool's role unmistakable and differentiating it from siblings that handle trading or risk operations.
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?
Explicitly instructs to 'Call this first whenever another tool fails,' which is direct usage guidance. It also explains how to interpret each state and what `hint` provides, giving the agent clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnly/idempotent/non-destructive annotations: missing strikes appear under 'missing' with reasons, daysToExpiry counts to settlement date (not just trading date), and instrument-root ambiguity is resolved via 'underlying' and 'warnings'. These are valuable behavioral traits not inferable from annotations alone, and there is no contradiction.
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 long but every section earns its place, with bolded headings breaking up distinct concepts (deterministic repricing, don't collapse, settlement dates, missing strikes, instrument ambiguity). It is front-loaded with the core definition and then layers critical warnings. No filler or redundant phrasing.
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?
For a tool with 9 parameters and an output schema, the description covers the essential contextual pitfalls: settlement vs trading date, missing strike handling, root-symbol collisions, and usage cautions about term structure. The output schema exists, so return values need no elaboration. The tool is complex and the description fully equips the agent with the needed context.
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 78%, so the schema already explains most parameters. The description adds meaningful context for several: it explains sec_type disambiguation with the 'ES' example, trading_class resolution for same-day expiries, strike snapping behavior, and the rate-limit implication of max_strikes_per_expiry. This goes beyond the schema's dry definitions, though not exhaustively for all parameters.
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 clearly states the tool returns IB's implied volatility surface for an underlying, with a grid of (expiry, strike) and specific fields. It uses a specific verb ('get') and resource ('volatility surface'), and the detailed behavior distinguishes it from sibling tools dealing with margin, greeks, stress, and orders.
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?
Extensive usage guidance is provided: it explains when to use the surface for local repricing, warns against collapsing the surface to a single number, advises reading the correct tenor and interpolating in total variance, and tells users to check the underlying instrument to avoid ambiguity. It gives clear context and practical 'how to use' directions, though it doesn't name alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, and the description adds substantial beyond-annotation detail: silent fallback from sticky_moneyness to sticky_strike, fitted unpublished decay parameters, bonds held flat unless a shift is set, FX reported under excluded rather than silently ignored, and the explicit warning to check reconciled before quoting results. No contradiction exists.
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 long, but every section earns its place: it front-loads the core purpose, then organizes verification, silent fallbacks, curve construction, valuation-date families, and breakdowns under clear bolded lead-ins. The depth is proportional to a 16-parameter analytical tool, and there is no tautology or padding.
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 an output schema present, the description does not need to enumerate return fields, yet it still covers the critical ones: curves, valuationDate, dateOffsetDays, pnl_by_expiry, excluded, warnings, netLiquidation, and reconciled. It also explains verification, model provenance, and calibration state, making it complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high at 81%, but the description still adds real meaning: volSlopeDown is volatility points per 1% fall, vol_coord is multiplicative rather than shifted, date_offsets creates one consistent family of valuations, and breakdown='expiry' keys on settlement date. It turns parameter names into decision-relevant concepts rather than mere labels.
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 deliverable: the portfolio P&L curve under several volatility regimes, positioned as the data behind a risk graph for plotting. It distinguishes itself from the single-curve sibling by emphasizing that this tool guarantees one loading of the portfolio across all scenarios.
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?
Provides explicit operational guidance: read the slope-0 curve first as the external check, prefer vol_coord unless a flat regime is specifically wanted, use fetch_skew when volSurfaceUsed is thin, and use breakdown='expiry' to see which expiry drives the trough. It also names alternatives and failure conditions, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ibkr-risk-mcp MCP server](https://glama.ai/mcp/servers/simoneb/ibkr-risk-mcp/badges/card.svg)](https://glama.ai/mcp/servers/simoneb/ibkr-risk-mcp)

Score Badge

Copy to your README.md:

[![ibkr-risk-mcp MCP server](https://glama.ai/mcp/servers/simoneb/ibkr-risk-mcp/badges/score.svg)](https://glama.ai/mcp/servers/simoneb/ibkr-risk-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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