Skip to main content
Glama

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

Portfolio Risk

workflow.run_portfolio_risk
Read-only

Aggregates risk across multiple open positions in one call: total notional, total P&L, total margin in use, margin usage as a % of account balance (if given), and which single position sits closest to liquidation. Each position is computed through the same canonical PnL/liquidation math as the single-position tools, then rolled up. Linear (USDT-margined) positions sum into one USD total; inverse (coin-margined) positions are grouped by settlement coin instead, since a BTC-margined P&L cannot be summed with an ETH-margined one without a live conversion rate. Returns a verdict label, healthy / watch / reduce / critical, which places the closest liquidation distance and margin usage in fixed bands and is not a recommendation. Edge cases: 1 to 50 positions; each needs entry_price, mark_price, size and leverage above zero, mmr 0 to 0.2 and fees 0 to 0.05 as fractions; an inverse position must name its settlement coin; account_balance above zero is optional and without it margin usage is not computed. Positions are not netted against each other. Not covered: correlation between positions, collateral shared across positions, exchange tiered margin, funding, and price moves after the mark price you give. Use when user asks "how exposed am I across all my positions?" or "which of my positions is closest to liquidation?". Position size follows the product-wide convention: base-asset quantity for linear, USD notional (contracts) for inverse. liquidation_price and liq_distance_pct of a position are null when it cannot be liquidated (an inverse short at 1x or less); the closest liquidation skips it.

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": {
      "positions": "<positions>"
    },
    "name": "workflow.run_portfolio_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
positionsYesOpen positions to aggregate (1 to 50). Each: { side, entry_price, mark_price, size, leverage }, plus optional fees, mmr, mmBase, liqFeeRate, contractType, coin, label.
account_balanceNoOptional account balance in USD, used to compute margin_usage_pct: linear margin plus every inverse position's own margin marked to market at its mark_price, all as one USD total

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / positions / items / properties / mmr / description
      Previous value: -"Maintenance margin rate (default 0.005)"New value: +"Maintenance margin rate as a fraction, 0 to 0.2 (default 0.005 = 0.5%); not a percent: 0.5% is 0.005, not 0.5"
    • addedInput schema / properties / positions / items / properties / mmr / maximum
      Added value: +0.2
    • addedInput schema / properties / positions / items / properties / mmr / minimum
      Added value: +0
  2. Changed3 schema fields changed
    • changedInput schema / properties / positions / description
      Previous value: -"Open positions to aggregate (1 to 50). Each: { side, entry_price, mark_price, size, leverage }, plus optional fees, mmr, contractType, coin, label."New value: +"Open positions to aggregate (1 to 50). Each: { side, entry_price, mark_price, size, leverage }, plus optional fees, mmr, mmBase, liqFeeRate, contractType, coin, label."
    • addedInput schema / properties / positions / items / properties / liqFeeRate
      Added value: +{
      +  "description": "Liquidation fee as a fraction of position value, default 0, max 0.05; added to mmr.",
      +  "type": "number"
      +}
    • addedInput schema / properties / positions / items / properties / mmBase
      Added value: +{
      +  "description": "Value the maintenance margin is taken on: \"liquidation\" = position value at the liquidation price (default), \"entry\" = entry value.",
      +  "enum": [
      +    "liquidation",
      +    "entry"
      +  ],
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / positions / description
      Added value: +"Open positions to aggregate (1 to 50). Each: { side, entry_price, mark_price, size, leverage }, plus optional fees, mmr, contractType, coin, label."
    • addedInput schema / properties / positions / items / properties / side / description
      Added value: +"Trade direction: \"long\" or \"short\""
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a safe read operation, and the description still adds substantial behavioral context: the verdict label is explicitly 'not a recommendation', positions are not netted, linear vs inverse results are grouped differently, and liquidation_price/liq_distance_pct are null for non-liquidatable positions with the closest-liquidation calc skipping them. Validation bounds (1–50 positions, mmr 0–0.2, fees 0–0.05, account_balance optional) are spelled out so failures are predictable.

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 what is aggregated and the roll-up rule, then edges cases and exclusions, which is the right order. It is long and repeats a few schema facts (mmr/fee ranges, size convention), but nearly every sentence carries decision-relevant 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 output schema, the description covers the return surface itself (aggregate totals, verdict bands, per-position nulls) and the input constraints, so an agent knows both what it gets and what it must supply. Nothing needed to call this correctly 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the field-level docs: it explains why inverse positions are grouped by settlement coin, that account_balance is optional and without it margin usage is not computed, and that contractType/coin interact as a requirement. The size convention it repeats is already in the schema, which keeps it from a 5.

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 ('aggregates risk across multiple open positions in one call') and enumerates exactly what is computed: total notional, total P&L, total margin, margin usage %, and the position closest to liquidation. It distinguishes itself from the single-position siblings by explaining that each position goes through the same canonical math and is then rolled up, so an agent can tell it apart from run_liquidation_safety or run_liquidation_live.

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?

Gives concrete invocation triggers ('how exposed am I across all my positions?', 'which of my positions is closest to liquidation?') and a scope-exclusion list (correlation, shared collateral, tiered margin, funding, post-mark price moves) that tells the agent what this tool will not answer. It only implies, rather than names, the per-position alternative for single-position questions.

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.