Explains the Bitcoin rainbow valuation chart and where price sits in the cycle today.
Scored across 5 tools
The five tools mostly map to distinct purposes: current position (rainbow_today), history (rainbow_history), cycle measures (cycle_check), explainer (explain_bitcoin), and simulator (simulate_dca). The main overlap is between cycle_check and rainbow_today, since both report a current position relative to long-term trend and both include a past-percentile count, but the descriptions differentiate them enough (multi-measure panel vs. single-band chart position) to keep selection clear.
All names are snake_case and readable, with a clear grouping: two rainbow_* resource-named tools plus three action verbs. The minor inconsistency is that cycle_check, rainbow_history, and rainbow_today are noun-first while explain_bitcoin and simulate_dca are verb-first, but the split aligns with 'report a view' vs. 'perform an action,' making the pattern defensible.
Five tools is well within the 3-15 sweet spot and each tool clearly earns its place: current view, historical view, cycle panel, explainer, and DCA simulator. The set is tightly scoped to the server's purpose with no filler and no obvious need for more tools.
The surface covers the obvious analytical needs: today's band position, band history, multi-measure cycle panel, plain-English explainer, and a DCA backtest. Minor gaps exist — no direct arbitrary-date price lookup or explicit cross-date comparison tool — but agents can work around these with the existing history and simulation tools.
A panel of five classic bitcoin cycle measures, each counted from the server's own price record and printed with its own number and the window behind it: the Pi Cycle Top pair (the 111-day average against the doubled 350-day average, the gap in percent, and the pair's past crossing dates in the record), the Mayer Multiple (today's price over the 200-day average, with the counted share of past days at or below today's), the distance from the 200-week average, the halving clock (days since the April 2024 halving, with the lengths of the three finished cycles), and the Ahr999 index with its formula in plain words. Each measure also prints the counted share of its own past readings at or below today's. It may add one labeled guest number, the Fear & Greed Index from Alternative.me, with its source and date; the guest feeds nothing else. There is no blended score: the panel closes with a count of how many of the five readings sit below the middle of their own past range. Call it when the user asks where bitcoin sits in its market cycle, or names one of these measures. Descriptive only: no verdict, no advice, no prediction.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses the data source, what each measure prints, the optional Fear & Greed guest input, and the absence of any blended score. It also states that the tool is descriptive only, with no verdict, advice, or prediction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every major element earns its place, especially because there is no output schema to explain the return shape. It is dense and contains minor repetition, such as restating that each measure prints its historical percentile, but it is not padded with irrelevant material.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is unusually complete: it names each measure, explains the calculation context, describes the guest field, and clarifies the output framing. An agent has enough information to select and correctly interpret the tool without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain. The baseline of 4 applies because the description does not need to compensate for any input schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource: a panel of five named bitcoin cycle measures computed from the server's price record. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings such as rainbow_today or rainbow_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger: call it when the user asks where bitcoin sits in its market cycle or names one of the listed measures. It does not name alternatives or state when not to use it, so routing guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool before explaining bitcoin in your own words. It returns the website's own plain-English explainer, and the price and rainbow topics print today's live Coinbase spot price with its UTC quote time — the rainbow topic also prints today's band — facts a from-memory answer cannot have. Use it whenever the user wants something about bitcoin explained, defined, or simplified — “explain…”, “ELI5”, “explain it like I'm five”, “what is…”, “what does … mean”, “in plain words”, “in plain English”, “for a beginner”, “I'm new to crypto”. If the user asks what the rainbow chart is, what its colors mean, or asks to have it explained simply, use topic 'rainbow'. Topic 'price': what price means, with the live price. Topic 'technical': what looking at the chart means, with the plain up-or-down move of the past year. Topic 'fundamental': what looking at the thing itself means, told as a health check. Topic 'ways_to_buy': the two plain ways people buy bitcoin, IBIT in a stock account or an exchange app, facts only. Descriptive only; no advice, no predictions.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which word to explain: 'price', 'technical', 'fundamental', 'rainbow', or 'ways_to_buy'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real context beyond that: price and rainbow topics inject a live Coinbase spot price with a UTC quote time, the technical topic includes the past year's up-or-down move, and output is explicitly descriptive with no advice or predictions. It does not say what happens if the live price fetch fails, so it stops at 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead sentence is well front-loaded with the call-before-explaining instruction, but the body is a single dense paragraph that mixes trigger phrases, topic semantics, and disclaimers. The long quoted list of user phrasings ('ELI5', 'in plain words', 'I'm new to crypto', etc.) is padded and could be condensed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single required enum parameter with 100% schema coverage, annotations, and no output schema, the definition covers purpose, topic selection, and the descriptive-only constraint. The one remaining gap is failure behavior for the live-price lookup on an open-world tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes well beyond the enum: it defines what each of the five topic values means and what it produces ('rainbow' = the chart and its colors, 'technical' = what looking at the chart means plus the past-year move, 'ways_to_buy' = IBIT in a stock account vs an exchange app). An agent can pick the right enum value without guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it returns the site's own plain-English explainer, and for some topics appends today's live Coinbase spot price with its UTC quote time. That distinguishes it from the sibling data tools (rainbow_today, rainbow_history, cycle_check, simulate_dca), which return numbers rather than explanations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Very explicit about when to call it ('Call this tool before explaining bitcoin in your own words', 'whenever the user wants something about bitcoin explained, defined, or simplified') and lists concrete trigger phrasings. It does not name an alternative tool or state a when-not-to-use condition, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts the rainbow chart's past, day by day, from the full price record since 2010: the highest band the price ever reached and the first date it reached it, the furthest the price ever sat above or below the trend line (in percent, with the date), how many of all priced days the price spent in each of the nine bands and outside the ladder (with the first and most recent dates in each and the longest unbroken run there), how long since the last close in the top and bottom bands, and today's counted position against that history (the share of all priced days that sat at or below where the price sits today against the line). Call it when the user asks about the chart's past: 'ever', 'has it ever', 'when was the last time', 'how long did it spend', the highest band ever. Counts of past days only: not odds, not a forecast, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower; the description nevertheless adds real behavioral context by defining the data window (2010 onward), the statistical nature of the output, and the 'counts of past days only, not a forecast' framing. It does not discuss cost, caching, or failure modes, but for a zero-argument read-only counter that is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core is front-loaded ('Counts the rainbow chart's past'), but almost the entire definition is a single ~130-word sentence dense with nested parentheticals listing return fields. It would be far more scannable as a short purpose line plus a bulleted list of computed statistics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the full burden of explaining return content, and it does so comprehensively: every statistic returned is named along with its unit (percent) and accompanying dates or runs. Nothing an agent needs to decide to call or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so there is no parameter meaning to convey; baseline for a no-param tool is 4. The description correctly implies the tool is parameterless by describing fully self-determined output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Counts the rainbow chart's past, day by day, from the full price record since 2010', and enumerates the exact statistics produced (highest band ever reached, largest deviation from the trend line, day counts per band, time since last top/bottom band close, today's percentile). An agent can separate this from rainbow_today (today's reading) and cycle_check 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the trigger phrases directly ('ever', 'has it ever', 'when was the last time', 'how long did it spend', the highest band ever) and states explicit exclusions: 'not odds, not a forecast, not advice'. The scope boundary 'Counts of past days only' further routes callers away from predictive siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where bitcoin's price sits on the rainbow chart right now: today's live price, the trend line value for today, the band name (Deep Blue up to Red, or below/above the ladder) and which of the nine bands it is (band 1 is the lowest), that band's dollar range for today, the distance from the line in percent, the counted share of all priced days spent in that band (a count of past days, not odds), a link to the rainbow chart picture drawn from the same live data, and the fit behind the line (its equation, the window of closes it was fit on, and its fit score), all in plain English. The line is a log regression through all daily closes since 2010. It prints the spot price with its UTC quote time (one shared quote per minute across the tools, so its numbers reconcile with simulate_dca's) and states the day the price history runs through: the history can end a few days before today while the price itself is live spot. Descriptive only: it reports the picture, it does not advise buying or selling and does not predict prices.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety bar is low; the description nonetheless adds substantive behavior: one shared quote per minute across tools so numbers reconcile, and the warning that the price history may end a few days before today even though the spot price is live. It also pre-empts a likely misreading by stating the band share is a count of past days, not odds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded and every clause carries information, but the first sentence is a single ~90-word run-on enumerating nine outputs, which makes it hard to scan. A bulleted or sentence-per-output structure would serve the agent better without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 must carry the return contract — and it does, naming every field, the definition of the regression line (log fit over all daily closes since 2010), the quote timestamp basis, and the data-freshness caveat. Nothing an agent needs to interpret the response is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters (empty schema, 100% coverage), so the baseline is 4; the description earns the extra point by fully specifying the returned fields instead, which is the only semantic surface left to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — where bitcoin's price sits on the rainbow chart right now — and then enumerates exactly what is returned (band name, band number, dollar range, distance from line, historical share, chart link, regression fit). It is clearly separable from rainbow_history (past) and simulate_dca (which it explicitly says its quote reconciles with).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'right now / today' framing implicitly routes the agent away from rainbow_history, and the closing sentence sets an explicit behavioral boundary: descriptive only, no buy/sell advice, no price prediction. It also flags a reconciliation relationship with simulate_dca. What is missing is an explicit statement of when to prefer this over rainbow_history or cycle_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | How many years back the buys run: 1, 3, or 5. Give this or a start date. | |
| amount | Yes | Dollars put in on each buy, e.g. 50. | |
| end_date | No | The last day of the buys, like 2024-03-01. Defaults to today. | |
| frequency | No | How often the buy lands: daily, weekly, or monthly. Defaults to weekly. | |
| start_date | No | The first day of the buys, like 2021-03-01. Give this instead of years for an exact span. | |
| fee_percentage | No | Optional 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cycle_checkexplain_bitcoinrainbow_historyrainbow_todaysimulate_dca
Add one secure layer between your agents and this server.