Skip to main content
Glama

RiskModels Portfolio Hedge Levels and ETF Hedge

riskmodels_analyze_portfolio
Read-only

Compute holdings-weighted L1, L2, and L3 hedge ratios and ETF hedge notionals for a long-only portfolio of up to 100 dollar positions.

Instructions

Use when you have a long-only book of up to 100 names and want its holdings-weighted L1, L2 and L3 hedge ratios, or the ETF hedge notionals for dollar positions. Not for books with shorts or more than 100 names (use riskmodels_portfolio_exposure) or a variance decomposition with return attribution (use riskmodels_get_portfolio_risk_snapshot). Returns, from POST /batch/analyze, portfolio hedge levels at L1, L2 and L3 with per-ticker detail. Only when every position is given in dollars does it also return the ETF hedge notionals at hedge_level (set by level, default L3), by ticker and summed by ETF; with weights, level is ignored. End-of-day data, refreshed after each US market close. Price: $0.015 per position, minimum $0.03 per call.

Input Schema

NameRequiredDescriptionDefault
levelNoHedge depth for the ETF notionals, used only when every position is in dollars, e.g. L2 (default L3)
yearsNoLookback window in years, integer 1-30, e.g. 2 (default 1)
positionsYesLong positions, each with weight or dollars, combined per ticker, e.g. [{"ticker":"AAPL","dollars":25000},{"ticker":"NVDA","dollars":15000}]

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.0.12
    • addedInput schema / properties / level
      Added value: +{
      +  "description": "Hedge depth for the ETF notionals, used only when every position is in dollars, e.g. L2 (default L3)",
      +  "enum": [
      +    "L1",
      +    "L2",
      +    "L3"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / positions / description
      Previous value: -"Positions with weight or dollars (combined per ticker)"New value: +"Long positions, each with weight or dollars, combined per ticker, e.g. [{\"ticker\":\"AAPL\",\"dollars\":25000},{\"ticker\":\"NVDA\",\"dollars\":15000}]"
    • addedInput schema / properties / positions / items / properties / dollars / description
      Added value: +"Positive position value in US dollars, e.g. 25000"
    • addedInput schema / properties / positions / items / properties / ticker / description
      Added value: +"US stock ticker symbol, e.g. AAPL"
    • addedInput schema / properties / positions / items / properties / weight / description
      Added value: +"Positive portfolio weight, any scale, e.g. 0.4"
    • changedInput schema / properties / years / description
      Previous value: -"Batch lookback window, default 1"New value: +"Lookback window in years, integer 1-30, e.g. 2 (default 1)"
  2. First observedv1.0.11

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the read-only/no-destruction profile, and the description adds substantive behavior beyond them: conditional output (ETF notionals only when all positions are in dollars; level ignored with weights), data freshness (end-of-day, refreshed after US close), and pricing ($0.015/position, $0.03 minimum). These are exactly the traits an agent cannot get from the structured fields.

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 the use case, then exclusions, then returns, then cost/freshness. Dense and mostly waste-free, though the returning-behavior sentence is somewhat long and could be split for scanability.

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?

No output schema exists, but the description explains return values, the conditional branch that gates ETF notionals, defaults (level default L3), limits (100 names), data latency, and cost. An agent has everything needed to call and interpret it correctly.

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 baseline is 3, but the description adds meaning the schema does not: that 'level' is used only when every position is in dollars and is ignored when weights are supplied, and that the dollars-vs-weight choice gates which outputs appear. That conditional coupling of parameters to outputs is genuine added value.

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 resource (long-only portfolio hedge levels / ETF hedge notionals) and the exact conditions (up to 100 names, holdings-weighted L1-L3). It explicitly names the siblings it is not for, so an agent can distinguish it from riskmodels_portfolio_exposure and riskmodels_get_portfolio_risk_snapshot without opening schemas.

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 ('long-only book of up to 100 names'), when-not ('books with shorts or more than 100 names'), and names the alternative tool for each excluded case. Nothing is left to inference.

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