Skip to main content
Glama

Get portfolio analytics

get_portfolio_analytics
Read-only

Analyze portfolio risk, diversification, concentration, exposures, correlations, and stress scenarios, or test a candidate stock/ETF as a diversifier using a portfolio ID from list_portfolios.

Instructions

Analyze the signed-in user's portfolio risk, diversification, concentration or a candidate stock/ETF. Returns correlation/covariance, risk contributions, country/sector/currency exposures, proxy factors and stress scenarios. Use portfolioId from list_portfolios; use get_portfolio_context instead for holdings/value and matched/unmatched coverage. Set candidateTicker for correlation and pro-forma volatility; add includeLookThrough=true for direct/ETF underlying overlap in lookThroughFit with separate coverage/warnings. Look-through uses priced positions, independently of the risk-history subset; partial ETF snapshots give a lower bound. Risk math excludes holdings without sufficient price history and renormalizes over those analyzed: report the leading coverage banner and never imply whole-portfolio coverage when holdings were excluded. Requires OAuth read:portfolios and reads only the caller's data. privacyMode=weights_only hides absolute USD amounts; full is the default.

Input Schema

NameRequiredDescriptionDefault
daysNoCalendar-day lookback for daily USD return analytics. Default 370.
portfolioIdYesThe portfolio id, as returned by list_portfolios.
privacyModeNo"full" (default) includes absolute USD amounts; "weights_only" returns only relative figures.
candidateTickerNoOptional exact Bullrun stock or ETF listing ticker to test as a candidate diversifier, e.g. AAPL, BMW, ABBN, NESN or SPY. Use the stored listing ticker; do not infer exchange suffixes.
candidateWeightPctNoOptional hypothetical candidate allocation for pro-forma volatility. Default 5 (%).
includeLookThroughNoAlso compare an exact stock or ETF candidate against direct holdings and stored ETF constituents. Requires candidateTicker. Default false: no underlying holdings requests. Look-through has separate priced-position coverage from price-history risk analytics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.1
    • changedInput schema / properties / candidateTicker / description
      Previous value: -"Optional exact Bullrun ticker to test as a candidate diversifier - the native local-exchange symbol, e.g. AAPL, BMW, ABBN, NESN (not Yahoo-style suffixes like BMW.DE)."New value: +"Optional exact Bullrun stock or ETF listing ticker to test as a candidate diversifier, e.g. AAPL, BMW, ABBN, NESN or SPY. Use the stored listing ticker; do not infer exchange suffixes."
    • addedInput schema / properties / includeLookThrough
      Added value: +{
      +  "default": false,
      +  "description": "Also compare an exact stock or ETF candidate against direct holdings and stored ETF constituents. Requires candidateTicker. Default false: no underlying holdings requests. Look-through has separate priced-position coverage from price-history risk analytics.",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / candidateTicker / description
      Previous value: -"Optional exact Bullrun ticker to test as a candidate diversifier, e.g. AAPL, NESN.SW, BMW.DE."New value: +"Optional exact Bullrun ticker to test as a candidate diversifier - the native local-exchange symbol, e.g. AAPL, BMW, ABBN, NESN (not Yahoo-style suffixes like BMW.DE)."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/no-destructive, yet the description adds substantial context beyond them: OAuth scope read:portfolios, caller-scoped data only, exclusion of holdings without sufficient price history plus renormalization, look-through coverage computed independently from the risk-history subset, partial ETF snapshots yielding a lower bound, and a directive to surface the coverage banner. It also discloses the privacyMode effect on absolute USD amounts.

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

Conciseness4/5

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

Front-loaded with purpose and alternatives before diving into the coverage caveats, and every sentence carries actionable information. It is dense and reads as a long run-on chain, which slightly slows scanning for an agent parsing it quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter analytics tool with no output schema, the description covers auth, caller scoping, privacy modes, conditional parameters, output field naming (lookThroughFit), and the critical coverage-caveat behavior. An agent has everything needed to call it and to report results honestly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds semantic linkage the schema does not state: which parameters drive correlation/pro-forma volatility, that look-through results appear in lookThroughFit with separate coverage/warnings, and that look-through coverage is independent of the risk-history subset. Minor gap: it does not explain the days lookback window semantics beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and a concrete resource set (risk, diversification, concentration, candidate stock/ETF analytics) and enumerates the outputs (correlation/covariance, risk contributions, exposures, stress scenarios). It also explicitly names the sibling it is not (get_portfolio_context for holdings/value), so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use routing (portfolioId from list_portfolios, get_portfolio_context for holdings/value and coverage), conditional parameter guidance ('Set candidateTicker for correlation and pro-forma volatility', 'add includeLookThrough=true for direct/ETF underlying overlap'), and the prerequisite dependency (includeLookThrough requires candidateTicker). Nothing is left to inference.

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