Skip to main content
Glama

Analyse holdings

describe_holdings
Read-onlyIdempotent

Risk, diversification, fundamentals and outlook for holdings given in the conversation. Nothing is stored. sections narrows the answer; 'weights' adds the breakdown.

Each line is an ``asset_id`` (as find_assets, screen_equities and the solve tools
return it), else an isin, ticker or name, or a ``cash_currency`` for cash, sized by
one of ``weight``, ``units`` or ``market_value``. Amounts and units mix freely;
weights cannot mix with either. A name that matches nothing close to it is
listed as not included rather than replaced by another company, and a name
matched to a differently spelt instrument is listed for checking.

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": {
      "holdings": "<holdings>"
    },
    "name": "describe_holdings"
  }
}

Input Schema

NameRequiredDescriptionDefault
holdingsYes
sectionsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/non-destructive annotations, it explicitly states that nothing is stored and explains matching behavior: unmatched names are listed as not included rather than replaced, and differently spelt matches are flagged for checking. This is substantive behavioral context for an analysis tool.

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 front-loaded with the tool's purpose, then moves into input-line rules and matching caveats. It is dense but appropriately sized for a tool with a complex holdings array, and every sentence contributes useful information.

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 nested holdings input, a present output schema, and annotations covering safety, the description supplies the necessary input-format, sizing, sections and matching context. Nothing critical for correct invocation appears to be missing.

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?

With schema description coverage reported at 0%, the description carries the burden and does so well: it explains that each line may use asset_id, ISIN, ticker, name or cash_currency and must be sized by weight, units or market_value. It also states the key mixing rule: amounts and units may mix, but weights cannot mix with either.

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 purpose for an ad-hoc set of holdings, covering risk, diversification, fundamentals and outlook. The phrases 'given in the conversation' and 'Nothing is stored' distinguish it from stored-portfolio analysis tools such as the describe_portfolio_* siblings.

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?

It gives clear usage context for inline holdings and explains how 'sections' narrows the answer and how 'weights' adds the breakdown. It does not explicitly name alternative sibling tools or say when to prefer this over stored-portfolio analysis, but the intended context is clear.

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