Skip to main content
Glama

Summarise track record

describe_portfolio_series
Read-onlyIdempotent

Summary statistics of a backtested strategy's track record, or an account's history.

A read: computes and writes nothing. Returns the summary statistics; the curve is
drawn by the card where the host renders one. ``series_in_context=True`` returns
every daily point, for questions about the curve's shape (peaks, time under water).

``contributions_by`` returns instead what each holding or group added to the
return between ``from_date`` and ``to_date`` (ISO dates; default the last year),
largest first. Contributions add up to the window's return. A fund counts as one
holding: its past holdings are not known, so it is not split by country, sector
or industry.

For a strategy it also gives the one-way turnover over the last year's worth of
rebalances and the dividend yield, gross: the track record deducts no trading
cost or withholding tax, and these are the inputs for estimating both.

For an account it is the account's own history. A strategy with no track record
yet is refused; ``run_strategy_backtest`` or a build with ``backtest=True``
creates one.

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": {
      "strategy_id": "<strategy_id>"
    },
    "name": "describe_portfolio_series"
  }
}

Input Schema

NameRequiredDescriptionDefault
to_dateNo
from_dateNo
strategy_idYes
contributions_byNo
series_in_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations: states that contributions sum to the window's return, that a fund is not split by country/sector/industry because its past holdings are unknown, that turnover is one-way over the last year's rebalances, and that dividend yield is gross with no trading costs or withholding tax deducted. It also discloses the refusal condition when a strategy has no track record and names the remedy.

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?

Purpose is front-loaded in sentence one and each paragraph maps to a mode, so navigation is good. It is on the long side and sentences like the turnover/dividend-yield one are dense, but no line is purely filler.

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

Completeness4/5

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

Without an output schema the description must imply the return shape, and it does for the three modes plus the card-rendering caveat. The notable omission is which summary statistics are actually returned (Sharpe, CAGR, volatility, drawdown?) and how strategy vs account is selected from a single strategy_id.

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 description coverage is 0%, so the description carries the burden and mostly delivers: from_date/to_date are ISO dates defaulting to the last year, contributions_by returns per-holding/group additions sorted largest first, and series_in_context returns every daily point. Gaps remain: strategy_id is never explained and the ContributionLevel enum values (asset_class, country, sector, industry) are only gestured at as 'group'.

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

Purpose4/5

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

The first sentence names the specific resource (a backtested strategy's track record or an account's history) and the operation (summary statistics), and later sentences carve out the two alternative modes (series_in_context, contributions_by). It never names a sibling tool to contrast with (e.g. describe_portfolio_risk, describe_holdings), so the differentiation is by mode rather than by routing.

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?

Gives concrete use conditions: series_in_context=True 'for questions about the curve's shape (peaks, time under water)' and contributions_by for attribution between from_date and to_date. It also routes the failure case explicitly to run_strategy_backtest or a build with backtest=True. No explicit exclusions against neighbouring describe_* tools, so short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources