Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Regime

REMOTE · FEED.REGIMETOKEN.XYZ · SCANNED OCT 7

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

75 Trust /100
Trust breakdown (7 categories)

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. How we score → Why this is hard to score →

Endpoint Security80
Transport & Reachability100
Schema Quality & AI Usability66
  • AI-judged instruction clarity (excellent).Pass
  • 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. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management20
  • Stability observed for 6 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
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.

remote · feed.regimetoken.xyz

# add to Claude Code
claude mcp add --transport http xyz-regimetoken-regime 'https://feed.regimetoken.xyz/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "xyz-regimetoken-regime": {
      "url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "xyz-regimetoken-regime": {
      "type": "http",
      "url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
# ~/.codex/config.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
    }
  }
}
# add to OpenClaw
openclaw mcp add xyz-regimetoken-regime --url 'https://feed.regimetoken.xyz/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  xyz-regimetoken-regime:
    url: "https://feed.regimetoken.xyz/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "xyz-regimetoken-regime": {
      "Transport": "http",
      "Url": "https://feed.regimetoken.xyz/mcp"
    }
  }
}
# add to Vellum
assistant mcp add xyz-regimetoken-regime -t streamable-http -u 'https://feed.regimetoken.xyz/mcp'
// mcp.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 we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 7 Oct 26 +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.

  • 3 Oct 26 +1
    • 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 security
    • Schema quality: 192 → 242 ▼ functional
  • 2 Oct 26 0
    • Stability: unverified → 0.03 ▲ functional
  • 1 Oct 26 72

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 8 Oct 2026 · Probed https://feed.regimetoken.xyz/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=regimetoken.xyz CN=WE1,O=Google Trust Services,C=US 27 Aug 2026 25 Nov 2026 ECDSA 256 ECDSA-SHA256 c6cec6478a8b3a5a1363992928023eae
SANs: regimetoken.xyz, *.regimetoken.xyz
CN=WE1,O=Google Trust Services,C=US (CA) CN=GTS Root R4,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 ECDSA 256 ECDSA-SHA384 7ff31977972c224a76155d13b6d685e3
CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 15 Nov 2023 28 Jan 2028 ECDSA 384 SHA256-RSA 7fe530bf331343bedd821610493d8a1b

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of feed.regimetoken.xyz. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
xyz. present 3599, 18130 8, 8 Verified
regimetoken.xyz. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
strict-transport-security max-age=31536000
x-content-type-options nosniff

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://feed.regimetoken.xyz/mcp Verified 200
http (plaintext) http://feed.regimetoken.xyz/mcp HTTPS enforced 301 https://feed.regimetoken.xyz/mcp
MCP tools · 12 exposed · ~2,817 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
averaging_in_check ~232

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.

NameTypeReqDescription
coinstringyesTicker or full pair. An unknown one comes back with the list we hold and the ones left out.
daysnumberyesThe window, in days: 90, 365 or 730.
instalmentsstringyesHow often a slice goes in: weekly or monthly. Defaults to weekly.
NameTypeReqDescription
errorstring–no_data when ok is false.
instalmentsnumber–How many slices fit in the window.
median_edge_pointsnumber–Percentage points spreading made over lump sum in the middle case. Negative means lump sum won.
median_lump_sum_pctnumber–Middle start, all in on day one.
median_spread_pctnumber–Middle start, spread out.
modelstring–The assumptions, stated: cash not yet in earns nothing (against spreading), no fees (in favour of spreading).
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
p05_lump_sum_pctnumber–Fifth percentile of starts, lump sum: one worst day is an anecdote.
p05_spread_pctnumber–The same for spreading.
reasonstring–Why, in one sentence, and what we do have instead.
share_in_profit_lump_sum_pctnumber–Share of starts that ended up, lump sum.
share_in_profit_spread_pctnumber–The same for spreading.
sourcestring–The public file these numbers come from.
spreading_wonnumber–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_pctnumber–The same as a share of starts.
startsnumber–Start days tested. Fewer than 120 and we refuse to give a percentage.
worst_lump_sum_pctnumber–The single worst start day, all in on day one.
worst_spread_pctnumber–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.

No examples provided.

best_days_check ~224

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.

