Skip to main content
Glama
DevDizzle

GammaRips Options Intelligence

Candidate Pool

get_pool
Read-onlyIdempotent

Retrieve a curated daily options-flow pool in four views: enriched analysis, raw scans, feature vectors, or a free preview, and filter by direction, ticker, score, or scan date.

Instructions

The GammaRips candidate pool for a scan date. One tool, four `view`s:

  * view="enriched" (DEFAULT) — the AI-enriched pool: news, technicals,
    catalyst, the recommended contract (an OTM call chosen on contract
    liquidity), and the 60-day momentum feature `mom_60`. Funnel for
    scan_date >= 2026-08-24 (liquid-universe era): the 100 most liquid
    optionable names, BULLISH only, one call each, roughly 40-50 rows.
    Liquidity decides membership, not unusual activity; the $500K UOA
    floor is retired and `overnight_score>=1` is a cosmetic floor.
    Earlier scan dates come from the prior UOA-gated funnel (UOA>$500K,
    top-50 BULLISH); the two eras are not one population.
    This is the daily candidate set your agent reasons over to its OWN
    contract (see get_playbook("run-your-own-tournament")). Served from a
    leakage-safe view (forward-outcome columns physically stripped);
    `summary=True` gives ~21 decision columns, `fields=[...]` a strict
    projection, `summary=False` full rows, `offset` pages.
  * view="raw" — the wide overnight scan BEFORE the pool cut (the ranked
    liquid universe for scan_date >= 2026-08-24; the market-wide
    unusual-activity scan for earlier dates). Honors `direction`,
    `min_score`, `ticker`, `limit`.
  * view="features" — point-in-time FEATURE VECTORS from the leakage-safe
    allowlist view `enriched_features_v1` (identity + features + cohort
    metadata only; no outcome/label/telemetry column can appear). The
    quantitative substrate for joining against query_outcomes. Lags the
    live pool by ~1-2 trading days.
  * view="preview" — a minimal public teaser (ticker, direction, score,
    headline, directional UOA) for the most recent scan; no contract
    specifics or thesis.

TIER: view="preview" is FREE (no key). The enriched / raw / features views
are the paid product — they require an active pro subscription key; an anon
call to them returns `subscription_required` (get_pool(view='preview') is
named as the free entry point).

Liquidity caveat (all views): `recommended_oi`/`recommended_volume` are
scan-time snapshots, not live values; `recommended_spread_pct` is
permanently NULL on the current data plan — re-check with get_liquidity.

Args:
    view: "enriched" (default) | "raw" | "features" | "preview".
    scan_date: YYYY-MM-DD (default: latest available scan for the view).
    direction: "bull"/"bear" prefix filter (enriched / raw).
    ticker: exact ticker filter (enriched / raw / features).
    min_score: overnight_score floor (raw view only; clamped 0-10).
    limit: max rows (enriched/raw clamp 1-50, features 1-100, preview 1-20).
    summary: enriched only — True=compact columns, False=full rows.
    fields: enriched only — explicit strict column projection.
    offset: enriched only — pagination offset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoenriched
limitNo
fieldsNo
offsetNo
tickerNo
summaryNo
directionNo
min_scoreNo
scan_dateNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Far exceeds the readOnly/idempotent/non-destructive annotations by disclosing leakage-safe construction (outcome columns physically stripped), per-view freshness (features lag 1-2 trading days), snapshot semantics for recommended_oi/recommended_volume, permanent NULL for recommended_spread_pct, subscription gating (anon calls return subscription_required), and the two-era population discontinuity. No statement contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, and the body is partitioned with clear markers (view bullets, TIER:, Liquidity caveat:, Args:) so an agent can locate the relevant section quickly. Though long, the density is high: each paragraph covers a distinct concern (view semantics, access tier, data caveats, parameters) with no filler or repeated boilerplate. The length is proportionate to the tool's complexity.

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 present, the description compensates by describing each view's return shape: enriched has ~21 decision columns and names key fields (news, technicals, catalyst, recommended contract, mom_60); preview names its five fields; features is scoped to identity+features+cohort metadata; raw is the wide pre-cut scan. It also covers error behavior (subscription_required), defaults, pagination, and the liquidity caveat. The only absence is an exhaustive column-name list for the fields projection, which no schema exists to supply.

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?

With 0% schema description coverage, the Args section carries the full load and documents all nine parameters: allowed values for view, per-view applicability (min_score raw-only; summary/fields/offset enriched-only), clamps (enriched/raw 1-50, features 1-100, preview 1-20; min_score 0-10), and the YYYY-MM-DD format for scan_date. The schema itself only supplies titles and defaults, so this section is the agent's sole source of semantic meaning.

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 statement ('The GammaRips candidate pool for a scan date') and decomposes the tool into four distinctly described views, each with its own funnel logic, era, and output scope. It names related siblings (get_playbook, query_outcomes, get_liquidity) so the tool's role in the workflow is unambiguous. An agent can tell this from every sibling without opening another 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?

Explicitly directs when to use which view: enriched as the daily reasoning set for the agent's own contract, raw as the pre-cut scan, features for joining against query_outcomes, and preview as the named free entry point. It also names get_playbook('run-your-own-tournament') for the downstream step and get_liquidity for re-checking stale or NULL liquidity fields, and states the paid-versus-free tier rule that determines whether a call is even worth attempting.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DevDizzle/gammarips-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server