Skip to main content
Glama
HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics

HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics

get_pretrade_risk_scan

Read-onlyIdempotent

Run a pre-trade risk scan on a stock to compare volatility, beta, VaR and drawdown against SPY, evaluate position-sizing guardrails, and assess portfolio exposure and correlation impact before trading.

Instructions

Run a pre-trade risk scan for a single stock: the stock's own volatility/beta/VaR/drawdown set against the SPY benchmark, market regime, a forward return distribution for the stock, position-sizing checks on the stock's own metrics, and — against the user's tracked watchlist — the sector/symbol exposure impact of adding it and its correlation to existing holdings.

riskDeltas compare SPY with the stock on its own. They are NOT the risk of the user's portfolio before and after the trade; only exposure and correlation use the portfolio.

Use this tool when:

  • You need a risk-first check before evaluating or placing a trade.

  • You want position-sizing guardrails (volatility, drawdown, beta, liquidity) evaluated against warn/fail thresholds, not just raw numbers.

  • You need to see how adding this symbol would shift sector or per-symbol concentration in the existing portfolio.

  • You want the new symbol's correlation to current holdings, to judge diversification benefit vs. redundant exposure.

Do NOT use this tool for:

  • A standalone price-distribution simulation with no portfolio context → use get_monte_carlo instead.

  • A general bullish/bearish read on the stock → use analyze_stock.

Example

get_pretrade_risk_scan("NVDA")

Returns

dict with keys: symbol : str — normalized ticker asOf : str — ISO 8601 date the scan was computed regime : str — "bull" | "bear" | "chop" market regime regimeConfidence: float — 0–1 confidence in the regime classification riskDeltas : list — the stock's own risk metrics next to the SPY benchmark's (field names are historical; neither side is a portfolio), each a dict: label : str — e.g. "Annualized Volatility", "Beta (vs SPY)", "1-Day VaR (95%)", "Max Drawdown (1Y)" beforeValue : float — the SPY benchmark's value (beta is 1.0) afterValue : float — the scanned stock's own value unit : str — "%" or "" (unitless, e.g. beta) higherIsRiskier : bool — whether an increase in this metric is worse distribution : dict — the stock's simulated forward return distribution over methodology.monteCarlo .horizonDays trading days (10): {"bins": list, "frequencies": list, "kde_x": list, "kde_y": list} range_90 : dict — {"lower": float, "upper": float} 5th-95th percentile of that forward return (%) mean : float — mean simulated forward return (%) threshold : float — break-even line of the distribution (0.0) sizingChecks : list — pass/warn/fail guardrail checks on the stock's own metrics, each a dict: label : str — "Volatility" | "Drawdown Risk" | "Market Exposure" | "Liquidity" status : str — "pass" | "warn" | "fail" detail : str — human-readable explanation with the thresholds used. Liquidity is the 20-day average of close x volume in the ticker's quote currency (no FX conversion); the service warns below 5,000,000 and fails below 500,000, and the detail text states those limits. Services deployed before 2026-10-12 print $50M / $5M in the text; the limits applied were 5,000,000 / 500,000 throughout. exposure : dict — portfolio concentration impact: available : bool — false if the user has no watchlist symbols to compare against bySector : list of {sector, currentPct, postTradePct, deltaPct} — empty list when available is false bySymbol : list of {symbol, currentPct, postTradePct, deltaPct} — empty list when available is false concentrationFlag : str — "pass" | "warn" | "fail" | "unknown" ("unknown" when available is false) assumedPositionWeight: float | None — None when available is false weightingMethod : str — e.g. "equal_weight_proxy" reason : str — present only when available is false; human-readable explanation (e.g. "No watchlist symbols to compare against. Add symbols to your watchlist to see portfolio exposure.") — surface this to the user instead of guessing why the section is empty correlation : dict — correlation of the new symbol to holdings: available : bool — false if the user has no watchlist symbols to compare against aggregate : dict | None — None when available is false; otherwise {avgCorrelationWithPortfolio, level, mostCorrelated: {symbol, correlation}, leastCorrelated: {symbol, correlation}} matrix : dict | None — None when available is false; otherwise {"symbols": list, "values": list[list[float]]} full pairwise correlation matrix reason : str — present only when available is false; human-readable explanation (e.g. "No watchlist symbols to compare against. Add symbols to your watchlist to see correlation.") — surface this to the user instead of guessing why the section is empty methodology : dict — how the scan was computed, read from the constants the computation uses. Absent from services deployed before 2026-10-12. Includes: monteCarlo : dict — {"model": "gbm", "horizonDays": int (10), "paths": int, "seeded": bool}; horizonDays is the horizon of distribution / range_90 / mean var : dict — {"method": "historical", "confidence": 0.95, "horizonDays": 1} thresholds : dict — warn/fail limits for every check, e.g. "turnoverBelow": {"warn": 5000000, "fail": 500000} windowStart, windowEnd, lookbackCalendarDays, observations, benchmark, benchmarkFallback, returns, annualizationDays, beta, maxDrawdownDays

