Skip to main content
Glama
Sign In

Folionomiq

by com.folionomiq
OverviewDiscussionsAdmin

What it would take to lose that much

reverse_stress
Read-onlyIdempotent

Starts from a loss the reader names and finds the least extreme combination of market moves that would cause it on this portfolio, beside the worst each move actually did in the record; also each single company on its own. Typical questions: 'What would it take to lose 30%?'; 'A third of my portfolio is my employer's stock: what would a crash in it take from me?'; 'How bad would markets have to get for me to lose a quarter?'. Instead: for what past crises actually did, past_crises. No probability is computed: it says how large the moves would be, not how likely. It does not recommend, predict or calculate tax.

Input Schema

NameRequiredDescriptionDefault
baseNoCurrency code every figure is expressed in: USD, EUR, GBP, CAD… Default USD.
lossNoThe loss to explain, as a fraction: 0.25 = lose a quarter.
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.
lineNoOne sentence: what it would take.
movesNoPer market direction: label, plain wording, shock needed, sensitivity (beta), share of the loss, worst_seen in the record over the same number of days.
_fenceYesWhat these figures are and are not: descriptive, no forecast, no advice. Repeat its sense when presenting the result.
targetNoThe loss explained, as a negative fraction.
coverageNoShare of the portfolio's movement these directions explain.
window_endNoRecord end.
window_daysNoLength of the move considered, in trading days.
window_startNoRecord start.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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}."
  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?

The annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate those. It still adds useful scope limits beyond them: no probability is computed, and it does not recommend, predict, or calculate tax. That is valuable for a read-only analytics tool, though it does not say anything about output size or cost.

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 core behavior and the alternative appear first, and the example questions make the intent concrete. Some phrasing is dense ('beside the worst each move actually did in the record'), but no sentence is wasted and the negative scope statements earn their place.

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?

An output schema exists, so return values do not need explaining. For a three-parameter analytic tool, the description covers the intent, the alternative, and the exclusions. What is missing is minor: no note on how large the output is or limits on portfolio complexity.

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%, so the schema already defines base, loss, and the holdings object in detail, including units and ticker format. The description adds only mild framing ('a loss the reader names' and per-company output) beyond that. The baseline of 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?

The description names a specific operation on a specific object: it starts from a named loss and finds the least extreme combination of market moves that would cause it on this portfolio, alongside the worst each move actually did and each single company on its own. It is clearly separable from siblings, and it explicitly contrasts itself with past_crises.

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 gives concrete user questions that select this tool ('What would it take to lose 30%?', employer-stock crash, market decline), and it names the alternative for a different intent ('for what past crises actually did, past_crises'). The routing decision is explicit.

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

All Folionomiq toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources