Skip to main content
Glama
Sign In

Folionomiq

by com.folionomiq
OverviewDiscussionsAdmin

Money in every month, replayed

monthly_plan
Read-onlyIdempotent

The same amount bought on the first trading day of each month, replayed on a portfolio's own history with dividends reinvested: what it became against what was put in, the deepest point below the money put in, and the same plan from every possible starting January. Typical questions: 'If I put $500 a month into these, what would it have become?'; 'Dollar-cost averaging into VTI since 2007?'; 'Monthly investing: what was the hardest stretch?'. Instead: for withdrawals, living_off_it. For the record itself, return_history. Before taxes and fees. It does not recommend, predict or calculate tax.

Input Schema

NameRequiredDescriptionDefault
baseNoCurrency code every figure is expressed in: USD, EUR, GBP, CAD… Default USD.
startNoThe year whose January the plan starts in; the record's first whole January when absent.
monthlyYesAmount bought every month, in the base currency.
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
runNoThe plan from `start`: start (first buying day), year, months, put, value, worst_day, worst_value, worst_put, gap (how far below the money put in at its hardest moment), under_months (longest stretch below it, at month ends), brief_dip, under_from, under_to.
baseNoCurrency of every figure.
dataNoWhere the prices came from and what was missing or repaired.
kindNoreplayed.
startNoThe year whose January the plan started in.
_fenceYesWhat these figures are and are not: descriptive, no forecast, no advice. Repeat its sense when presenting the result.
amountNoBought every month, in the base currency.
recordNostart, end: the shared daily record replayed.
startsNoThe same plan from every January in `start_years`, in order; each as `run`.
limitationsNoWhat the figures leave out, in words.
start_yearsNoEvery January the record allows as a 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.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful model assumptions the agent would otherwise guess: dividends reinvested, purchases on the first trading day, results before taxes and fees, and no recommendation/prediction/tax computation. It stops short of disclosing data frequency or how the 'deepest point below' is measured, so not a full 5.

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 action leads, followed by the reported quantities, example questions, and exclusion routing — a sensible front-load. Some phrasing is stylized ('what it became against what was put in') and the three sample questions are slightly redundant, but nothing is padded enough to waste an agent's attention.

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?

For a 4-parameter tool with nested holdings and an output schema, the description covers what is computed, the reinvestment/timeframe assumptions, tax and fee scope, and the sibling to use instead. Return-value explanation is rightly omitted because an output schema exists.

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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: the monthly amount is bought on the first trading day, and the start year defines a January with the plan also replayed from every possible starting January (a rolling-window behavior not evident from 'the year whose January the plan starts in'). The dollar examples reinforce the monthly parameter's scale.

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 computation: a fixed monthly purchase on the first trading day of each month, replayed on the portfolio's own history with dividends reinvested, reporting final value vs. contributions, the deepest underwater point, and rolling January-start replays. This is a precise verb+resource definition that an agent can separate from siblings like return_history or compare_portfolios 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 concrete triggering questions ('If I put $500 a month into these...', 'Dollar-cost averaging into VTI since 2007?') so an agent can pattern-match a user's ask. It also names explicit negatives and alternatives: living_off_it for withdrawals, return_history for the raw record.

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