Tells you whether a trading strategy's edge is distinguishable from luck.
Scored across 4 tools
Each tool has a clearly distinct role: listing available factors, testing whether performance beats luck, decomposing returns by regime, and validating the engine itself. There is no meaningful overlap or ambiguity about which tool to call.
All tools share the regimen_ prefix and use snake_case, making them easy to group. The pattern is mostly verb_noun, but regime_map and self_attack are noun-first, which is a minor deviation.
Four tools is appropriate for this focused server: each tool earns its place and covers a distinct stage of the validation workflow. It is neither bloated nor too thin for its stated purpose.
The tool surface covers the full skeptical analysis pipeline: understand the factors, evaluate the headline claim, locate the edge by regime, and verify that the engine itself is not fooled. There are no obvious dead ends or missing operations for this domain.
List the market-condition factors Regimen slices performance by, with units, the upstream operation each is read from, and how it is bucketed. Call this when you need to know which factor keys exist or how to explain a bucket to a user. Takes no arguments, reaches no network, never changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| factors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond those: 'reaches no network, never changes' and describes the output content (units, upstream operation, bucketing). No contradiction with annotations; the added network and output details justify above-baseline credit.
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?
Two compact sentences with no wasted words. The first sentence front-loads the exact purpose and scope; the second adds usage trigger and behavioral constraints. Every clause earns its place.
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-argument read-only tool with annotations and an output schema, the description is fully sufficient. It states what is returned, why a user would call it, and what side effects to expect (none). Nothing an agent needs to invoke it correctly 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 has zero parameters and 100% schema description coverage, so the baseline is 4. The description reinforces this with 'Takes no arguments,' which is redundant but harmless. There is no parameter ambiguity to compensate for.
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 names a specific verb ('List') and a precise resource ('market-condition factors Regimen slices performance by'), and specifies the detail level: units, upstream operation, and bucketing. This clearly distinguishes it from sibling tools like regimen_evaluate_track_record or regimen_regime_map, which are about evaluation and mapping rather than describing factor keys.
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 an explicit call-when: 'when you need to know which factor keys exist or how to explain a bucket to a user.' It does not explicitly name when-not-to-use or alternative tools, but the phrasing implies this is for descriptive/explanation tasks rather than evaluation or regime mapping. Clear context, but no formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer whether a trading strategy’s measured performance is distinguishable from luck. Returns the Probabilistic Sharpe Ratio (the probability the true Sharpe beats a benchmark, corrected for sample length, skew and fat tails), a bootstrap confidence interval, and the Minimum Track Record Length — how long the record would have to run before the claim could be made at all. Use this whenever someone quotes a Sharpe ratio, a win rate or a return and you need to know whether the number means anything. It will frequently say the evidence is too thin; that is the intended answer, not a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | concise returns the verdict, the headline statistics and the reasoning — enough to answer a user. full adds every bucket, every dropped point and the complete provenance list, and is much larger. | concise |
| selector | Yes | Which track record to analyse. | |
| confidence | No | ||
| trialSharpes | No | Per-period Sharpe ratios of other configurations tried for this strategy. Supplying them enables the Deflated Sharpe Ratio, which discounts the headline for how many variants were tested before this one was reported. | |
| benchmarkSharpe | No | Per-period Sharpe the record must beat. 0 asks only whether there is any edge at all. |
| Name | Required | Description |
|---|---|---|
| full | Yes | The complete report when detail is "full", otherwise null. |
| label | Yes | |
| notes | Yes | |
| verdict | Yes | One of insufficient_evidence, indistinguishable_from_luck, weak, supported, strong. |
| headline | Yes | |
| sourceId | Yes | |
| reasoning | Yes | |
| usableReturns | Yes | |
| deflatedSharpe | Yes | |
| sharpePerPeriod | Yes | |
| sharpeAnnualised | Yes | |
| probabilisticSharpe | Yes | |
| divergencesFromReported | Yes | |
| minimumTrackRecordLength | Yes | |
| sharpeConfidenceInterval | Yes | |
| periodsShortOfSignificance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive behavior, so the description adds meaningful extra context: it explains the output set and, importantly, that a verdict of insufficient evidence is intended rather than a failure. This warns the agent about a likely outcome without contradicting any annotation.
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?
Three well-structured sentences front-load the purpose, then cover return values, usage triggers, and expected behavior. There is no filler and every sentence earns its place.
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?
Given a rich schema, annotations, and an output schema, the description supplies everything an agent needs to decide when to call this tool and what to expect: purpose, outputs, usage cue, and a warning about the thin-evidence verdict. No important calling context 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 description coverage is 80%, so the schema already documents most parameters in detail. The description reinforces the statistical interpretation of the tool but does not add new meaning to individual parameters like confidence, benchmarkSharpe, or trialSharpes, which justifies the baseline score of 3.
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: it answers whether a strategy's measured performance is distinguishable from luck. It names concrete outputs (Probabilistic Sharpe Ratio, bootstrap confidence interval, Minimum Track Record Length) that make it clearly distinct from the factor, regime, and self-attack sibling tools.
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 an explicit trigger condition: use it whenever someone quotes a Sharpe ratio, win rate, or return and you need to know whether the number means anything. It does not name alternative tools or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break a strategy’s returns down by the market conditions that held on each date — volatility, funding, open interest, positioning, sentiment, trend state — and report performance per bucket. Each factor also gets a permutation test: the observed best-to-worst spread is compared against spreads produced by randomly reshuffling the regime labels, so a flattering subset cannot pass itself off as a regime effect. Use this after regimen_evaluate_track_record when you need to know WHERE an edge comes from, or whether it is a bet on conditions that could end.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | concise returns the verdict, the headline statistics and the reasoning — enough to answer a user. full adds every bucket, every dropped point and the complete provenance list, and is much larger. | concise |
| maxDates | No | How many of the most recent dates to read conditions for, bounded by the upstream rate limit. | |
| selector | Yes | Which track record to analyse. | |
| minSample | No | Buckets below this many observations are returned but flagged unusable. |
| Name | Required | Description |
|---|---|---|
| full | Yes | |
| label | Yes | |
| factors | Yes | |
| warnings | Yes | |
| minSample | Yes | |
| datesCovered | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint and openWorldHint annotations by explaining the permutation test methodology and its purpose—to prevent a flattering subset from passing as a regime effect. It also notes that buckets below minSample are flagged unusable (via schema). It does not contradict any annotation and adds meaningful behavioral context about the statistical safeguards.
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 three sentences with no wasted words. The first sentence states the core function, the second explains the permutation test, and the third gives usage guidance. The key 'after' relationship is front-loaded, and every sentence earns its place.
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 tool with a nested selector object, multiple parameters, and an output schema, the description covers the core concept, the statistical test, and the intended usage context. It does not explicitly detail the two selector sources or parameter specifics, but those are fully described in the schema. The reference to using it after regimen_evaluate_track_record provides the prerequisite context, making it adequately complete.
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 schema description coverage is 100%, so each parameter (detail, maxDates, selector, minSample) already has a detailed description. The tool description adds no additional parameter-level meaning; it focuses on the overall purpose and methodology. Since the schema carries the full burden, the baseline of 3 is appropriate.
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 verb ('Break a strategy’s returns down') with a clear resource (market conditions per date) and output (performance per bucket). It also distinguishes itself from the sibling regimen_evaluate_track_record by positioning itself as the follow-up that reveals where an edge comes from, which differentiates its purpose.
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 description explicitly says to use this tool after regimen_evaluate_track_record when you need to know WHERE an edge comes from or whether it is a bet on conditions that could end. It gives a clear trigger condition but does not explicitly mention when not to use it or name alternative siblings like regimen_describe_factors or regimen_self_attack, so it falls just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Regimen’s own analysis against controls whose answer is known in advance: the strategy’s returns with the edge mathematically removed, and a simulated population of strategies with no edge at all. Returns whether the engine correctly found nothing in them, and where the real strategy’s confidence sits among pure-luck strategies of the same length and volatility. Use this when a user is entitled to ask why they should believe the verdict, or before quoting a result as evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | Which track record to analyse. | |
| simulations | No |
| Name | Required | Description |
|---|---|---|
| label | Yes | |
| notes | Yes | |
| verdict | Yes | |
| controls | Yes | |
| nullDistribution | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the internal methodology—edge-removed returns and simulated no-edge strategies—and the exact nature of the output, which goes beyond the readOnly/destructive annotations. It also conveys that this is a statistical sanity check rather than a simple evaluation, adding useful behavioral context.
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?
Three sentences, each earning its place: what the tool does, what it returns, and when to use it. The core action is front-loaded and there is no filler or repetition.
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?
An output schema exists, so return-value details are already covered. The description provides enough purpose, method, and usage context for an agent to select and invoke the tool correctly; the only notable omission is explicit guidance about sibling tools, which is already accounted for in usage_guidelines.
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?
With only 50% schema description coverage, the description compensates by explaining the conceptual role of the simulations (pure-luck population with the same length and volatility) and how controls are constructed (edge mathematically removed). It does not map these concepts to parameter names directly, but the schema already documents the selector and simulation fields.
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 names a concrete operation—running Regimen's own analysis against known-answer controls—and specifies both the controls and the two outputs: whether the engine correctly found nothing, and where the real strategy's confidence sits among pure-luck strategies. This clearly distinguishes it from siblings like regimen_evaluate_track_record, which likely judges a track record directly, while this tool attacks the verdict itself.
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 description explicitly states when to use the tool: when a user is entitled to ask why they should believe the verdict, or before quoting a result as evidence. It does not name sibling alternatives or provide when-not-to-use conditions, so it stops short of full routing guidance.
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.
regimen_describe_factorsregimen_evaluate_track_recordregimen_regime_mapregimen_self_attackGrade a track record before risking capital: REAL_EDGE/REGIME_LUCK/NEGATIVE_EV. Fail-closed.
Honest A-F grades for trading strategies, backtested on real out-of-sample data. No hype.
Validated trading edges across futures, equities, crypto. Live signals, full audit trail.
Backtest plain-English trading strategies on real market data: graded results, honesty flags.
Add one secure layer between your agents and this server.
