Institutional-grade portfolio risk analytics for Claude and any MCP client.
VaR / Monte Carlo / Stress Testing / Portfolio Optimization / Greeks / Correlation Matrices
Real market data. Real math. Not hallucinated numbers.
Website · Get Pro · Documentation
1. Install
npm install -g @quantrisk/mcp-server2. Configure (Claude Desktop — see below for Cursor)
Add to your claude_desktop_config.json:
{
"mcpServers": {
"quantrisk": {
"command": "quantrisk-mcp-server",
"env": {
"QUANTRISK_API_KEY": "your-api-key"
}
}
}
}Get your free API key at quantrisk.dev/signup.
3. Ask Claude
"What's the Value at Risk on a portfolio of 60% SPY, 25% TLT, and 15% GLD?"
That's it. Claude now has access to institutional-grade risk analytics.
Related MCP server: optionslab
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"quantrisk": {
"command": "quantrisk-mcp-server",
"env": {
"QUANTRISK_API_KEY": "your-api-key"
}
}
}
}Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"quantrisk": {
"command": "quantrisk-mcp-server",
"env": {
"QUANTRISK_API_KEY": "your-api-key"
}
}
}
}QuantRisk works with any client that supports the Model Context Protocol. Point it at the quantrisk-mcp-server binary with your API key in the environment.
Tool | Description | Tier |
| VaR, CVaR, volatility, Sharpe ratio, max drawdown | Free |
| Forward-looking return simulations with configurable paths | Free |
| Portfolio impact under historical and hypothetical scenarios | Free |
| Historical price and return data for any supported ticker | Free |
| Sector and industry breakdown across holdings | Free |
| Return attribution by asset, sector, and factor | Free |
| Cross-asset correlation analysis | Free |
| Mean-variance and risk-parity optimization | Pro |
| Side-by-side risk/return comparison of multiple portfolios | Pro |
| Options Greeks — delta, gamma, theta, vega, rho | Pro |
Once configured, ask Claude questions like these:
"Run a Monte Carlo simulation on my portfolio: 50% AAPL, 30% MSFT, 20% NVDA. Show me the 5th percentile outcome."
"Stress test 70% VTI / 30% BND against the 2008 financial crisis and a hypothetical 300bp rate shock."
"What's my sector exposure if I hold equal weights in AMZN, JPM, JNJ, XOM, and NEE?"
"Show me the correlation matrix for SPY, GLD, TLT, and BTC-USD over the last 2 years."
"Compare the risk-adjusted returns of a 60/40 portfolio vs. an all-weather portfolio." (Pro)
"Calculate the Greeks for a SPY 550 call expiring in 30 days." (Pro)
The free tier covers core risk analytics for small portfolios. Pro unlocks the tools and scale that serious analysis demands.
Free | Pro ($29/mo) | |
Positions | 20 | 500 |
API calls | 50/day | Unlimited |
Tools | 7 | All 10 |
Monte Carlo paths | 1,000 | 100,000 |
Portfolio optimization | — | Mean-variance, risk-parity, min-volatility |
Portfolio comparison | — | Side-by-side multi-portfolio analysis |
Options Greeks | — | Full Greeks surface |
What that means in practice:
Free: "What's the VaR on my 10-stock portfolio?" — works great.
Pro: "Optimize my 200-position portfolio for maximum Sharpe, then stress test it against 5 scenarios and compare it to my current allocation." — you need Pro for that.
Claude / MCP Client
|
MCP Protocol
|
QuantRisk MCP Server (local process)
|
QuantRisk API (Cloudflare Workers)
|
Yahoo Finance (market data) + risk engine (math)MCP Server runs locally as a stdio process — your API key never leaves your machine except to authenticate with the QuantRisk API.
Risk Engine runs on Cloudflare Workers. All calculations — VaR, Monte Carlo, optimization — happen server-side with real math on real market data.
Market Data sourced from Yahoo Finance. Prices, fundamentals, and options chains are fetched in real time.
Reports generated with pdf-lib when applicable.
No data is stored. No portfolio information is retained after a request completes.
Contributions are welcome. Please open an issue first to discuss what you'd like to change.
git clone https://github.com/78degrees/mcp-server.git
cd mcp-server
npm install
npm testSee CONTRIBUTING.md for guidelines.
Built by the team at quantrisk.dev
Contact: hello@quantrisk.dev
Calculate core risk metrics for a portfolio — Value at Risk (VaR), Conditional VaR (CVaR), volatility, beta, and max drawdown.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | Array of portfolio positions. Each entry needs a ticker and quantity. Free tier: max 20 positions. Paid tier: up to 500. | |
| confidence_level | No | VaR confidence level as a decimal, e.g. 0.95 = 95%. Range: 0.01-0.99. Default: 0.95. | |
| horizon_days | No | Risk horizon in trading days. 1 = overnight, 21 ≈ 1 month, 252 ≈ 1 year. Default: 1. | |
| method | No | VaR calculation method. "historical" uses empirical return distribution, "parametric" assumes normality, "cornish_fisher" adjusts for skew and kurtosis. Default: "historical". | historical |
| benchmark | No | Benchmark ticker for beta calculation, e.g. SPY or QQQ. Default: SPY. | SPY |
| lookback_days | No | Number of historical trading days to use. 252 ≈ 1 year, 756 ≈ 3 years. Range: 30-1260. Default: 252. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists the output metrics but fails to describe key behavioral traits such as how calculations are performed, whether it makes external API calls, or if there are data freshness requirements. The description adds minimal beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose and lists key outputs. There is no extraneous information, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 1 required, no output schema), the description is minimal. It adequately states the calculated metrics but does not explain the return format, constraints (e.g., max positions), or provide any operational context beyond the schema. It meets a basic standard but could be improved for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all six parameters are fully described in the schema. The tool description itself does not mention any parameters or add value beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates core risk metrics for a portfolio and names specific metrics (VaR, CVaR, volatility, beta, max drawdown). This distinctively separates it from sibling tools like calculate_greeks or stress_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context on prerequisites, such as needing the portfolio positions or data, and does not mention situations where other sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate option Greeks (delta, gamma, theta, vega, rho) for individual options or an options portfolio. Uses Black-Scholes for European, binomial for American style. Paid tier only.
| Name | Required | Description | Default |
|---|---|---|---|
| options | Yes | Array of option positions to calculate Greeks for. 1-100 options. Results include per-option Greeks and aggregated portfolio Greeks. | |
| risk_free_rate | No | Annualized risk-free rate as a decimal, e.g. 0.05 = 5%. Used in Black-Scholes and binomial pricing models. Default: 0.05. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It reveals the tool uses Black-Scholes for European options and binomial for American, and notes it's paid-tier only. This provides useful model-specific context, though it doesn't detail error handling or data sources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. All information is essential and front-loaded: action, resource, models, and constraint (paid tier). Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema means description should clarify return values, but it only states what is calculated, not what the agent receives (e.g., object structure, aggregation). The schema's 'description' field for options covers per-option and portfolio results, partially compensating. Still, the description leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—all parameters are described in the schema. The description does not add new semantics beyond stating the tool calculates Greeks per option or portfolio, which is already implied by the tool name and schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates option Greeks (delta, gamma, theta, vega, rho) for individual options or portfolios, using specific models (Black-Scholes, binomial). This directly conveys the resource and action, distinguishing it from broader risk tools like 'analyze_risk'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. sibling tools. The description lacks explicit context for appropriate usage, such as prerequisites or conditions for choosing this over alternatives like 'analyze_risk' or 'monte_carlo_simulation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two or more portfolio allocations head-to-head across all key risk and return metrics. Paid tier only.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolios | Yes | Two to five named portfolios to compare head-to-head. Each needs a unique name and a list of positions. Min: 2, max: 5. | |
| period_days | No | Lookback period in trading days used for return and risk calculations. 252 = ~1 year. Range: 30-1260. Default: 252. | |
| confidence_level | No | VaR confidence level as a decimal, e.g. 0.95 = 95%. Range: 0.01-0.99. Default: 0.95. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the paid tier requirement but does not state whether the tool is read-only or modifies data, nor does it describe the output shape or side effects. The term 'compare... across all key risk and return metrics' is vague about what metrics are computed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: purpose then restriction. No filler, but could include a brief note on output or usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (3 parameters, no output schema, no annotations). The description omits critical context such as what the return value contains, whether results are displayed or returned as data, and how metrics are defined. This forces the agent to guess or rely on the schema alone, which is insufficient for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes each parameter thoroughly. The description adds no parameter-level details beyond the schema. Baseline score of 3 applies as the description does not degrade but adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compare' and the resource 'portfolio allocations head-to-head across all key risk and return metrics.' It distinguishes from sibling tools like analyze_risk or correlation_matrix by implying a broad comparison rather than a focused calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only mentions 'Paid tier only' as a restriction. It does not explain scenarios where compare_portfolios is preferred over analyze_risk, optimize_portfolio, or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the pairwise correlation matrix for a set of assets. Identifies highly correlated pairs and diversification opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Tickers to include in the correlation matrix. Minimum 2, maximum 50. Free tier: max 10 tickers. Paid tier: up to 50. | |
| lookback_days | No | Historical window for computing correlations in trading days. 30 = ~6 weeks, 252 = ~1 year. Range: 30-1260. Default: 252. | |
| method | No | Correlation method. "pearson" = linear correlation (standard), "spearman" = rank-based (robust to outliers), "kendall" = concordance-based. Default: "pearson". | pearson |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool computes correlations but doesn't disclose any behavioral traits (e.g., data freshness, rate limits, or side effects). It is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states purpose, second adds actionable output. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains returns (highly correlated pairs, diversification) but lacks specifics on output format or error handling. Adequate for a simple tool but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value by explaining the method options (pearson, spearman, kendall) and ticker limits (free vs paid tier), which is not in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and resource ('pairwise correlation matrix'), and adds context about identifying correlated pairs and diversification, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions identification of pairs and diversification, implying when to use, but lacks explicit guidance on when not to use or comparison with sibling tools like analyze_risk or stress_test.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Monte Carlo simulation on a portfolio to model the distribution of future returns, including percentile outcomes and probability of loss.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | Array of portfolio positions. Free tier: max 20 positions. Paid tier: up to 500. | |
| num_paths | No | Number of simulation paths to run. More paths = more accurate but slower. Free tier: max 1,000. Paid tier: up to 100,000. Default: 10,000. | |
| horizon_days | No | Simulation horizon in trading days. 21 ≈ 1 month, 63 ≈ 1 quarter, 252 ≈ 1 year. Default: 21. | |
| model | No | Stochastic process model. "gbm" = Geometric Brownian Motion (standard), "jump_diffusion" = adds jump risk for fat-tail scenarios. Default: "gbm". | gbm |
| lookback_days | No | Historical window used to estimate drift and volatility parameters. Range: 30-1260 trading days. Default: 252. | |
| seed | No | Random seed for reproducible results. Omit for a fresh random run each time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool runs simulations and outputs distribution metrics, but does not mention key behaviors such as reliance on historical data (lookback_days), computational cost scaling with num_paths, or any side effects like data caching. The description is adequate but lacks depth on assumptions and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that efficiently conveys the core functionality and outputs. It is front-loaded and uses precise language. While it could be broken into bullet points for readability, it is not unnecessarily verbose and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description provides a high-level summary of outputs ('percentile outcomes and probability of loss') but does not detail the structure of the results (e.g., return distribution, summary statistics). The schema covers parameters thoroughly, but the description could be more complete regarding expected output format and edge case handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters and their purposes. The description adds no additional parameter-level meaning beyond what is in the schema (e.g., does not explain how seed affects reproducibility or how model choice changes output). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run Monte Carlo simulation on a portfolio to model the distribution of future returns, including percentile outcomes and probability of loss.' This uses a specific verb ('Run') and resource ('Monte Carlo simulation on a portfolio'), and distinguishes it from sibling tools like stress_test or analyze_risk by specifying its unique output (distribution, percentile outcomes, probability of loss).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context (modeling future returns distribution) but does not explicitly state when to use this tool versus alternatives like 'analyze_risk' or 'stress_test'. No 'when not to use' or comparison to siblings is provided, leaving the agent to infer from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the optimal portfolio allocation using mean-variance optimization. Supports max Sharpe, min variance, and target return objectives. Paid tier only.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Universe of tickers to optimize across. Must be 2-50 tickers. The optimizer will determine the best weights within this set. | |
| objective | No | Optimization objective. "max_sharpe" = maximize risk-adjusted return, "min_variance" = minimize portfolio volatility, "target_return" = hit a specific return with minimum risk. Default: "max_sharpe". | max_sharpe |
| target_return | No | Required when objective is "target_return". Annualized return as a decimal, e.g. 0.12 = 12% annual return target. | |
| constraints | No | Optional weight constraints. See ConstraintsInput for details. | |
| risk_free_rate | No | Annualized risk-free rate as a decimal, e.g. 0.05 = 5%. Used in Sharpe ratio calculation. Default: 0.05. | |
| lookback_days | No | Historical window for estimating return and covariance. 252 = 1 year, 756 = 3 years, 1260 = 5 years. Range: 252-1260. Default: 756. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It discloses that the tool is mean-variance optimization and mentions the paid tier restriction, but does not cover error conditions, side effects, or data requirements beyond what is implicit in a read-only computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core intent, and contains no redundant or extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema), the description is brief. It lacks any mention of the output format (e.g., returned weights). While the core functionality is covered, the absence of return value information reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 6 parameters described in the schema). The description adds little beyond the schema: it lists objectives and mentions constraints, but these are already detailed in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find the optimal portfolio allocation using mean-variance optimization.' It lists supported objectives (max Sharpe, min variance, target return) and distinguishes it from siblings like analyze_risk or compare_portfolios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Paid tier only,' indicating a usage restriction, but does not provide explicit guidance on when to use this tool versus alternatives such as monte_carlo_simulation or compare_portfolios. Usage context is implied but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break down portfolio performance into factor exposures, sector allocation, and position contributions. Computes Sharpe, Sortino, Treynor, Calmar, and Information ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | Array of portfolio positions. Free tier: max 20 positions (basic ratios only). Paid tier: up to 500 positions with full factor attribution. | |
| period_days | No | Measurement period in trading days. 252 = ~1 year. Range: 30-1260. Default: 252. | |
| benchmark | No | Benchmark ticker for relative performance metrics (Information Ratio, Tracking Error, Beta). Default: SPY. | SPY |
| risk_free_rate | No | Annualized risk-free rate as a decimal, e.g. 0.05 = 5%. Used in Sharpe, Sortino, and Treynor ratios. Default: 0.05. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions computations but omits whether the tool is read-only, any auth requirements, rate limits, or side effects. The free tier limitation on positions is documented only in the schema, not the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every word is necessary; no fluff or redundancy. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values. It lists the outputs (factor exposures, sector allocation, contributions, ratios) but lacks details on structure, format, or how results are presented. Adequate but incomplete for a tool with complex output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The main description adds no extra parameter information beyond what the schema already provides. It does not elaborate on parameter usage, defaults, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool breaks down portfolio performance into factor exposures, sector allocation, and position contributions, and lists specific ratios computed. This verb-resource pair is distinct from sibling tools like sector_exposure (focused only on sectors) or calculate_greeks (options-focused), making it easy for an agent to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like sector_exposure or analyze_risk. The description implies it is for detailed performance decomposition but does not state exclusions, prerequisites, or when a simpler tool would suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch historical OHLCV price data for one or more tickers. Free tier: 1 ticker, 252 days. Paid tier: up to 20 tickers, 1260 days.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Ticker symbols to fetch price history for. Free tier: max 1 ticker. Paid tier: up to 20 tickers. | |
| days | No | Number of historical trading days to return. Free tier: max 252 days (~1 year). Paid tier: up to 1260 days (~5 years). Default: 252. | |
| interval | No | Price interval. "daily" returns one OHLCV row per trading day, "weekly" aggregates to weekly bars, "monthly" aggregates to monthly bars. Default: "daily". | daily |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral constraints (tier limits, intervals) but does not mention response format, rate limiting, data source, or error handling. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with zero wasted words. It front-loads the core purpose and efficiently adds tier constraints. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the conciseness, the description lacks important details for a data-fetching tool: it does not specify the return format (OHLCV columns, order, date range), data source, or pagination behavior. With no output schema, these omissions leave the agent guessing about the response structure, making it incomplete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (tickers, days, interval) documented. The description adds context about tier limits, but this is already present in the schema's parameter descriptions. Thus, the description adds no significant meaning beyond the schema, warranting a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch', the resource 'historical OHLCV price data', and specifies the scope ('one or more tickers'). It distinguishes from sibling tools (like analyze_risk, compare_portfolios) which focus on analysis rather than raw data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with tier limitations (free/paid) for ticker count and days, guiding usage based on user's plan. However, it does not explicitly mention when not to use this tool or direct to alternatives for derived metrics, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break down portfolio exposure by GICS sector, market cap, and asset class. Returns concentration metrics including the Herfindahl-Hirschman Index.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | Array of portfolio positions to analyze. Returns GICS sector weights, market cap breakdown, and concentration metrics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool is a read-only computation returning sector weights and concentration metrics, but lacks details on error handling, invalid inputs, or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise and front-loaded with the primary action. Every sentence is necessary and informative without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 1 parameter, no output schema, and no annotations, the description explains the main purpose and one output metric (HHI) but lacks details on the complete return structure or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context that the tool computes exposure from positions but does not provide additional parameter syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it breaks down portfolio exposure by GICS sector, market cap, and asset class, and returns concentration metrics like HHI. This is specific and distinguishes from sibling tools like 'analyze_risk' or 'performance_attribution'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sector exposure analysis but does not explicitly compare to alternatives or state when not to use it. No guidance on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stress test a portfolio against historical crisis scenarios (GFC 2008, COVID 2020, etc.) or custom shocks (paid tier).
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | Array of portfolio positions. Free tier: max 20 positions and historical scenarios only. Paid tier: up to 500 positions plus custom shocks. | |
| scenarios | No | Historical scenarios to run. Available values: gfc_2008, covid_2020, dot_com_2000, black_monday_1987, taper_tantrum_2013, rate_hike_2022, volmageddon_2018, euro_crisis_2011. Default: [gfc_2008, covid_2020]. | |
| custom_shocks | No | Custom shock definitions. PAID tier only. Each shock specifies ticker-level, sector-level, or market-wide price changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions tier restrictions. It does not disclose whether the operation is read-only, destructive, or requires specific permissions. Behavioral traits beyond the schema are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's core function. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. While parameters are well-described in the schema, the description does not explain what the tool returns (e.g., P&L impact, risk metrics) or how the output should be interpreted. This leaves a gap for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by summarizing the two main parameter categories (historical scenarios vs custom shocks) and mentioning the paid tier limitation, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (stress test), resource (portfolio), and context (historical crisis scenarios or custom shocks). It is specific but does not explicitly differentiate from sibling tools like monte_carlo_simulation or analyze_risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or limitations beyond paying for custom shocks. The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_riskcalculate_greekscompare_portfolioscorrelation_matrixmonte_carlo_simulationoptimize_portfolioperformance_attributionprice_historysector_exposurestress_testScored across 10 tools
Each tool targets a distinct financial analysis function (risk metrics, greeks, comparison, correlation, simulation, optimization, attribution, history, sector exposure, stress test) with no overlap.
All tool names consistently follow the verb_noun pattern with snake_case (e.g., analyze_risk, calculate_greeks, compare_portfolios).
10 tools is well within the ideal 3-15 range, covering a comprehensive set of risk analysis capabilities without being excessive.
The tool set covers all major areas of quantitative risk analysis: basic risk metrics, options greeks, portfolio optimization, simulation, stress testing, performance attribution, correlation, sector exposure, and historical data.
Hosted MCP for stocks, options, Greeks, brokers, order previews, alerts, and workflows.
Portfolio and strategy stress diagnostics with hedge-break detection and regime outlook. Free tier.
Crypto portfolio risk analysis: VaR, scenarios, liquidity and correlation engines as MCP tools.
HPSILab Quant finance MCP for US stocks, ETFs, options, Monte Carlo, backtesting, and risk analysis.
