f1ow

Market Regime

research_regime

Read-only

Deterministic market-regime classification across seven axes: trend (Mayer Multiple bands vs the 200-day SMA), volatility (30d realized, percentile vs own history), cycle (a ~30-indicator top checklist incl. MVRV Z-Score, NUPL, Pi Cycle, AHR999), sentiment (Fear & Greed level, trajectory and percentile), leverage stress (derivatives-risk-index percentile), liquidity (7d spot-ETF net flows vs prior 7d), and rotation (Altcoin Season index, BTC dominance, ETH/BTC 30d). Each axis reports its state, the numbers behind it, and a +1/0/-1 vote; the overall posture is the disclosed sum-of-votes rule, with one exception — while 30d realized volatility sits at or below its 5th percentile the tape is compressed, trend structure stops being tradeable, and the Trend axis's vote is withheld (its reading is still reported). Compression is flagged structurally, and adds an informational, never-voting asymmetry lean naming which side is more exposed. Includes explicit 'would change the call' thresholds to watch. Rule-based and deterministic — same inputs, same read. Useful as a first call: most other signals (funding, sentiment, flows) read differently depending on this regime.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`axes`	No
`options`	No	Informational BTC/ETH implied-vol context from Deribit options (DVOL, ATM IV term structure, IV vs realized, 25-delta skew) and the modeled options regime (under gamma). Never votes.
`posture`	No	Overall risk-posture label
`asymmetry`	No	Which side is more exposed while compressed; a lean with a stated confidence, never a vote. Absent unless the tape is compressed and at least two of its inputs are meaningful
`axesTotal`	No
`compressed`	No	30d realized vol at or below its 5th percentile — while true the Trend axis contributes 0 to the posture whatever its state
`postureRule`	No	The exact rule that produced posture
`wouldChange`	No	Thresholds that would flip an axis
`axesComputed`	No
`volatilityPercentile`	No	30d realized-vol percentile vs own history; absent when no candle history was available, which is not the same as not compressed

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedOutput schema / properties / options

Added value: +{
+  "description": "Informational BTC/ETH implied-vol context from Deribit options (DVOL, ATM IV term structure, IV vs realized, 25-delta skew) and the modeled options regime (under gamma). Never votes.",
+  "type": "object"
+}

Changed3 schema fields changedAug 21, 2026

addedOutput schema / properties / asymmetry

Added value: +{
+  "description": "Which side is more exposed while compressed; a lean with a stated confidence, never a vote. Absent unless the tape is compressed and at least two of its inputs are meaningful",
+  "properties": {
+    "detail": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "state": {
+      "type": "string"
+    },
+    "vote": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / compressed

Added value: +{
+  "description": "30d realized vol at or below its 5th percentile — while true the Trend axis contributes 0 to the posture whatever its state",
+  "type": "boolean"
+}

addedOutput schema / properties / volatilityPercentile

Added value: +{
+  "description": "30d realized-vol percentile vs own history; absent when no candle history was available, which is not the same as not compressed",
+  "type": "number"
+}

First observedAug 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the core aggregation rule (sum of votes), a specific exception (Trend vote withheld when 30d realized vol is at/below its 5th percentile), that compression is flagged structurally, that the asymmetry lean is informational and never votes, and that thresholds for changing the call are included. That is unusually rich behavioral disclosure for a read-only tool and directly informs how the agent should interpret output.

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?

The purpose is front-loaded in the first clause, and the dense enumeration that follows is information-bearing rather than filler. It is a long single paragraph, though, and the seven-axis catalog could be tightened; a bulleted structure would aid scanning, so it falls short of a 5.

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?

With an output schema present, return values needn't be explained, and there are no parameters to document. What remains — what the tool computes, how votes combine, the volatility-compression exception, and the deterministic guarantee — is fully covered, leaving no gap an agent would need to guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. No parameter-related content is missing or misleading.

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?

The description names a specific verb and resource — 'deterministic market-regime classification' — and then enumerates the seven axes it covers, including the exact indicators used per axis. This is clearly distinct from siblings like research_opportunities, research_trade_plan, or market_overview, so an agent can select it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage context: 'Useful as a first call: most other signals (funding, sentiment, flows) read differently depending on this regime,' which tells the agent where this sits in a call sequence. It stops short of naming specific alternatives or stating when NOT to use it, keeping it at a 4 rather than a 5.

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

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