Folionomiq

Living off it: withdrawals replayed

living_off_it

Read-onlyIdempotent

Replays a yearly withdrawal, raised with real inflation, from every start month the portfolio's history allows: how many starts lasted the full span, how many ran out and when, the lowest point from the worst start, and the highest yearly rate that ran out from no start. Use it for 'can I live off this?'; for money put in every month instead, monthly_plan. amount is the portfolio's value (defaults to the sum of the holdings), withdrawal the yearly amount in today's money, years the span (5 to 50, default 30). A count of starts, never a probability; a span the record is too short for is said, not invented.

Input Schema

TableJSON Schema

Name	Required	Description
`base`	No	Currency every figure is expressed in (USD, EUR, GBP, CAD…). Default USD.
`years`	No	How many years, 5 to 50.
`amount`	No	How much is in the portfolio, when `holdings` are weights rather than money.
`holdings`	Yes	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).
`withdrawal`	Yes	Taken each year, in today's money; raised with the real price index of the base currency.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No	Where the prices came from and what was missing or repaired.
`rate`	No	withdrawal / amount.
`worst`	No	The worst start: start, ran_out, months, low_real, low_at, end_real.
`years`	No	Span asked for.
`_fence`	Yes	What these figures are and are not: descriptive, no forecast, no advice. Repeat its sense when presenting the result.
`amount`	No	Money in the portfolio at each start.
`record`	No	start, end and years of the shared monthly record.
`starts`	No	A sample of starts (every sixth): start, complete, months, ran_out, low_real, end_real.
`n_going`	No	Recent starts not run out so far, span not over.
`n_starts`	No	Starts followed (at least a year).
`inflation`	No	Price index used: source, last_published, assumed.
`n_ran_out`	No	Starts, complete or not, where the money ran out.
`safe_rate`	No	Highest yearly rate that ran out from no start; null if no start is complete.
`n_complete`	No	Starts old enough for the full span.
`withdrawal`	No	Taken each year, in start-month money, raised with prices.
`testable_years`	No	The longest span the record can test in full.
`n_complete_lasted`	No	Of those, how many lasted.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 25, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the result is 'a count of starts, never a probability' and 'a span the record is too short for is said, not invented' — both important framing for interpreting output, though it does not discuss performance or pagination.

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 and every sentence carries information, but the opening sentence is a long, comma-heavy enumeration and the parameter notes are packed into the same paragraph rather than separated. Dense and useful, slightly heavy to parse.

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 present, return values needn't be explained, and the description still covers scope, defaults, units, the sibling alternative, and the counts-not-probabilities caveat. Complete enough for a 5-parameter analytic tool, though nothing is said about the base-currency interaction or runtime cost.

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 100%, so baseline is 3, but the description adds meaning the schema lacks: amount 'defaults to the sum of the holdings', withdrawal is 'the yearly amount in today's money', and years' 5–50 range with default 30 is restated inline. That clarifies the weights-vs-money distinction the schema only hints at.

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 a specific verb and resource — replaying a yearly, inflation-raised withdrawal from every start month the history allows — and enumerates the four outputs (starts that lasted, starts that ran out and when, lowest point from worst start, highest failing rate). An agent can distinguish it from monthly_plan and past_crises without opening a 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 an explicit use case ('can I live off this?') and routes to the right alternative by condition: 'for money put in every month instead, monthly_plan.' That is the sibling-routing pattern that makes selection unambiguous.

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

All Folionomiq tools Inspect

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

Need Help?