Skip to main content
Glama

The findings in plain words

plain_findings
Read-onlyIdempotent

Three or four plain sentences about one portfolio, how its risk is built and its worst historical fall, each with its window. Typical questions: 'Explain my portfolio simply.'; 'In plain words, what should I know?'; 'I'm new to investing: what does this portfolio look like?'. Instead: for the figures in full, measure_portfolio. For a quotable numbered report, portfolio_report. It does not recommend, predict or calculate tax.

Input Schema

NameRequiredDescriptionDefault
baseNoCurrency code every figure is expressed in: USD, EUR, GBP, CAD… Default USD.
unitsNoWhat the holdings' numbers are: 'money' (amounts in the base currency) or 'weights' (percentages or fractions). Omitted: holdings adding up to 1 or 100 are read as percentages, anything else as money, and the answer says so.
holdingsYesWhat is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): `units` says which; without it, holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {"VTI": 60, "VXUS": 20, "BND": 20}.

Output Schema

NameRequiredDescriptionDefault
dataNoWhere the prices came from and what was missing or repaired.
_fenceYesWhat these figures are and are not: descriptive, no forecast, no advice. Repeat its sense when presenting the result.
insightsNoPer finding: key, title, detail, severity (info or warning), evidence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / holdings / description
      Previous value: -"What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {\"VTI\": 60, \"VXUS\": 20, \"BND\": 20}."New value: +"What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): `units` says which; without it, holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {\"VTI\": 60, \"VXUS\": 20, \"BND\": 20}."
    • addedInput schema / properties / units
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "money",
      +        "weights"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "What the holdings' numbers are: 'money' (amounts in the base currency) or 'weights' (percentages or fractions). Omitted: holdings adding up to 1 or 100 are read as percentages, anything else as money, and the answer says so.",
      +  "title": "Units"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / base / description
      Previous value: -"Currency every figure is expressed in (USD, EUR, GBP, CAD…). Default USD."New value: +"Currency code every figure is expressed in: USD, EUR, GBP, CAD… Default USD."
    • changedInput schema / properties / holdings / description
      Previous value: -"What is held: {ticker: weight or amount}. Weights need not sum to one; amounts in the base currency are also accepted (then the crises are shown in money). 1 to 100 holdings. Tickers as the exchange lists them (VOO, VWCE.DE, XAW.TO; 'CASH.USD' for cash)."New value: +"What is held: {ticker: number}, 1 to 100 holdings. Weights in any scale (60/20/20 or 0.6/0.2/0.2) or money amounts in the base currency (60000/20000/20000): holdings adding up to 1 or 100 are read as percentages, anything else as money, which makes the falls come out in money. Tickers as the exchange lists them (VOO, VWCE.DE, EQQQ.DE, XAW.TO; 'CASH.USD' for cash). Example: {\"VTI\": 60, \"VXUS\": 20, \"BND\": 20}."
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavior context the annotations don't: output length (three or four sentences), that every figure carries its measurement window, and that advice/prediction/tax calculation are out of scope. It stops short of saying how invalid or unknown tickers are handled, which matters for a tool that takes free-form tickers.

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 the output shape, then example questions, then sibling routing, then exclusions — a sensible order with no filler. It is slightly long-winded and the awkward line breaks make it read as one run-on block, but every clause carries information.

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?

With an output schema, rich annotations, and fully described parameters, the description only needs to say what the tool is for and when to prefer it — which it does. Minor gap: nothing about failure behavior for unrecognized tickers or about how expensive/long the call is, which is the one thing left for an agent to guess.

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

Parameters3/5

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

Schema description coverage is 100% and the holdings property is documented in depth (scales, ticker conventions, CASH.USD, example object), so the schema carries parameter meaning. The description only implies the single-portfolio scope and adds nothing on base/units handling or the 1–100 holding limit. Baseline 3 is appropriate.

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 exactly what the tool produces (three or four plain sentences about one portfolio's risk construction and worst historical fall, each with its window), which is a specific verb+resource+output shape. It explicitly names the two sibling tools that do something else (measure_portfolio, portfolio_report), so an agent can pick it without opening any 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 concrete triggering questions ('Explain my portfolio simply', 'I'm new to investing...') plus explicit routing to alternatives for the figures-in-full and numbered-report cases. It also adds a negative boundary: it does not recommend, predict or calculate tax.

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