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, the description fails to disclose behavioral traits such as data fetching, rate limits, or side effects; it only lists metrics without describing what the tool actually does beyond calculation.
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 is efficient, but could be structured with bullet points for better readability.
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 description lacks detail on return values or overall behavior; given the complexity and absence of output schema, more context about what the tool returns is needed.
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?
The input schema provides thorough descriptions for all 6 parameters, so the description adds no additional meaning; 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 explicitly states the tool calculates core risk metrics (VaR, CVaR, volatility, beta, max drawdown) for a portfolio, which is specific and sets it apart from siblings like stress_test or monte_carlo_simulation.
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; no prerequisites, exclusions, or context about when the tool is appropriate is provided.
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?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It explains the models used but does not disclose error handling, rate limits, or what happens if implied_volatility and market_price are both omitted (the schema implies one is needed but description doesn't clarify). The 'Paid tier only' is helpful but more details would improve transparency.
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, concise and to the point. The first sentence states the core function, the second adds model and tier info. It could be slightly improved by front-loading the paid tier note, but overall it's efficient and readable.
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 (multiple Greeks, both European and American, array input), the description is fairly complete but lacks details on output format (no output schema). It also doesn't explicitly state the dependency between implied_volatility and market_price. These gaps leave some uncertainty for the 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 the schema already documents all parameters well. The description adds minimal new semantics (e.g., model assignment for style, paid tier constraint). It does not repeat parameter details but doesn't significantly enhance understanding 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 the tool calculates option Greeks (delta, gamma, theta, vega, rho) for individual options or portfolios, using Black-Scholes for European and binomial for American styles. The 'Paid tier only' note adds a usage constraint, and the tool is well-differentiated from siblings like analyze_risk and monte_carlo_simulation.
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', which is a clear usage condition. It does not explicitly state when to use this tool versus alternatives, but the sibling tools cover different purposes (risk, optimization, etc.), so the context is clear enough for an agent.
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?
With no annotations, description should disclose behavioral traits (e.g., idempotency, auth requirements) but only notes 'Paid tier only.' Does not explain non-obvious behaviors like whether it modifies data or has rate limits.
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?
Single, clear sentence front-loaded with action and scope, plus a brief access note. No redundant or filler 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?
Absence of output schema and lack of description about return format or example results leaves agents uncertain about tool's output. Given complexity (risk/return metrics), more context is needed for complete understanding.
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 descriptions exist for all parameters. Description adds no extra meaning beyond what parameters already convey; 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 explicitly states the tool compares portfolio allocations head-to-head across risk and return metrics, distinguishing it from sibling tools that analyze single portfolios or perform other functions.
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 like analyze_risk or optimize_portfolio. Only mentions paid tier, leaving agents without decision criteria.
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 must fully disclose behavioral traits. However, it only states the computation and identification of pairs, without mentioning read-only nature, computational cost, data requirements, or output specifics. The agent lacks insight into side effects or required permissions.
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 with no extraneous information. It front-loads the core action and purpose, making it highly scannable for an AI agent.
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?
While the description explains what the tool does, it does not mention output format or additional context like return structure (e.g., matrix with tickers and correlation values). Given the absence of an output schema, the agent may be uncertain about the result. More details on the output would improve 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 description coverage is 100%, with each parameter having detailed descriptions (e.g., ticker constraints, lookback_days range, method enum meanings). The tool description adds no additional parameter semantics beyond the schema, so baseline score of 3 applies.
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 computes a pairwise correlation matrix for assets and identifies correlated pairs and diversification opportunities. This is a specific verb+resource that distinguishes it from siblings like 'analyze_risk' or 'optimize_portfolio'.
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 is provided on when to use this tool versus alternatives. It does not mention preconditions, exclusion criteria, or refer to other tools. The description implies usage for correlation analysis but lacks explicit when-to-use or when-not-to-use context.
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?
The description explains the output (distribution, percentiles, loss probability) but does not disclose whether the tool is read-only, modifies any data, or has authentication requirements. No annotations are provided, so the description carries the full burden; it partially meets it.
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 is easy to parse. It is brief but covers the core functionality. Slightly more structure (e.g., bullet points for key features) could improve usability, but it is already concise.
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 of Monte Carlo simulation and the absence of an output schema, the description provides a high-level overview but lacks details on return format, interpretation, or limitations (e.g., free tier restrictions are in the schema but not in the description). It is adequate but not fully complete.
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 all parameters have descriptions in the schema. The description itself does not add new meaning beyond the schema. A 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 it runs a Monte Carlo simulation on a portfolio to model the distribution of future returns, including percentile outcomes and probability of loss. This distinguishes it from sibling tools like stress_test (scenario-based) or analyze_risk (general risk assessment).
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 such as stress_test or analyze_risk. There is no mention of prerequisites or context where this tool is preferable.
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?
No annotations are provided, so the description bears full responsibility. It only mentions the method and paid tier, but does not disclose side effects, data requirements (beyond tickers), error conditions, or any other behavioral traits. Given the tool's complexity, this is a significant gap.
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 concise and front-loaded, three short sentences that quickly convey the core purpose and key constraints. It could be slightly more structured, but it is efficient and avoids unnecessary 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 description lacks crucial information about what the tool returns (output schema is absent). For a complex optimization tool with 6 parameters and nested objects, this is a notable omission. The description should at least mention that it returns optimal weights and associated metrics.
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 detailed parameter descriptions. The tool description adds no additional meaning beyond what the schema already provides, so a 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 action (find optimal portfolio allocation), method (mean-variance optimization), and supported objectives (max Sharpe, min variance, target return). It also distinguishes itself by mentioning 'Paid tier only', which differentiates it from potential free alternatives among 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 provides clear context for when to use the tool, including the paid tier restriction and supported objectives. However, it does not explicitly compare with siblings like 'monte_carlo_simulation' or 'analyze_risk', leaving some ambiguity about when to prefer this tool over alternatives.
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 provided, so description should disclose behavioral traits. It mentions tier limitations but not auth needs, mutability, rate limits, or side effects. The output format is not described.
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 core purpose, then specific ratios. No fluff. Every sentence adds value.
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 4 parameters and no output schema, description should explain expected outputs and behavioral scope. It does not cover return values, factor methodology, or what 'full factor attribution' entails. Leaves significant gaps for agent 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 coverage is 100%, so baseline is 3. Description adds minor context (e.g., free/paid limits on positions) but largely restates what schema descriptions already provide. No new semantics beyond 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 performance into factors, sectors, and contributions, and lists specific ratios. It differentiates itself from generic analysis tools but doesn't explicitly contrast with siblings like 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?
No guidance on when to use this tool versus siblings. Does not mention prerequisites, when not to use, or alternatives. The tier limitation is noted but not in the context of decision-making.
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 provided, so description carries full burden. Discloses tier limits (free/paid) but omits other behavioral traits like rate limits, authentication, or error handling. 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?
Two sentences are concise and front-loaded: first sentence states core action, second adds tier details. No wasted words, though structuring could be improved.
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?
Covers tier limits and basic functionality, but lacks output structure description (OHLCV columns, ordering) and error handling. Adequate but leaves gaps given no output schema.
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% with clear parameter descriptions. The tool description adds overall tier context but does not enhance per-parameter semantics beyond what the schema already provides.
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 action 'fetch', resource 'historical OHLCV price data', and scope 'one or more tickers' with tier limits. This distinguishes from sibling analysis/portfolio tools.
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?
Mentions free vs paid tier limits, providing context on constraints, but does not explicitly compare to sibling tools or specify when to use this tool over alternatives.
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?
With no annotations, the description bears full responsibility. It clearly states the tool returns concentration metrics including HHI and breaks down by multiple dimensions. It does not mention any destructive actions or permissions needed, but since the tool is likely a read-only analysis, the transparency is adequate.
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 redundant words. The first sentence front-loads the primary purpose; the second adds key output metrics. Every word contributes meaning.
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 single parameter and no output schema, the description effectively communicates what the tool does and returns. It could mention practical constraints like portfolio size limits or data refresh requirements, but overall it is sufficiently complete for an agent to understand when to invoke it.
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 fully describes the positions parameter. The description adds context about the output (sector weights, market cap breakdown, HHI) but does not clarify parameter semantics beyond what the schema provides.
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 ('Break down') and clearly states the resource ('portfolio exposure') and dimensions (GICS sector, market cap, asset class). It distinguishes from siblings by specifying sector-specific analysis and concentration metrics like HHI, which is unique among the listed sibling tools.
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 analyzing portfolio sector composition but does not provide explicit guidance on when to use this tool versus alternatives like analyze_risk or performance_attribution. No exclusions or contextual notes are given.
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?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions tier limitations but lacks details on side effects, authentication requirements, or output format. The schema constraints (e.g., minItems, maxItems) are not reiterated in the description, though they are covered in the 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 sentence that efficiently conveys the core functionality and tier distinction. It is front-loaded and contains no superfluous information, earning 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 that the tool has three parameters (one required) and no output schema, the description covers the main inputs but omits details about return values, idempotency, or error handling. For a stress-testing tool, additional context on how results are returned would enhance 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?
The input schema has 100% description coverage, but the description adds valuable context beyond the schema, particularly regarding tier-based limits (e.g., 'Free tier: max 20 positions and historical scenarios only'). This enhances understanding of parameter 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's purpose: stress testing a portfolio against historical crisis scenarios or custom shocks. It uses specific verbs ('stress test') and resources ('portfolio'), and the mention of specific crisis names distinguishes it from sibling tools like 'analyze_risk' or 'monte_carlo_simulation'.
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 usage context by differentiating between free and paid tiers ('or custom shocks (paid tier)'), hinting at when to use the full feature set. However, it does not explicitly compare this tool to siblings or state when not to use it, leaving room for ambiguity.
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. Dates show when Glama detected each change.
v1.0.0analyze_riskcalculate_greekscompare_portfolioscorrelation_matrixmonte_carlo_simulationoptimize_portfolioperformance_attributionprice_historysector_exposurestress_testEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/78degrees/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