NameTypeReqDescription
best_daysnumberyesHow many days are missed: 1, 5, 10 or 20. Defaults to 10, the number in the claim.
coinstringyesTicker or full pair. An unknown one comes back with the list we hold and the ones left out.
daysnumberyesWindow in days: 90, 365 or 730.
NameTypeReqDescription
best_days_next_to_a_worst_day_pctnumber–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_daysobject–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_ppnumber–Percentage points the best days were worth.
errorstring–no_data when ok is false.
gift_of_missing_worst_ppnumber–Percentage points dodging the worst days would have paid.
historyobject–From, to, days held and which tape.
median_pctnumber–The middle window, lived whole. The alternative, always.
median_without_best_pctnumber–The same window without its best days. This is the half of the claim you get shown.
median_without_either_pctnumber–Without both groups: usually back near the first number, after dodging the days that supposedly decided everything.
median_without_worst_pctnumber–The same window without its WORST days. This is the half nobody shows, and it is just as big.
modelstring–What missing a day means here, and what is not charged.
next_to_means_within_daysnumber–What «next to» means, in days.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
pagestring–The page with these exact numbers already in.
reasonstring–Why, in one sentence, and what we do have instead.
share_in_profit_pctnumber–Windows that ended in profit, lived whole.
share_in_profit_without_best_pctnumber–The same, without the best days.
share_in_profit_without_worst_pctnumber–The same, without the worst days.
sourcestring–The public file these numbers come from.
windowsnumber–Start days tested. Fewer than 120 and we refuse to give a percentage.
winners_turned_losers_pctnumber–Of the windows that ended in profit, the share that end in loss once their best days are removed.

No examples provided.

calendar_check ~237

'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.

NameTypeReqDescription
calendarstringyesday_of_week, month_of_year or hour_of_day. The hourly one exists for the 16 coins we hold hourly candles for.
coinstringyesTicker or full pair. An unknown one comes back with the list we hold and the ones left out.
NameTypeReqDescription
beats_chance_at_5pctboolean–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_bucketstring–The best bucket by average move, named.
best_bucket_happened_timesnumber–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_pctnumber–Its average move. On its own, this is the advertisement.
bucketsarray–Every bucket: its name, observations, times occurred, mean, median and share of up days.
chance_best_mean_pctnumber–What the BEST bucket of a shuffled world averages. Anything below this is less impressive than nothing.
chance_best_p95_pctnumber–What chance reaches in one shuffle out of twenty.
chance_matches_it_sharenumber–The p-value: share of shuffles whose best bucket matched or beat the real one. High means no pattern.
edge_covers_costboolean–Whether the average move of the best bucket is bigger than that cost. Usually it is not.
errorstring–no_data when ok is false.
historyobject–From, to, days held and which tape.
modelstring–The test, stated, including why a monthly p-value flatters itself.
observationsnumber–Moves measured across all buckets.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
pagestring–The page with these exact numbers already in.
reasonstring–Why, in one sentence, and what we do have instead.
round_trip_cost_pctnumber–What entering and exiting once costs, so the edge can be compared with it.
shufflesnumber–How many shuffled worlds were tested.
sourcestring–The public file these numbers come from.
worst_bucketstring–The other end.
worst_mean_pctnumber–Its average move.

No examples provided.

coin_comparison ~207

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.

NameTypeReqDescription
coinsstringyesTwo or three tickers, comma-separated: BTC,ETH,SOL. Kept in the order sent.
daysnumberyes90, 365 (default) or 730.
leveragenumberyesFor the leverage row. Default 25.
NameTypeReqDescription
errorstring–no_data when ok is false.
modelstring–The method, stated.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
reasonstring–Why, in one sentence, and what we do have instead.
rowsarray–Per coin: the drawdown, leverage, averaging-in and stop-loss answers, and its correlation with bitcoin (null for bitcoin itself).
sourcestring–The public files these numbers come from.

No examples provided.

copy_trading_check ~192

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.

