Skip to main content
Glama

SCRIPTMASTERLABS — x402 Gateway

regime_scan_board

SML REGIME SCAN board (PAID $0.05 USDC on Base via x402). Dynamic scan of the most liquid US stocks and ETFs (no hard-coded watchlist: every US listing from the last completed session, filtered by price ≥ $5, volume ≥ 500k and dollar volume ≥ $25M, top ~400 by dollar volume). Reads the regime first (ADX + Choppiness → TREND / RANGE / TRANSITION), then one indicator per family — EMA21/50, SuperTrend+DMI, RSI+MACD, ATR/BB-width/squeeze, OBV+CMF+RVOL, Donchian/52w, CHOP/ER/Z/RS-vs-SPY, universe breadth — and returns the 15–25 tickers where the families agree. Each ticker: setup (TREND_CONTINUATION, TREND_PULLBACK, BREAKOUT, SQUEEZE_COIL, RANGE_STRETCH), bias, score 0–100, tier, trigger, invalidation, next level, reward-to-risk, RVOL, ATR%, a one-line why, the setup type's measured history on the scanned tickers (5/10-day forward move, +1R-before-invalidation rate, sample count), and a live price vs levels during market hours. Starts with a one-sentence answer. Completed daily bars only; nothing repaints. Use for: a ranked, ready-to-reason shortlist of US equities with aligned technicals today. Don't use when: you need raw bars or quotes, intraday timeframes, crypto spot, or order execution. Describes conditions; not buy/sell instructions or financial advice.

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": "regime_scan_board"
  }
}

Input Schema

NameRequiredDescriptionDefault
biasNoOnly return setups with this bias.
limitNoMax tickers (default all, up to 25).
setupNoOnly return this setup type.
payment_headerNoBase64 X-PAYMENT EIP-3009 payload (standard rail) for the tool price in USDC on Base.
wallet_addressNoAgent wallet address (informational).
payment_tx_hashNoBase USDC tx hash (sovereign rail) paying the tool price to the canonical SML receiver.
include_familiesNoInclude the 8 family readings and missing checks per ticker (longer answer).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the $0.05 USDC-on-Base x402 charge, that results use completed daily bars only and never repaint, that live price-vs-levels appears only during market hours, and that the response opens with a one-sentence `answer`. It also explains the payment rails in prose, which matters because readOnlyHint=false signals a side effect (spend) that the description confirms rather than contradicts.

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 and zero-waste in substance — name, price, and mechanism come first, followed by filters, output fields, then use/don't-use routing. The long middle enumeration of indicator families (EMA21/50, SuperTrend+DMI, RSI+MACD, ...) is dense in a single unbroken paragraph and could be shortened without losing decision value.

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?

There is no output schema, so the description carries the full burden of describing the return shape, and it does: the leading `answer` sentence, the per-ticker field list, and the measured setup history (forward move, +1R rate, sample count). Together with the liquidity filter thresholds and data-freshness caveat, an agent has everything needed to call it and read the result.

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

Parameters3/5

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

Schema description coverage is 100%, so bias, limit, setup, include_families and the two payment fields are already documented. The description names all five setup types and the 'up to 25' cap, but adds no guidance on how those filters interact or when to prefer one payment rail over the other. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Dynamic scan of the most liquid US stocks and ETFs') plus the exact output contract: 15–25 tickers where indicator families agree, each with setup, bias, score, trigger, invalidation. The scope ('no hard-coded watchlist... every US listing from the last completed session') separates it from a single-name scanner like regime_scan_ticker without needing to open 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 Guidelines4/5

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

Provides an explicit 'Use for:' clause and a clear 'Don't use when:' exclusion list (raw bars/quotes, intraday timeframes, crypto spot, order execution). The gap is that it never names the sibling to use instead — an agent told 'not raw bars' is not routed to a specific alternative, and 'regime_scan_ticker' for single-name checks is left implicit.

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