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

TableJSON 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

TableJSON 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.
`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.
`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 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 declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavioral context beyond that — data domain (spot daily candles), survivorship handling (dead coins included), the full-history rolling start-day sweep, and a derived output (count of best days within a week of a worst one). It stops short of failure behavior or cost/latency characteristics.

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?

Two paragraphs, both earning their place, front-loaded with the core computation before usage guidance. Slightly dense, but no filler or repetition.

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 values need not be spelled out; the description nonetheless frames what the four scenarios yield and when the tool is applicable. For a read-only analytical tool with fully covered params, nothing an agent needs is missing.

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% and enums are already documented, so the baseline is 3. The description explains what the analysis does conceptually with best_days and the window, but adds no format, range, or syntax detail beyond what the schema already carries.

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 precisely what it computes: the 'miss the ten best days' claim, measured four ways (all, minus best N, minus worst N, minus both) across every start day. It explicitly names the sibling calendar_check and what that sibling covers instead, so an agent can route without opening either 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 explicit trigger conditions ('when someone argues for staying invested because missing the best days ruins returns, or for timing the market to dodge the worst ones') and names the alternative tool (calendar_check) for the adjacent question.

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?