NameTypeReqDescription
ranked_bystringyesreturn (default) or profit.
top_pctnumberyes10 (default) or 1. 0.1 is read as 10.
NameTypeReqDescription
chance_pctnumber–What picking accounts at random gives. The alternative, always.
errorstring–no_data when ok is false.
fell_to_bottom_pctnumber–Share that fell to the bottom group instead: the size control.
in_profit_next_month_all_accounts_pctnumber–The same for every active account.
in_profit_next_month_pctnumber–Share that made money the next month.
modelstring–The method, stated.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
reasonstring–Why, in one sentence, and what we do have instead.
repeatednumber–Of those, times it was in the top again next month.
repeated_pctnumber–The same as a share.
sourcestring–The public file these numbers come from.
stopped_tradingnumber–Counted as not repeating.
times_in_topnumber–Times an account finished a month in the top group.

No examples provided.

diversification_check ~223

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.

NameTypeReqDescription
coinsarrayyesTickers or full pairs, e.g. ["BTC", "ETH", "SOL"]. A comma-separated string also works. One we do not hold comes back with the list.
daysnumberyesWindow ending on the last day of the data: 90, 365 or 730. Defaults to 365.
NameTypeReqDescription
all_coins_we_holdobject–What every coin we hold, at equal weights, adds up to — the ceiling, for comparison.
average_pair_correlationnumber–Pearson correlation of daily log returns, averaged over every pair in the basket.
btc_bad_daysobject–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_btcobject–Each coin's correlation with bitcoin in the window.
errorstring–no_data when ok is false.
independent_betsnumber–N / (1 + (N-1)*avg_corr). Five coins that move as one are one bet; five that ignore each other are five.
modelstring–The assumptions, stated.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
reasonstring–Why, in one sentence, and what we do have instead.
sourcestring–The public file these numbers come from.

No examples provided.

drawdown_check ~213

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.

NameTypeReqDescription
coinstringyesTicker or full pair. An unknown one comes back with the list we hold and the ones left out.
daysnumberyesHow long it is held: 30, 90, 365 or 730.
NameTypeReqDescription
asset_max_drawdownobject–The coin's own biggest top-to-bottom fall, with dates and days to recover, for comparison.
errorstring–no_data when ok is false.
median_days_under_waternumber–Days of the hold spent below the entry price, middle start.
median_return_pctnumber–How the middle start ended.
median_worst_fall_among_winners_pctnumber–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_pctnumber–The middle start's worst fall from its own entry price within the hold.
modelstring–The assumptions, stated.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
reasonstring–Why, in one sentence, and what we do have instead.
share_fell_30_pctnumber–Share of starts that fell 30% or more from entry first.
share_fell_50_pctnumber–Same, 50% or more.
share_in_profit_pctnumber–Share of starts that ended up.
share_never_recovered_pctnumber–Starts that never closed back at their entry price within the hold.
sourcestring–The public file these numbers come from.
startsnumber–Start days tested. Fewer than 120 and we refuse to give a percentage.

No examples provided.

leaderboard_rank_check ~192

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.

NameTypeReqDescription
return_pctnumberyesIn percent: 340 means +340%.
windowstringyesday, week, month (default) or allTime.
NameTypeReqDescription
accounts_that_tradednumber–The denominator.
errorstring–no_data when ok is false.
median_return_pctnumber–The middle account, same window.
modelstring–The method, stated.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
one_innumber–One account in how many.
percentilenumber–Share of accounts below it.
reasonstring–Why, in one sentence, and what we do have instead.
same_or_betternumber–Accounts at that return or above.
share_in_profit_pctnumber–Accounts in profit, same window.
sourcestring–The public file these numbers come from.

No examples provided.

leverage_survival ~234

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.

NameTypeReqDescription
coinstringyesTicker or full pair. An unknown one comes back with the list we hold and the ones we do not.
daysnumberyesHow long it is held: 1, 7, 30 or 90.
leveragenumberyes2, 3, 5, 10, 20, 25, 50 or 100.
sidestring–long or short. Defaults to long.
NameTypeReqDescription
attemptsnumber–Starting days tested. A position still open when the history ends is not counted.
best_pctnumber–The best day. It is the one you were shown, and it is not hidden here.
errorstring–no_data when ok is false.
liquidated_pctnumber–Share of them that ended with nothing left.
median_days_to_liquidationnumber–How fast, when it happened.
median_return_pctnumber–The middle outcome, on the margin.
median_return_unlevered_pctnumber–What the same coin did with no leverage over the same days. A result without this is advertising.
modelstring–The assumptions, stated: liquidation at exactly 1/leverage with no maintenance margin, funding charged daily, the wick decides not the close.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
reasonstring–Why, in one sentence, and what we do have instead.
sourcestring–The public file these numbers come from.

