MangroveAI

get_market_regime

Read-onlyIdempotent

Classify an asset's regime using a lookback of 1-365 days of daily closes (default 180, the window strategy builds use): the return and a bull/neutral/bear band over 90, 180 and, for a 365-day lookback, 365 days, plus annualised volatility as a percentage, a bucket, and a z-score against the asset's own baseline; and the whole lookback in the sweep catalog's labels (direction, low/medium/high volatility for its asset class and length, and a clean/mixed/choppy trend). Use it before recommending a strategy style, because a mean-reversion design and a trend-following design suit opposite regimes. Covers crypto and the stocks, ETFs, commodities and bonds in Oracle's regime catalog: SPY, QQQ, DIA, IWM, AAPL, AMD, AMZN, COST, GOOGL, HD, JNJ, JPM, META, MSFT, NFLX, NVDA, PG, TSLA, UNH, WMT, XOM, GLD, SLV, USO, GOLD (gold futures), CRUDE (crude oil futures) and TLT. Without explicit source arguments, those tickers are read from their exchange-session daily series, even where a crypto token shares one (DIA and META are the ETF and the stock here); any other ticker is read as crypto, so a stock not named here cannot be read. Explicit market or provider arguments select the crypto history path. venue says which feed was read. A listed ticker needs at least 15 sessions with a close, about three weeks; anything shorter is refused as too little history. For a listed ticker the lookback is calendar days, so 365 reads about 250 sessions. For an exact crypto market, supply quote_token and market_data_venue together.

[Access: pay 0.02 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "asset": "<asset>"
    },
    "name": "get_market_regime"
  }
}

Input Schema

Name	Required	Description
`asset`	Yes	Asset symbol, e.g. BTC or ETH.
`provider`	No	Optional upstream override; omitted uses the existing server default.
`quote_token`	No	Quote currency of the requested market.
`lookback_days`	No	Number of days of history to request.
`market_data_venue`	No	Exact venue of the requested market.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026
- changedInput schema / properties / lookback_days / default
```
Previous value: -365New value: +180
```
First observedOct 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Well beyond the readOnly/idempotent annotations: it discloses the exact supported ticker universe, the ticker-resolution rules (bare tickers resolve to exchange sessions even when a crypto token shares the symbol; explicit market/provider args switch to the crypto path), a hard 15-session minimum that causes refusal, the calendar-day vs trading-session distinction for the lookback, and the x402/API-key payment split. These are precisely the failure modes an agent needs to avoid.

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?

Purpose is front-loaded and almost every clause carries operational information (universe, resolution rules, minimum history, payment). The main cost is the first sentence, a long comma-chained construction enumerating outputs that is harder to parse than a short bulleted list would be; the payment note is cleanly bracketed at the end.

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?

For a five-parameter, no-output-schema classification tool, the description covers what it returns, which assets are eligible, how symbols resolve, what causes a refusal, and how billing works. Nothing an agent needs to call it correctly or interpret a refusal is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds real meaning: default 180 is justified as 'the window strategy builds use', the 1-365 bound is stated, and the non-obvious coupling 'supply quote_token and market_data_venue together' for an exact crypto market is explained. It also clarifies that provider is an upstream override rather than a symbol selector.

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?

Opens with a specific verb+resource ('Classify an asset's regime') and immediately enumerates the outputs: multi-horizon returns, bull/neutral/bear bands, annualised volatility with bucket and z-score, and sweep-catalog labels. This is distinguishable from data-fetching siblings like get_market_data or get_ohlcv, which return series rather than a classification.

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?

Gives an explicit use case ('Use it before recommending a strategy style, because a mean-reversion design and a trend-following design suit opposite regimes'), which effectively routes the agent here ahead of strategy construction. It also states a clear exclusion boundary ('any other ticker is read as crypto, so a stock not named here cannot be read'). It does not name the specific sibling tool to call next, so it stops short of full alternative routing.

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

All MangroveAI 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.