# Regime (remote · feed.regimetoken.xyz)

Checks crypto trading claims on real data: leverage, drawdown, stop-loss, seasonality, luck.

- Trust score: 75/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-07

## Components

- remote · `feed.regimetoken.xyz`: 75/100 (this document), [markdown](https://verifymcp.io/servers/xyz-regimetoken-regime/feed.md), [page](https://verifymcp.io/servers/xyz-regimetoken-regime/feed)

## Channel facts

- Endpoint: `https://feed.regimetoken.xyz/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-07.

- **Endpoint Security**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 66/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2906 tokens (~242/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 20/100
  - Stability observed for 6 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Regime MCP server?

Regime is a hosted endpoint at https://feed.regimetoken.xyz/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http xyz-regimetoken-regime 'https://feed.regimetoken.xyz/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "xyz-regimetoken-regime": {
      "url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "xyz-regimetoken-regime": {
      "type": "http",
      "url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.xyz-regimetoken-regime]
url = "https://feed.regimetoken.xyz/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "xyz-regimetoken-regime": {
      "type": "remote",
      "url": "https://feed.regimetoken.xyz/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add xyz-regimetoken-regime --url 'https://feed.regimetoken.xyz/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  xyz-regimetoken-regime:
    url: "https://feed.regimetoken.xyz/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "xyz-regimetoken-regime": {
      "Transport": "http",
      "Url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add xyz-regimetoken-regime -t streamable-http -u 'https://feed.regimetoken.xyz/mcp'
```

### Other

```json
{
  "mcpServers": {
    "xyz-regimetoken-regime": {
      "type": "http",
      "url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-07 (score 75, +2)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 20. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-03 (score 73, +1)

- [security] Tool “averaging_in_check” rewrote its description, which is the text the model reads
- [security] Tool “best_days_check” rewrote its description, which is the text the model reads
- [security] Tool “calendar_check” rewrote its description, which is the text the model reads
- [security] Tool “coin_comparison” rewrote its description, which is the text the model reads
- [security] Tool “copy_trading_check” rewrote its description, which is the text the model reads
- [security] Tool “diversification_check” rewrote its description, which is the text the model reads
- [security] Tool “drawdown_check” rewrote its description, which is the text the model reads
- [security] Tool “leaderboard_rank_check” rewrote its description, which is the text the model reads
- [security] Tool “leverage_survival” rewrote its description, which is the text the model reads
- [security] Tool “overfitting_odds” rewrote its description, which is the text the model reads
- [security] Tool “stop_loss_check” rewrote its description, which is the text the model reads
- [security] Tool “strategy_grid_lookup” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 192 → 242

### 2026-10-02 (score 72, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-10-01 (score 72)

First indexed and scored.

## MCP tools (12)

### `strategy_grid_lookup` (~344 tokens)

Strategy grid lookup

Backtest lookup: what one exact version of a strategy actually did. Buy-the-dip and the moving-average cross, every combination of their knobs, computed over nine years of real prices with the exchange's fees charged both ways — sixteen coins, three of which died. Give the coin and the numbers and you get the return, the trades, the worst drawdown, and what buying and holding did over the same window. Read from a file you can download.

Use when someone quotes a specific dip-buying or moving-average rule ("buy 10% dips, take 5%") and you want its real backtest. For leverage use leverage_survival; for a stop on a plain buy-and-hold, stop_loss_check; to judge a win rate you were shown, overfitting_odds.

Input parameters:

- `candles` (string): cross only: 1d or 4h.
- `coin` (string, required): BTC, ETH, SOL, DOGE, PEPE, SRM… ticker or full pair. Ask with an unknown one and the answer lists the sixteen we hold.
- `drop` (number): dip only: how far below its recent high to buy, in %.
- `family` (string): dip (buy when it falls) or cross (moving average crossover). Defaults to dip.
- `fast` (number): cross only: fast average.
- `hours` (number): dip only: give up after this many hours.
- `slow` (number): cross only: slow average.
- `stop` (number): dip only: stop loss, in %.
- `target` (number): dip only: take profit, in %.

Output parameters:

- `buy_and_hold_pct` (number): What buying the coin and leaving it alone returned over the same window. A result without this is advertising.
- `error` (string): no_data when ok is false.
- `max_drawdown_pct` (number): Worst peak-to-trough fall.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `return_pct` (number): What it returned, after fees.
- `rule` (string): The rule in plain English.
- `source` (string): The public file these numbers come from.
- `trades` (number): How many trades it took.
- `versions_beating_buy_and_hold` (number): How many of them beat doing nothing. Often zero.
- `versions_in_family` (number): How many versions of this idea exist.
- `win_rate_pct` (number): Share of winners.

### `overfitting_odds` (~257 tokens)

Overfitting odds

Overfitting check: how many attempts plain chance needs to produce the track record you were shown. Give the wins, the losses and how many versions were tried: you get the exact binomial odds of one try reaching it, the odds once somebody shows you the best of N, and how many tries would make it an even bet. Arithmetic only — no market data, no model, no opinion. A 62% win rate over 100 trades is one thing on the first try, nothing on the fiftieth.

Use when you are shown a win rate, a backtest or a signal channel's record and need to know whether luck explains it. Needs no coin. For what a named rule did on real prices use strategy_grid_lookup; to place a return among real accounts, leaderboard_rank_check.

Input parameters:

- `baseline` (number): Probability a single trade wins by chance. Defaults to 0.5.
- `losses` (number): Losing trades. Give this or trades.
- `trades` (number, required): Total trades.
- `tries` (number): How many versions were tried before this one was shown to you. Defaults to 1, which is almost never true.
- `wins` (number, required): Winning trades.

Output parameters:

- `error` (string): no_data when ok is false.
- `odds_best_of_tries` (number): Same result, once you take the best of the attempts made.
- `odds_one_try` (number): P(at least this many wins) for a single attempt. Exact binomial, not simulated.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reading` (string): The same three numbers in one sentence.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `tries_for_even_odds` (number): Attempts needed for chance alone to reach it half the time.
- `win_rate_pct` (number): The win rate.

### `leverage_survival` (~234 tokens)

Leverage survival

What a leveraged trade actually did, opened on every single day of the history instead of the one day that worked. Give coin, side, leverage and holding period: you get the share of those days that ended liquidated, the median outcome, the best day, and what the same coin did with no leverage at all. Real perpetual tape, with the funding that was actually paid charged daily and eating into margin. Coins that blew up included.

Use when the question involves leverage, perpetuals or liquidation. For the fall an unleveraged holder sits through use drawdown_check; for two or three coins at once, coin_comparison.

Input parameters:

- `coin` (string, required): Ticker or full pair. An unknown one comes back with the list we hold and the ones we do not.
- `days` (number, required): How long it is held: 1, 7, 30 or 90.
- `leverage` (number, required): 2, 3, 5, 10, 20, 25, 50 or 100.
- `side` (string): long or short. Defaults to long.

Output parameters:

- `attempts` (number): Starting days tested. A position still open when the history ends is not counted.
- `best_pct` (number): The best day. It is the one you were shown, and it is not hidden here.
- `error` (string): no_data when ok is false.
- `liquidated_pct` (number): Share of them that ended with nothing left.
- `median_days_to_liquidation` (number): How fast, when it happened.
- `median_return_pct` (number): The middle outcome, on the margin.
- `median_return_unlevered_pct` (number): What the same coin did with no leverage over the same days. A result without this is advertising.
- `model` (string): The assumptions, stated: liquidation at exactly 1/leverage with no maintenance margin, funding charged daily, the wick decides not the close.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `source` (string): The public file these numbers come from.

### `drawdown_check` (~213 tokens)

Drawdown check

Drawdown check: what it cost to collect the return you were shown. The coin is bought at the close of every day of its history and held for the period you name: you get the drawdown from the entry before the period was out, the share of starts that fell 30% and 50%, the days spent under water, how it ended — and, among the starts that ended in profit, the drawdown they sat through first. Spot tape, no fees, coins that died included.

Use when a return is quoted for holding a coin ("BTC did +150% in a year") and you want the fall endured on the way. With leverage use leverage_survival; to test a stop that cuts the fall, stop_loss_check.

Input parameters:

- `coin` (string, required): Ticker or full pair. An unknown one comes back with the list we hold and the ones left out.
- `days` (number, required): How long it is held: 30, 90, 365 or 730.

Output parameters:

- `asset_max_drawdown` (object): The coin's own biggest top-to-bottom fall, with dates and days to recover, for comparison.
- `error` (string): no_data when ok is false.
- `median_days_under_water` (number): Days of the hold spent below the entry price, middle start.
- `median_return_pct` (number): How the middle start ended.
- `median_worst_fall_among_winners_pct` (number): Among the starts that ended in profit, the median fall they sat through first. The price of the number you were shown. A return without this is advertising.
- `median_worst_fall_pct` (number): The middle start's worst fall from its own entry price within the hold.
- `model` (string): The assumptions, stated.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `share_fell_30_pct` (number): Share of starts that fell 30% or more from entry first.
- `share_fell_50_pct` (number): Same, 50% or more.
- `share_in_profit_pct` (number): Share of starts that ended up.
- `share_never_recovered_pct` (number): Starts that never closed back at their entry price within the hold.
- `source` (string): The public file these numbers come from.
- `starts` (number): Start days tested. Fewer than 120 and we refuse to give a percentage.

### `diversification_check` (~223 tokens)

Diversification check

Diversification check: how many independent bets a basket of coins really is. Give the coins (and optionally the window: 90, 365 or 730 days): you get the average correlation between the pairs on real daily returns, the number of independent bets it works out to, each coin's correlation with bitcoin — and what the equal-weight basket did on the days bitcoin closed 3% or more down: how often it fell too, by how much, and its worst such day. Dead coins included.

Use when a basket of two or more coins is called diversified or hedged. For one coin use drawdown_check; for two or three coins side by side on every check, coin_comparison.

Input parameters:

- `coins` (array, required): Tickers or full pairs, e.g. ["BTC", "ETH", "SOL"]. A comma-separated string also works. One we do not hold comes back with the list.
- `days` (number, required): Window ending on the last day of the data: 90, 365 or 730. Defaults to 365.

Output parameters:

- `all_coins_we_hold` (object): What every coin we hold, at equal weights, adds up to — the ceiling, for comparison.
- `average_pair_correlation` (number): Pearson correlation of daily log returns, averaged over every pair in the basket.
- `btc_bad_days` (object): The days bitcoin closed 3% or more down: how many, on what share of them the basket fell too, its median and worst move. Diversification that vanishes on those days was never there.
- `correlation_with_btc` (object): Each coin's correlation with bitcoin in the window.
- `error` (string): no_data when ok is false.
- `independent_bets` (number): N / (1 + (N-1)*avg_corr). Five coins that move as one are one bet; five that ignore each other are five.
- `model` (string): The assumptions, stated.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `source` (string): The public file these numbers come from.

### `averaging_in_check` (~232 tokens)

Averaging in check

Whether spreading the entry would have helped, measured. One amount into a coin over a window (90, 365 or 730 days): all of it on day one, or equal instalments weekly or monthly. Both start the same day, move the same money and are valued on the same day, started on every day of the history. You get how often spreading ended ahead, the middle result of each, and the worst start day of each — which is what spreading actually buys and the half nobody shows. Spot tape, no fees, dead coins included.

Use for dollar-cost averaging versus lump sum on one coin. For claims about particular days or months use best_days_check or calendar_check; for the fall after a single buy, drawdown_check.

Input parameters:

- `coin` (string, required): Ticker or full pair. An unknown one comes back with the list we hold and the ones left out.
- `days` (number, required): The window, in days: 90, 365 or 730.
- `instalments` (string, required): How often a slice goes in: weekly or monthly. Defaults to weekly.

Output parameters:

- `error` (string): no_data when ok is false.
- `instalments` (number): How many slices fit in the window.
- `median_edge_points` (number): Percentage points spreading made over lump sum in the middle case. Negative means lump sum won.
- `median_lump_sum_pct` (number): Middle start, all in on day one.
- `median_spread_pct` (number): Middle start, spread out.
- `model` (string): The assumptions, stated: cash not yet in earns nothing (against spreading), no fees (in favour of spreading).
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `p05_lump_sum_pct` (number): Fifth percentile of starts, lump sum: one worst day is an anecdote.
- `p05_spread_pct` (number): The same for spreading.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `share_in_profit_lump_sum_pct` (number): Share of starts that ended up, lump sum.
- `share_in_profit_spread_pct` (number): The same for spreading.
- `source` (string): The public file these numbers come from.
- `spreading_won` (number): Start days on which spreading it out ended ahead. A count, not a rate: «100%» is only said when it was all of them.
- `spreading_won_pct` (number): The same as a share of starts.
- `starts` (number): Start days tested. Fewer than 120 and we refuse to give a percentage.
- `worst_lump_sum_pct` (number): The single worst start day, all in on day one.
- `worst_spread_pct` (number): The same for spreading. This pair is the whole argument for averaging in, and it is the one that never appears next to the advice.

### `stop_loss_check` (~262 tokens)

Stop loss check

Whether a stop-loss would have helped, measured. The same buy of a coin, held 30, 90, 365 or 730 days, with a stop 5, 10, 15, 20 or 30% below the entry and without one, started on every day of the history. The stop fires on the day's low, not its close, and fees are charged to both. You get how often it fired, how often it sold a buy that would have ended in profit, and the worst case of each. Spot tape, dead coins included.

Use when asked whether a stop-loss protects a spot buy-and-hold. For leveraged positions, where liquidation is the stop, use leverage_survival; for a rule with a stop and a take-profit, strategy_grid_lookup.

Input parameters:

- `coin` (string, required): Ticker or full pair. An unknown one comes back with the list we hold and the ones left out.
- `days` (number, required): Holding period in days: 30, 90, 365 or 730.
- `stop` (number, required): How far below the entry, in percent: 5, 10, 15, 20 or 30. 0.05 is read as 5.

Output parameters:

- `buys` (number): Start days tested. Fewer than 120 and we refuse to give a percentage.
- `error` (string): no_data when ok is false.
- `fired_but_would_have_ended_in_profit` (number): Buys the stop sold that, held to the end, would have ended in profit after fees. The half nobody shows.
- `fired_but_would_have_ended_in_profit_pct` (number): The same as a share of ALL buys.
- `mean_with_stop_pct` (number): Average buy, with the stop.
- `mean_without_stop_pct` (number): Average buy, holding. Skewed by a few huge winners.
- `median_days_to_fire` (number): Among the buys it fired on. Null when it never fired.
- `median_with_stop_pct` (number): Middle buy, with the stop.
- `median_without_stop_pct` (number): Middle buy, just holding. The alternative, always.
- `model` (string): The assumptions, stated: the low triggers, fills at the stop or the gap open, out until the end, same costs both ways.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `p05_with_stop_pct` (number): Fifth percentile, with the stop: what the stop actually buys.
- `p05_without_stop_pct` (number): The same, holding.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `share_in_profit_with_stop_pct` (number): Share of buys that ended up, stop.
- `share_in_profit_without_stop_pct` (number): The same, holding.
- `source` (string): The public file these numbers come from.
- `stop_beat_holding` (number): Buys on which the stop ended strictly ahead of holding.
- `stop_beat_holding_pct` (number): The same as a share of buys.
- `stop_fired` (number): Buys on which the stop fired. A count.
- `stop_fired_pct` (number): The same as a share of buys.
- `worst_with_stop_pct` (number): The single worst buy, with the stop. Worse than the stop itself only when a day gapped through.
- `worst_without_stop_pct` (number): The same, holding.

### `copy_trading_check` (~192 tokens)

Copy trading check

Whether copying the top traders works, measured. Accounts in the top 10% or 1% of Hyperliquid one month, by return or by dollar profit: how many were in the top again the next month, next to chance, how many fell to the bottom instead, and how many made money the month you would have copied them for, next to every active account. 4,000 accounts sampled at random, not today's leaders; about 30 month pairs.

Use when someone proposes copying top traders, a leaderboard or signal leaders. Takes no account address. To place one specific return on the leaderboard use leaderboard_rank_check; to ask whether luck explains a record, overfitting_odds.

Input parameters:

- `ranked_by` (string, required): return (default) or profit.
- `top_pct` (number, required): 10 (default) or 1. 0.1 is read as 10.

Output parameters:

- `chance_pct` (number): What picking accounts at random gives. The alternative, always.
- `error` (string): no_data when ok is false.
- `fell_to_bottom_pct` (number): Share that fell to the bottom group instead: the size control.
- `in_profit_next_month_all_accounts_pct` (number): The same for every active account.
- `in_profit_next_month_pct` (number): Share that made money the next month.
- `model` (string): The method, stated.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `repeated` (number): Of those, times it was in the top again next month.
- `repeated_pct` (number): The same as a share.
- `source` (string): The public file these numbers come from.
- `stopped_trading` (number): Counted as not repeating.
- `times_in_top` (number): Times an account finished a month in the top group.

### `leaderboard_rank_check` (~192 tokens)

Leaderboard rank check

How much company a return has. Send a return (+340%) and a window (day, week, month or all time) and get how many accounts on Hyperliquid's whole public leaderboard did the same or better, out of how many traded, its percentile, and the median account next to it. Every row of the exchange's own table, refreshed daily; the denominator is the accounts that traded, not the ones that sat idle.

Use when a trader or an ad quotes a return ("+340% this month") and you want to know how rare it is. Hyperliquid accounts only. Whether last month's top accounts stay on top is copy_trading_check; whether luck explains a win rate, overfitting_odds.

Input parameters:

- `return_pct` (number, required): In percent: 340 means +340%.
- `window` (string, required): day, week, month (default) or allTime.

Output parameters:

- `accounts_that_traded` (number): The denominator.
- `error` (string): no_data when ok is false.
- `median_return_pct` (number): The middle account, same window.
- `model` (string): The method, stated.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `one_in` (number): One account in how many.
- `percentile` (number): Share of accounts below it.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `same_or_better` (number): Accounts at that return or above.
- `share_in_profit_pct` (number): Accounts in profit, same window.
- `source` (string): The public file these numbers come from.

### `calendar_check` (~237 tokens)

Calendar check

'Uptober'. 'Mondays dip'. 'Sell in May'. Any calendar claim on 34 coins, measured against chance. With seven days one has to come first, so the answer is a permutation test: the SAME returns dealt out at random hundreds of times, and how often chance alone produces a bucket that good. Plus how many times the bucket really happened - October is 279 days of bitcoin but nine Octobers - and the round-trip cost. Nine years of daily candles.

Tests whether one day of the week, month of the year or hour of the day really beats the rest for a coin. Use for seasonality claims (Uptober, Monday dips, Sell in May). For the claim about missing the market's best days use best_days_check; for when to spread an entry, averaging_in_check.

Input parameters:

- `calendar` (string, required): day_of_week, month_of_year or hour_of_day. The hourly one exists for the 16 coins we hold hourly candles for.
- `coin` (string, required): Ticker or full pair. An unknown one comes back with the list we hold and the ones left out.

Output parameters:

- `beats_chance_at_5pct` (boolean): Whether that share is under 0.05. Across all 34 coins, about 5% of these come back true by chance alone, so one true answer on its own is not a finding.
- `best_bucket` (string): The best bucket by average move, named.
- `best_bucket_happened_times` (number): How many times that bucket has actually occurred. For months this is years, not days: nine Octobers is nine observations however many candles they hold, and it is the number these claims never show.
- `best_mean_pct` (number): Its average move. On its own, this is the advertisement.
- `buckets` (array): Every bucket: its name, observations, times occurred, mean, median and share of up days.
- `chance_best_mean_pct` (number): What the BEST bucket of a shuffled world averages. Anything below this is less impressive than nothing.
- `chance_best_p95_pct` (number): What chance reaches in one shuffle out of twenty.
- `chance_matches_it_share` (number): The p-value: share of shuffles whose best bucket matched or beat the real one. High means no pattern.
- `edge_covers_cost` (boolean): Whether the average move of the best bucket is bigger than that cost. Usually it is not.
- `error` (string): no_data when ok is false.
- `history` (object): From, to, days held and which tape.
- `model` (string): The test, stated, including why a monthly p-value flatters itself.
- `observations` (number): Moves measured across all buckets.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `page` (string): The page with these exact numbers already in.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `round_trip_cost_pct` (number): What entering and exiting once costs, so the edge can be compared with it.
- `shuffles` (number): How many shuffled worlds were tested.
- `source` (string): The public file these numbers come from.
- `worst_bucket` (string): The other end.
- `worst_mean_pct` (number): Its average move.

### `best_days_check` (~224 tokens)

Best days check

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 parameters:

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

Output parameters:

- `best_days_next_to_a_worst_day_pct` (number): 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.
- `biggest_days` (object): The biggest up days and down days of the whole history, with their dates, so the clustering can be checked rather than believed.
- `cost_of_missing_best_pp` (number): Percentage points the best days were worth.
- `error` (string): no_data when ok is false.
- `gift_of_missing_worst_pp` (number): Percentage points dodging the worst days would have paid.
- `history` (object): From, to, days held and which tape.
- `median_pct` (number): The middle window, lived whole. The alternative, always.
- `median_without_best_pct` (number): The same window without its best days. This is the half of the claim you get shown.
- `median_without_either_pct` (number): Without both groups: usually back near the first number, after dodging the days that supposedly decided everything.
- `median_without_worst_pct` (number): The same window without its WORST days. This is the half nobody shows, and it is just as big.
- `model` (string): What missing a day means here, and what is not charged.
- `next_to_means_within_days` (number): What «next to» means, in days.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `page` (string): The page with these exact numbers already in.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `share_in_profit_pct` (number): Windows that ended in profit, lived whole.
- `share_in_profit_without_best_pct` (number): The same, without the best days.
- `share_in_profit_without_worst_pct` (number): The same, without the worst days.
- `source` (string): The public file these numbers come from.
- `windows` (number): Start days tested. Fewer than 120 and we refuse to give a percentage.
- `winners_turned_losers_pct` (number): Of the windows that ended in profit, the share that end in loss once their best days are removed.

### `coin_comparison` (~207 tokens)

Coin comparison

Two or three coins side by side, every check at once: for each, how often a buy fell 30% or more before the window was out and where the middle one ended, how often a leveraged month ended with nothing, whether spreading the entry won, how often a stop-loss sold a buy that ended in profit, and how much it moves with bitcoin. Nothing is ranked and no coin is called better. Spot and perpetual tapes, fees charged.

Use when two or three coins are being compared or chosen between. For one coin or one question the specific check gives more detail: drawdown_check, leverage_survival, averaging_in_check, stop_loss_check, diversification_check.

Input parameters:

- `coins` (string, required): Two or three tickers, comma-separated: BTC,ETH,SOL. Kept in the order sent.
- `days` (number, required): 90, 365 (default) or 730.
- `leverage` (number, required): For the leverage row. Default 25.

Output parameters:

- `error` (string): no_data when ok is false.
- `model` (string): The method, stated.
- `ok` (boolean): false when we do not hold that data. Never a zero standing in for an answer.
- `reason` (string): Why, in one sentence, and what we do have instead.
- `rows` (array): Per coin: the drawdown, leverage, averaging-in and stop-loss answers, and its correlation with bitcoin (null for bitcoin itself).
- `source` (string): The public files these numbers come from.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/xyz-regimetoken-regime/feed#diagnostics

## Score history

- 2026-10-07: 75
- 2026-10-04: 73
- 2026-10-03: 73
- 2026-10-02: 72
- 2026-10-01: 72

## Common questions

### What is the Regime MCP server?

Regime is an MCP server listed in the public MCP registry as xyz.regimetoken/regime. Checks crypto trading claims on real data: leverage, drawdown, stop-loss, seasonality, luck. This page covers its hosted endpoint (https://feed.regimetoken.xyz/mcp).

### Is the Regime MCP server safe to use?

Regime scores 75 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Regime MCP server expose?

Regime exposes 12 tools: strategy_grid_lookup, overfitting_odds, leverage_survival, drawdown_check, diversification_check, and 7 more. Their descriptions and schemas cost roughly 2,817 tokens of context every time the server is loaded.

### Does the Regime MCP server require authentication?

No. We connected to Regime without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Regime MCP server still maintained?

Regime is still listed as active in the MCP registry. We last reached this channel on 7 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://feed.regimetoken.xyz/mcp
- Website: https://regimetoken.xyz/api
- Changelog RSS feed: https://verifymcp.io/servers/xyz-regimetoken-regime/feed.xml
- Changelog JSON feed: https://verifymcp.io/servers/xyz-regimetoken-regime/feed.json
- HTML version of this page: https://verifymcp.io/servers/xyz-regimetoken-regime/feed