Portfolio Analytics MCP

Overview Schema Source Related Servers Discussions Admin

analyze_portfolio_risk

Read-only

Calculate risk and return metrics for a multi-asset portfolio in one base currency, including volatility, drawdown, beta, and Sharpe ratio for holdings given by symbol or ISIN.

Instructions

Risk and return of a whole portfolio, measured in one base currency.

    Positions can be stocks or ETFs, given by Yahoo symbol or ISIN, sized
    by quantity (shares) or current value (in base currency); with
    neither, positions are equally weighted. Prices are converted to the
    base currency with daily FX (pence-quoted London listings handled),
    put on a common calendar, and analysed. Use analyze_portfolio
    (justETF) for cost and country/sector/stock look-through of ETFs.

    Example positions: [{"isin": "IE00B4L5Y983", "value": 30000},
    {"symbol": "ASML.AS", "quantity": 10}, {"symbol": "AAPL", "quantity": 25}]

    Args:
        positions: Up to 30 holdings: {symbol | isin, quantity | value}.
        base_currency: ISO code of the investor's currency. Default EUR.
        benchmark: Optional Yahoo symbol, e.g. "IWDA.AS" or "^GSPC".
        start_date: YYYY-MM-DD. Defaults to 3 years before end_date.
        end_date: YYYY-MM-DD (exclusive). Defaults to the latest data.
        interval: Return frequency. Default "1wk": daily returns across
            regions (US vs Europe) understate correlation and beta because
            the markets close hours apart.
        method: "current_holdings" (today's units held throughout) or
            "constant_weights" (rebalanced to today's weights each period).
        risk_free_rate_pct: Annual risk-free rate in %, e.g. 2.0.

    Returns:
        Total value and weights; portfolio return, volatility,
        Sharpe/Sortino/Calmar, max drawdown (dates); vs `benchmark` beta,
        alpha, tracking error, information ratio; per position return,
        volatility, beta and share of portfolio risk; correlation matrix;
        diversification ratio; how ISINs were resolved; FX rates used;
        warnings (short histories, stale quotes, bad Yahoo prices
        removed). Or an error dict.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "positions": "<positions>"
    },
    "name": "analyze_portfolio_risk"
  }
}

Input Schema

Name	Required	Default
`method`	No	current_holdings
`end_date`	No
`interval`	No	1wk
`benchmark`	No
`positions`	Yes
`start_date`	No
`base_currency`	No	EUR
`risk_free_rate_pct`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A5/5.0

Behavior5/5

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

The annotations already indicate a read-only, open-world operation, and the description adds substantial behavioral context: FX conversion, pence-quoted London handling, calendar alignment, warnings for stale or short histories, bad Yahoo prices removed, and ISIN resolution. Nothing contradicts readOnlyHint=true or openWorldHint=true.

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

Conciseness5/5

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

The description is long but justified by eight parameters, no output schema, and nontrivial financial processing. It is front-loaded with purpose and alternative, then structured into an example, Args, and Returns with no wasted sentences.

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?

With no output schema, the Returns section is necessary and detailed, covering metrics, benchmark comparison, per-position risk, correlation, FX rates, warnings, and error output. Combined with the usage and parameter notes, an agent has enough information to call and interpret the tool correctly.

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

Parameters5/5

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

Although top-level schema descriptions are absent, the Args section documents all eight parameters with meaning beyond the schema — position sizing fallback, base currency conversion, date defaults, interval rationale, and the two method modes. It fully compensates for the low schema description coverage.

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?

The description states a specific analytical resource — portfolio risk and return in one base currency — and distinguishes it from the sibling analyze_portfolio by naming the latter's ETF cost and look-through purpose. An agent can identify this as the portfolio risk/return tool without opening the 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?

It explicitly routes the agent to analyze_portfolio for ETF cost and country/sector/stock look-through, making the primary alternative and its selection condition clear. It also gives concrete position examples and default behaviors, so usage is not left to inference.

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