Regime

Best days check

best_days_check

Read-onlyIdempotent

The 'miss the ten best days and you get nothing' claim, measured on both sides. The same window of a coin lived four ways: all of it, without its N best days, without its N worst days, and without either, from every start day of the history. You also get how many of those best days landed within a week of a worst one, which is what decides whether the claim means anything. Backtest on spot daily candles, dead coins included.

Use when someone argues for staying invested because missing the best days ruins returns, or for timing the market to dodge the worst ones. Which weekday or month does best is calendar_check.

Input Schema

Name	Required	Description
`coin`	Yes	Ticker or full pair. An unknown one comes back with the list we hold and the ones left out.
`days`	Yes	Window in days: 90, 365 or 730.
`best_days`	Yes	How many days are missed: 1, 5, 10 or 20. Defaults to 10, the number in the claim.

Output Schema

Name	Required	Description
`ok`	No	false when we do not hold that data. Never a zero standing in for an answer.
`page`	No	The page with these exact numbers already in.
`error`	No	no_data when ok is false.
`model`	No	What missing a day means here, and what is not charged.
`reason`	No	Why, in one sentence, and what we do have instead.
`source`	No	The public file these numbers come from.
`history`	No	From, to, days held and which tape.
`windows`	No	Start days tested. Fewer than 120 and we refuse to give a percentage.
`median_pct`	No	The middle window, lived whole. The alternative, always.
`try_instead`	No	When ok is false: the closest call that does answer, ready to send (tool, arguments, and what changed).
`biggest_days`	No	The biggest up days and down days of the whole history, with their dates, so the clustering can be checked rather than believed.
`same_coin_in`	No	When ok is false because this tool lacks the coin: the other tools that hold it, each with arguments ready to send.
`share_in_profit_pct`	No	Windows that ended in profit, lived whole.
`cost_of_missing_best_pp`	No	Percentage points the best days were worth.
`median_without_best_pct`	No	The same window without its best days. This is the half of the claim you get shown.
`gift_of_missing_worst_pp`	No	Percentage points dodging the worst days would have paid.
`median_without_worst_pct`	No	The same window without its WORST days. This is the half nobody shows, and it is just as big.
`median_without_either_pct`	No	Without both groups: usually back near the first number, after dodging the days that supposedly decided everything.
`next_to_means_within_days`	No	What «next to» means, in days.
`winners_turned_losers_pct`	No	Of the windows that ended in profit, the share that end in loss once their best days are removed.
`share_in_profit_without_best_pct`	No	The same, without the best days.
`best_days_next_to_a_worst_day_pct`	No	Share of the best days that fell within a few days of one of the worst. High means you cannot dodge one without dodging the other.
`share_in_profit_without_worst_pct`	No	The same, without the worst days.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 15, 2026

addedInput schema / examples

Added value: +[
+  {
+    "best_days": 10,
+    "coin": "btc",
+    "days": 365
+  }
+]

addedOutput schema / properties / same_coin_in

Added value: +{
+  "description": "When ok is false because this tool lacks the coin: the other tools that hold it, each with arguments ready to send.",
+  "type": "array"
+}

addedOutput schema / properties / try_instead

Added value: +{
+  "description": "When ok is false: the closest call that does answer, ready to send (tool, arguments, and what changed).",
+  "type": "object"
+}

Changed3 schema fields changedOct 2, 2026
- addedInput schema / properties / best_days / default
```
Added value: +10
```
- addedInput schema / properties / best_days / enum
```
Added value: +[
+  1,
+  5,
+  10,
+  20
+]
```
- addedInput schema / properties / days / enum
```
Added value: +[
+  90,
+  365,
+  730
+]
```
First observedOct 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world, so the bar is lower. The description still adds substantive context beyond them: the data source (spot daily candles), the survivorship-bias stance ('dead coins included'), and the paired best/worst-day overlap diagnostic that determines whether the headline claim is meaningful.

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?

Front-loaded with the claim being tested, then what is returned, then usage. The first paragraph is dense and long, but each clause (four-way decomposition, overlap count, candle type, dead coins) conveys distinct information, and the second paragraph is a tight routing sentence.

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?

An output schema exists, so return formatting need not be restated, yet the description still supplies methodology and scope an agent needs to set expectations. With annotations covering safety and the schema covering all three parameters, nothing material is missing for correct invocation.

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% with enums on days and best_days and a stated default of 10, so the schema carries the parameter detail. The description's 'without its N best days / N worst days' gives a little conceptual framing for best_days but no format or edge-case guidance beyond the schema, making 3 the right baseline.

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 analytical operation (decompose a window four ways with/without N best/worst days) on a specific resource (spot daily candles for a coin). It also explicitly names the sibling calendar_check as the tool for the adjacent weekday/month question, so the boundary is unambiguous.

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 trigger ('Use when someone argues for staying invested because missing the best days ruins returns, or for timing the market to dodge the worst ones') and routes the nearby-but-different question to calendar_check. Both when-to-use and the alternative are named.

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

All Regime 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?