Skip to main content
Glama

classify_market_segment

Read-onlyIdempotent

Classify one stretch of market: a date range, or a catalog window by file name. Explicit date ranges require daily (1d) candles; catalog windows retain their stored interval. Returns its direction band, volatility band, trend character and the three features behind them, using the same labels the sweep catalog carries. Use it for a period the person names, or to see what a window a sweep selected contains. For an asset's current conditions use get_market_regime instead. Volatility reads unscored when no fitted band covers the stretch's length; the bands come back with it. For an exact crypto market, supply quote_token and market_data_venue together. A date range 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.

[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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "classify_market_segment"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetNoAsset symbol, e.g. BTC or ETH.
end_dateNoISO end of the window.
providerNoOptional upstream override; omitted uses the existing server default.
start_dateNoISO start of the window, e.g. 2026-01-01.
candle_sizeNoDuration of one candle, e.g. 1h or 1d.1d
quote_tokenNoQuote currency of the requested market.
window_fileNoA catalog window's file name, classified as it stands. Supply this or the asset with both dates, not both.
market_data_venueNoExact venue of the requested market.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover the read-only/idempotent profile, and the description goes well beyond them: explicit date ranges force 1d candles, volatility returns `unscored` when no fitted band covers the stretch, ticker routing defaults (listed symbols read from exchange-session daily series even when a crypto token shares the name), and the x402/API-key access model.

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?

Front-loaded with the core action and the alternative, and nearly every sentence carries routing or constraint information. It runs long and the ticker enumeration plus the access note make it dense, but there is little that could be cut without losing caller-relevant detail.

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 no output schema, the description still tells the agent what comes back (direction band, volatility band, trend character, the three features, and the venue read). It covers routing, minimum-history refusal, fallback labels, and payment/auth, leaving nothing an agent needs to call it correctly.

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 100%, but the description adds non-obvious meaning the schema lacks: quote_token and market_data_venue must be supplied together for an exact crypto market, explicit date ranges require 1d candles regardless of candle_size, and window_file versus asset+dates are mutually exclusive. It also explains which tickers are routable and that unlisted tickers fall back to crypto.

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?

States a specific verb and resource ('Classify one stretch of market') and enumerates the two input modes (date range vs catalog window). It explicitly contrasts with the sibling get_market_regime, so an agent can pick without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit selection rules: use this for a named period or to inspect a sweep-selected window, and use get_market_regime for an asset's current conditions. It also names the threshold condition (at least 15 sessions, about three weeks) under which the call is refused.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.