Skip to main content
Glama

The Bitcoin Rainbow

What a steady buy would have done

simulate_dca
Read-onlyIdempotent

Replays a steady bitcoin buy on the real price history (daily closes — blockchain.info through Oct 29, 2026, then Coinbase — valued at the live Coinbase spot price). DCA means dollar-cost averaging: putting in the same amount on a set rhythm, no matter the price. Give an amount per buy in dollars and a rhythm (daily, weekly, or monthly), then either a span of 1, 3, or 5 years or an exact start date (an end date is optional; dates win if both are given); it returns how much would have gone in, how much bitcoin it would have bought, what that would be worth today, and the gain or loss against what went in, in dollars and percent. It also states how many buys there were, the first and last buy dates, the weekday the weekly buys land on, the average cost per bitcoin, and the day the price history ends (a buy scheduled after that day is priced at the last close). An optional fee_percentage takes that percent out of each buy before it buys; by default no fees are counted, and the answer says which. Today's value prints the shared spot quote with its UTC time, the same quote rainbow_today prints, so the two answers reconcile; two checks more than a minute apart can still differ a little. Shows the past only: it is not a prediction, not a promise, and not advice to buy.

Input Schema

NameRequiredDescriptionDefault
yearsNoHow many years back the buys run: 1, 3, or 5. Give this or a start date.
amountYesDollars put in on each buy, e.g. 50.
end_dateNoThe last day of the buys, like 2024-03-01. Defaults to today.
frequencyNoHow often the buy lands: daily, weekly, or monthly. Defaults to weekly.
start_dateNoThe first day of the buys, like 2021-03-01. Give this instead of years for an exact span.
fee_percentageNoOptional fee taken out of each buy, in percent, e.g. 1 means 1% of each buy never reaches bitcoin. Defaults to 0, which counts no fees.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses data provenance (blockchain.info daily closes through Oct 29, 2026, then Coinbase), that valuation uses live Coinbase spot, how fees are applied and defaulted, that buys past the history end are priced at the last close, and that two spot checks more than a minute apart can differ. That is rich behavioral context an agent could not infer from annotations.

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 call shape (amount + rhythm + span/start) is front-loaded and every sentence carries operational information. It runs long as a single paragraph, and the price-source and disclaimer sentences could be tightened, but none are padding.

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?

There is no output schema, so the description carries the full burden of describing returns, and it enumerates them: total invested, bitcoin bought, today's value, dollar and percent gain/loss, buy count, first/last buy dates, weekly weekday, average cost per bitcoin, and the history end date. Nothing material for a correct call is missing.

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 most parameter meaning already lives in the schema; the baseline would be 3. The description adds genuinely new semantics on top: the precedence rule that an explicit start date wins over years when both are given, and that fee_percentage is deducted from each buy before the purchase rather than from the final value.

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?

"Replays a steady bitcoin buy on the real price history" states a specific verb and resource, and the paragraph immediately names the mechanics (amount, rhythm, span) and the siblings it reconciles with (rainbow_today). An agent can tell this apart from rainbow_history or cycle_check without opening the schema.

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 invocation context: supply an amount and a frequency, then either years or a start date, with an optional end date. It also bounds scope explicitly ("Shows the past only: it is not a prediction ... not advice") and notes the shared spot quote reconciles with rainbow_today. It stops short of saying when to prefer this over cycle_check or rainbow_history, so it lacks full sibling routing.

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