Skip to main content
Glama
JerBouma

Finance Toolkit

portfolio

Read-onlyIdempotent

Build and analyze a multi-ticker portfolio: compute optimal weights (minimum variance, maximum Sharpe, risk parity, Black-Litterman), risk contributions, stress tests, and Brinson attribution.

Instructions

Portfolio construction and analysis for the given tickers (at least two). Optimal weights: get_minimum_variance_weights, get_maximum_sharpe_weights, get_mean_variance_weights (target_return= or risk_aversion=), get_risk_parity_weights (risk_budget={'AAPL': 0.5, ...} optional), get_hierarchical_risk_parity_weights, get_inverse_volatility_weights, get_minimum_cvar_weights (confidence_level=) and get_black_litterman_weights (views={'AAPL': 0.10, 'AAPL-MSFT': 0.02}, optional view_confidences= and market_weights=; market capitalizations by default). Each returns per ticker and for the Portfolio the Weight, annualized Expected Return, Volatility, Sharpe Ratio and Risk Contribution. minimum_weight=/maximum_weight= bound the weights (a negative minimum allows shorting). get_efficient_frontier (points=) returns portfolios from the lowest risk to the highest return. For given weights (weights={'AAPL': 0.6, 'MSFT': 0.4}, equal weights when omitted): get_risk_contributions, get_stress_test (returns in the Dot-com Crash, Global Financial Crisis, Euro Area Debt Crisis, 2015-2016 and 2018 Q4 sell-offs, COVID-19 Crash and 2022 Rate Shock next to the benchmark, or scenarios={'name': ['start', 'end']}), get_look_through_exposure (by='sector'|'country'|'holdings', looks through ETFs to their holdings, with the benchmark's exposure next to it) and get_brinson_attribution (allocation, selection and interaction effects by sector against the benchmark over start_date/end_date). Expected returns are historical averages; period= sets the return frequency (daily by default). Weights, returns and volatilities are decimals.

Input Schema

NameRequiredDescriptionDefault
byNoWhat to look through to: "sector", "country" or "holdings".sector
tauNoThe uncertainty of the implied returns relative to the covariance matrix.
limitNoThe rows to return, like head and tail: 5 for the first five, -5 for the last five (the most recent of a time series). A table with its periods as columns (financial statements, ratios) keeps its first or last periods instead. For ETF holdings the largest (or, negative, the smallest) by weight, and for a list (e.g. news or a screener) its length.
viewsNoThe annualized views, absolute views as total returns.
periodNoObservation frequency, e.g. 'daily', 'weekly', 'monthly', 'quarterly', or 'annual' (supported values differ per method).daily
pointsNoThe number of portfolios on the frontier.
tickersNoComma-separated ticker symbols, e.g. 'AAPL,MSFT,GOOGL'.
weightsNoFor get_brinson_attribution: The weight per asset at the start of the date range. For get_look_through_exposure, get_risk_contributions, get_stress_test: The weight per asset.
end_dateNoEnd of the date range in YYYY-MM-DD format.2026-10-27
indicatorYesName of the specific metric to calculate, one of the listed values. Required — search_metrics finds the indicator (and its tool) for a metric by name.
quarterlyNoReturn quarterly data instead of annual when True.
scenariosNoCustom scenarios as {"name": ("start date", "end date")}.
start_dateNoStart of the date range in YYYY-MM-DD format.2021-10-28
risk_budgetNoThe share of the risk per asset, e.g. {"AAPL": 0.4, "MSFT": 0.2, ...}; it is scaled to sum to one.
show_columnsNoComma-separated names to filter the output. For historical data use the key names visible in any response record (e.g. 'Close,Volume,Return'). For financial statements use the 'metric' field values from the response (e.g. 'Revenue,Net Income,EBITDA'). Call the tool once without this parameter to see all available names, then repeat with show_columns to reduce response size and token usage.
risk_aversionNoFor get_black_litterman_weights: The risk aversion δ of the market. For get_mean_variance_weights: The investor's risk aversion λ; higher values give less risky portfolios.
target_returnNoThe annualized return the portfolio must expect, e.g. 0.12 for 12%.
linkage_methodNoThe linkage of the hierarchical clustering: "single", "complete", "average" or "ward".single
market_weightsNoThe market weight per asset.
maximum_weightNoThe highest weight an asset may have.
minimum_weightNoFor get_black_litterman_weights, get_efficient_frontier, get_mean_variance_weights, get_minimum_cvar_weights: The lowest weight an asset may have. For get_maximum_sharpe_weights, get_minimum_variance_weights: The lowest weight an asset may have; a negative value allows short positions.
benchmark_tickerNoTicker used as the market benchmark, e.g. 'SPY' or '^GSPC'.SPY
confidence_levelNoThe confidence level of the CVaR, e.g. 0.95 for the average of the worst 5% of periods.
view_confidencesNoThe confidence per view, between 0 and 1.
include_benchmarkNoWhether to include the benchmark as an asset.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety behavior is covered. The description adds useful context: output metrics, historical-average expected returns, decimal conventions, weight bounds and shorting, risk-budget scaling, and benchmark behavior.

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?

The description is long but appropriately dense for a 25-parameter, 13-indicator tool, and it is front-loaded with the core purpose. Structure is a single dense paragraph, so readability could be improved, but there is little wasted content.

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?

Given the rich input schema, output schema and annotations, the description covers all indicator names, the main groupings, key parameter usage, return fields and unit conventions. Remaining parameter details such as tau, linkage_method and show_columns are fully documented in the schema.

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 the schema already carries baseline parameter meaning. The description adds method-specific applicability and examples for weights=, risk_budget=, views=, scenarios=, points=, period=, minimum_weight= and maximum_weight=.

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?

States a specific verb and resource: portfolio construction and analysis for given tickers. It then enumerates all supported indicators and analyses, making clear this is the holistic portfolio tool rather than a sibling category like volatility or risk.

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

Usage Guidelines4/5

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

Groups the indicators into optimal-weight methods versus given-weight analyses, and ties parameters like target_return=, risk_aversion= and confidence_level= to specific indicators. It does not explicitly explain how to choose between competing weighting schemes or when to use this instead of sibling tools.

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