Portfolio risk analytics — VaR, Monte Carlo, optimization, options Greeks, stress testing.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 10 of 10 tools scored.
Each tool has a distinct purpose (e.g., risk metrics, Greeks, portfolio optimization, simulation), with no overlap or ambiguity. The descriptions clearly separate core risk analysis from advanced features.
All tool names follow a consistent snake_case verb_noun pattern (e.g., analyze_risk, calculate_greeks), making them predictable and easy to distinguish.
With 10 tools, the server covers a comprehensive range of quantitative risk analytics without being bloated. Each tool serves a clear, non-redundant purpose within risk management.
The tool set covers essential risk analysis (VaR, Greeks, optimization, stress tests, attribution) but is missing common features like scenario analysis beyond historical crises or backtesting. Still, it is well above average.
analyze_riskBInspectCalculate core risk metrics for a portfolio — Value at Risk (VaR), Conditional VaR (CVaR), volatility, beta, and max drawdown.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| positions | Yes | Array of portfolio positions. Each entry needs a ticker and quantity. Free tier: max 20 positions. Paid tier: up to 500. | |
| horizon_days | No | Risk horizon in trading days. 1 = overnight, 21 ≈ 1 month, 252 ≈ 1 year. Default: 1. | |
| lookback_days | No | Number of historical trading days to use. 252 ≈ 1 year, 756 ≈ 3 years. 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 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_greeksAInspectCalculate 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_portfoliosBInspectCompare 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.
correlation_matrixAInspectCompute the pairwise correlation matrix for a set of assets. Identifies highly correlated pairs and diversification opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Correlation method. "pearson" = linear correlation (standard), "spearman" = rank-based (robust to outliers), "kendall" = concordance-based. Default: "pearson". | pearson |
| 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. |
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.
monte_carlo_simulationAInspectRun Monte Carlo simulation on a portfolio to model the distribution of future returns, including percentile outcomes and probability of loss.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed for reproducible results. Omit for a fresh random run each time. | |
| model | No | Stochastic process model. "gbm" = Geometric Brownian Motion (standard), "jump_diffusion" = adds jump risk for fat-tail scenarios. Default: "gbm". | gbm |
| 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. | |
| positions | Yes | Array of portfolio positions. Free tier: max 20 positions. Paid tier: up to 500. | |
| horizon_days | No | Simulation horizon in trading days. 21 ≈ 1 month, 63 ≈ 1 quarter, 252 ≈ 1 year. Default: 21. | |
| lookback_days | No | Historical window used to estimate drift and volatility parameters. Range: 30-1260 trading days. 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 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.
optimize_portfolioAInspectFind 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 |
| constraints | No | Optional weight constraints. See ConstraintsInput for details. | |
| lookback_days | No | Historical window for estimating return and covariance. 252 = 1 year, 756 = 3 years, 1260 = 5 years. Range: 252-1260. Default: 756. | |
| target_return | No | Required when objective is "target_return". Annualized return as a decimal, e.g. 0.12 = 12% annual return target. | |
| risk_free_rate | No | Annualized risk-free rate as a decimal, e.g. 0.05 = 5%. Used in Sharpe ratio calculation. Default: 0.05. |
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.
performance_attributionBInspectBreak down portfolio performance into factor exposures, sector allocation, and position contributions. Computes Sharpe, Sortino, Treynor, Calmar, and Information ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| benchmark | No | Benchmark ticker for relative performance metrics (Information Ratio, Tracking Error, Beta). Default: SPY. | SPY |
| 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. | |
| 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.
price_historyAInspectFetch 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 |
|---|---|---|---|
| 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. | |
| tickers | Yes | Ticker symbols to fetch price history for. Free tier: max 1 ticker. Paid tier: up to 20 tickers. | |
| 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.
sector_exposureAInspectBreak 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_testBInspectStress 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.