Skip to main content
Glama

Opportunity Scan

research_opportunities
Read-only

Cross-sectional opportunity scan across every major and medium-cap coin at once — the screener the per-coin tools cannot be looped into safely. Two whole-universe feeds (the merged market snapshot + venue perp contexts) build a liquidity-filtered universe and rank it, then candles are fetched for a bounded shortlist only; ZERO per-symbol calls are made to the rate-limited derivatives provider, which is what lets this cover a universe without silently degrading. Up to six signals per candidate: crowding (annualized funding vs the venue-standard anchor AND its percentile across the screened universe right now — a cross-sectional read, explicitly NOT the own-history percentile research_positioning reports), stress (24h liquidations as a share of open interest — whether forced sellers already cleared), leverage (open interest as a share of market cap — the gap-through-your-stop condition), compression (4h Bollinger bandwidth ranked against the coin's own trailing window — the per-coin form of the reading research_regime computes for BTC alone; says energy is loading, never direction), trend (ADX with the +DI/-DI separation on 4h, confirmed against 1d — the vote is withheld unless the slow timeframe agrees), and location (distance from the 4h EMA20 in ATR units — an extended coin scores DOWN, because a chase is not a setup). Each signal reports its state, the numbers, and a +1/0/-1 setup-quality vote; the setup name and score come from a disclosed rule shipped with every scan. Candidates carry ATR-and-structure geometry — a resting-limit entry at the EMA20 (never at market), a stop a full 2 ATR beyond it, and a target shaded inside the first structural level — priced so it feeds research_trade_plan directly. 'tier' filters major/medium/all; 'limit' caps the ranked list; 'symbols' narrows the universe to specific coins, and every symbol named there is accounted for individually in the response — selected, excluded by your own tier filter, below the liquidity floors (never screened, so no band was ever applied to it), below the tier floor, or not quoted at all — because mere absence from the ranked list conflates four different answers. Reports a board, not a forecast: the bands are disclosed constants chosen for plausibility with no backtest behind them, and 'NO CANDIDATES' is a real and frequent answer. Use it to pick what to look at, then research_positioning and ta_technicals on the two or three that stand out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoSize tier to screen: 'major' (market cap >= $10B), 'medium' ($300M-$10B), or 'all' (default).
limitNoRanked candidates to return. Default 10, max 25.
symbolsNoOptional: narrow the universe to these coin symbols, e.g. ["SOL","AVAX"]. Omit to screen everything that clears the tier and liquidity floors.
intervalsNoThe timeframe pair to analyse, FINEST FIRST: [fast] or [fast, slow]. Default ["4h","1d"]. This is the most consequential argument: entry, stop, target, ATR and every AT STRUCTURE verdict are measured on the fast timeframe, so changing it produces a DIFFERENT trade rather than a refinement of the same one — on one live BTC read the 1h pair put the entry 0.2% above spot while the 1d pair put it 10.7% below, with stops of 0.77% and 3.31%. Lookbacks are counted in candles, so the swing windows scale too (30 candles is 5 days at 4h, 7 hours at 15m). The second interval only CONFIRMS the first and must be slower; pass one interval to skip confirmation, which halves the candle cost and makes the trend vote abstain.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ruleNoThe exact rule that produced setup and score
caveatsNoWhat the scan cannot see, stated rather than implied
coverageNoWhat the scan actually looked at — read this before treating an empty candidate list as a quiet market
candidatesNo
requestedSymbolsNoOne entry per symbol named in the 'symbols' argument, so a symbol missing from 'candidates' can be explained. Empty when no symbols were named. A status other than 'selected' means no band was applied to that coin, so its absence says nothing about its setup.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / candidates / items / properties / geometry / description
      Previous value: -"ATR-and-structure prices, ready for risk_position_size. Absent for a setup with no priceable side (COILED) and for EXTENDED, where refusing to price a chase is the point."New value: +"ATR-and-structure prices, ready for research_trade_plan. Absent for a setup with no priceable side (COILED) and for EXTENDED, where refusing to price a chase is the point."
  2. Changed1 schema field changed
    • addedOutput schema / properties / requestedSymbols
      Added value: +{
      +  "description": "One entry per symbol named in the 'symbols' argument, so a symbol missing from 'candidates' can be explained. Empty when no symbols were named. A status other than 'selected' means no band was applied to that coin, so its absence says nothing about its setup.",
      +  "items": {
      +    "properties": {
      +      "detail": {
      +        "description": "The numbers behind the status, with the floor each was measured against",
      +        "type": "string"
      +      },
      +      "status": {
      +        "description": "selected | tier_excluded | below_liquidity_floors | below_tier_floor | not_quoted",
      +        "type": "string"
      +      },
      +      "symbol": {
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / intervals
      Added value: +{
      +  "description": "The timeframe pair to analyse, FINEST FIRST: [fast] or [fast, slow]. Default [\"4h\",\"1d\"]. This is the most consequential argument: entry, stop, target, ATR and every AT STRUCTURE verdict are measured on the fast timeframe, so changing it produces a DIFFERENT trade rather than a refinement of the same one — on one live BTC read the 1h pair put the entry 0.2% above spot while the 1d pair put it 10.7% below, with stops of 0.77% and 3.31%. Lookbacks are counted in candles, so the swing windows scale too (30 candles is 5 days at 4h, 7 hours at 15m). The second interval only CONFIRMS the first and must be slower; pass one interval to skip confirmation, which halves the candle cost and makes the trend vote abstain.",
      +  "items": {
      +    "enum": [
      +      "1m",
      +      "5m",
      +      "15m",
      +      "30m",
      +      "1h",
      +      "4h",
      +      "12h",
      +      "1d",
      +      "1w"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / coverage / properties / fastInterval
      Added value: +{
      +  "description": "The timeframe every level in this report is measured on",
      +  "type": "string"
      +}
    • addedOutput schema / properties / coverage / properties / slowInterval
      Added value: +{
      +  "description": "The confirmation timeframe; absent when only one interval was requested, in which case the trend vote abstains",
      +  "type": "string"
      +}
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds substantial behavioral context beyond that: zero per-symbol calls to the rate-limited derivatives provider (explaining why it is safe at scale), liquidity filtering before candle fetching, bounded shortlist, the six-signal construction with vote semantics, and the honest caveat that bands are disclosed constants with no backtest. It also discloses the tier/floor/symbol accounting contract so absence from the list is never ambiguous.

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 core differentiation is front-loaded in the first sentence and the operational cautions are placed well. It is dense and long — the per-signal enumeration is heavy and a few clauses (e.g. restating research_regime's BTC-only scope) could be trimmed — but nearly every sentence carries a distinct constraint or routing cue, so it stays justified.

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 need not be explained; the description instead covers everything else an agent needs — universe construction, signal definitions and vote polarity, geometry conventions, parameter effects, and failure-mode semantics. Given the tool's complexity, nothing material is left unspecified.

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?

Schema coverage is 100% and the schema itself is unusually rich (the 'intervals' description explains candle-cost, confirmation-slower rule, and timeframe scaling). The description still adds meaning on top: it clarifies that 'tier' filters major/medium/all, that 'limit' caps the ranked list, and that each symbol in 'symbols' is individually accounted for under five possible dispositions. That is real added semantics rather than repetition.

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 — a cross-sectional screener over the whole major/medium-cap universe — and immediately distinguishes it from the per-coin tools ('the screener the per-coin tools cannot be looped into safely'). It names the sibling tools it complements (research_positioning, research_regime, research_trade_plan, ta_technicals), so an agent can place it in the toolset without ambiguity.

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 workflow direction: 'Use it to pick what to look at, then research_positioning and ta_technicals on the two or three that stand out,' and notes geometry feeds research_trade_plan directly. It also states when the tool legitimately returns nothing ('NO CANDIDATES' is a real and frequent answer), which prevents the agent from treating an empty board as a failure.

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.

Resources