Notes

  • Requires a valid HPSILAB_API_KEY.

  • Requires a paid plan (Developer, Team, Enterprise, Pro, or Pro Lifetime). A Free account is refused with HTTP 403 (http_error, status_code 403) and is not charged.

  • Each call deducts Credits from the account (x-credits in this tool's metadata). The Credits check runs first, so an empty balance is insufficient_credits (402) even on a Free account. Confirm with the user before calling it.

  • Exposure and correlation sections assume the user has an existing tracked watchlist/portfolio. If none exists, "available" is false in both sections, their data fields are null/empty, and each includes a "reason" string explaining why — relay that reason to the user (e.g. suggest adding symbols to their watchlist) rather than treating the missing data as an error.

Input Schema

NameRequiredDescriptionDefault
symbolYesExchange ticker in uppercase, e.g. 'NVDA', 'AAPL', 'SPY'. Do NOT pass company names — use official tickers only.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "get_pretrade_risk_scanDictOutput",
      +  "type": "object"
      +}
  2. Addedv0.3.1

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: discloses the HPSILAB_API_KEY requirement, that a paid plan is needed and Free accounts get a 403 without being charged, that each call deducts Credits and an empty balance yields 402, and instructs the agent to confirm with the user before spending credits. It also pre-explains degraded behavior when the user has no watchlist (available=false, null fields, relay the reason rather than treat as an error).

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

Conciseness3/5

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

Purpose, usage rules, and the exclusions are front-loaded and earn their place, as do the two important caveats (riskDeltas are not portfolio deltas; liquidity threshold text drift in pre-2026-10-12 deployments). However, the Returns block reproduces an output schema that already exists, at great length — nearly half the description restates field-by-field output structure.

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 single-parameter but behaviorally complex tool, everything an agent needs is present: cost/auth gating, failure modes, the version-drift caveat on liquidity thresholds, and the explicit handling of unavailable exposure/correlation sections. The output schema carries return shapes, yet the description's clarifications about historically-named fields add real value rather than redundant detail.

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?

Only one parameter and schema coverage is 100%, so the schema already states the uppercase ticker pattern and forbids company names. The description adds little beyond the example call get_pretrade_risk_scan("NVDA") — no further semantics about normalization or symbol resolution, which is the baseline case.

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?

Names a specific verb and scope ("pre-trade risk scan for a single stock") and enumerates its components: volatility/beta/VaR/drawdown vs SPY, regime, forward return distribution, sizing checks, and watchlist-based exposure/correlation. It also makes the scope boundary explicit — riskDeltas compare SPY vs stock, and only exposure/correlation use the portfolio — which an agent could not infer from the name.

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 an explicit "Use this tool when" list of four scenarios and a "Do NOT use this tool for" list that routes to named siblings: get_monte_carlo for standalone price simulation and analyze_stock for a general directional read. Both the positive and negative conditions are stated, not implied.

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