No examples provided.

overfitting_odds ~257

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.

NameTypeReqDescription
baselinenumber–Probability a single trade wins by chance. Defaults to 0.5.
lossesnumber–Losing trades. Give this or trades.
tradesnumberyesTotal trades.
triesnumber–How many versions were tried before this one was shown to you. Defaults to 1, which is almost never true.
winsnumberyesWinning trades.
NameTypeReqDescription
errorstring–no_data when ok is false.
odds_best_of_triesnumber–Same result, once you take the best of the attempts made.
odds_one_trynumber–P(at least this many wins) for a single attempt. Exact binomial, not simulated.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
readingstring–The same three numbers in one sentence.
reasonstring–Why, in one sentence, and what we do have instead.
tries_for_even_oddsnumber–Attempts needed for chance alone to reach it half the time.
win_rate_pctnumber–The win rate.

No examples provided.

stop_loss_check ~262

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.

NameTypeReqDescription
coinstringyesTicker or full pair. An unknown one comes back with the list we hold and the ones left out.
daysnumberyesHolding period in days: 30, 90, 365 or 730.
stopnumberyesHow far below the entry, in percent: 5, 10, 15, 20 or 30. 0.05 is read as 5.
NameTypeReqDescription
buysnumber–Start days tested. Fewer than 120 and we refuse to give a percentage.
errorstring–no_data when ok is false.
fired_but_would_have_ended_in_profitnumber–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_pctnumber–The same as a share of ALL buys.
mean_with_stop_pctnumber–Average buy, with the stop.
mean_without_stop_pctnumber–Average buy, holding. Skewed by a few huge winners.
median_days_to_firenumber–Among the buys it fired on. Null when it never fired.
median_with_stop_pctnumber–Middle buy, with the stop.
median_without_stop_pctnumber–Middle buy, just holding. The alternative, always.
modelstring–The assumptions, stated: the low triggers, fills at the stop or the gap open, out until the end, same costs both ways.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
p05_with_stop_pctnumber–Fifth percentile, with the stop: what the stop actually buys.
p05_without_stop_pctnumber–The same, holding.
reasonstring–Why, in one sentence, and what we do have instead.
share_in_profit_with_stop_pctnumber–Share of buys that ended up, stop.
share_in_profit_without_stop_pctnumber–The same, holding.
sourcestring–The public file these numbers come from.
stop_beat_holdingnumber–Buys on which the stop ended strictly ahead of holding.
stop_beat_holding_pctnumber–The same as a share of buys.
stop_firednumber–Buys on which the stop fired. A count.
stop_fired_pctnumber–The same as a share of buys.
worst_with_stop_pctnumber–The single worst buy, with the stop. Worse than the stop itself only when a day gapped through.
worst_without_stop_pctnumber–The same, holding.

No examples provided.

strategy_grid_lookup ~344

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.

NameTypeReqDescription
candlesstring–cross only: 1d or 4h.
coinstringyesBTC, ETH, SOL, DOGE, PEPE, SRM… ticker or full pair. Ask with an unknown one and the answer lists the sixteen we hold.
dropnumber–dip only: how far below its recent high to buy, in %.
familystring–dip (buy when it falls) or cross (moving average crossover). Defaults to dip.
fastnumber–cross only: fast average.
hoursnumber–dip only: give up after this many hours.
slownumber–cross only: slow average.
stopnumber–dip only: stop loss, in %.
targetnumber–dip only: take profit, in %.
NameTypeReqDescription
buy_and_hold_pctnumber–What buying the coin and leaving it alone returned over the same window. A result without this is advertising.
errorstring–no_data when ok is false.
max_drawdown_pctnumber–Worst peak-to-trough fall.
okboolean–false when we do not hold that data. Never a zero standing in for an answer.
reasonstring–Why, in one sentence, and what we do have instead.
return_pctnumber–What it returned, after fees.
rulestring–The rule in plain English.
sourcestring–The public file these numbers come from.
tradesnumber–How many trades it took.
versions_beating_buy_and_holdnumber–How many of them beat doing nothing. Often zero.
versions_in_familynumber–How many versions of this idea exist.
win_rate_pctnumber–Share of winners.

No examples provided.

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.