Skip to main content
Glama

GammaRips Options Intelligence

by io.github.DevDizzle

Candidate Pool

get_pool
Read-onlyIdempotent
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

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish a safe read-only, idempotent profile, and the description adds substantial non-obvious behavior: anon calls to paid views return subscription_required, enriched is served from a leakage-safe view with outcome columns physically stripped, features lags by 1-2 trading days, the two rule eras are explicitly not one population, and recommended_spread_pct is permanently NULL. This is exactly the contextual depth that annotations alone cannot provide.

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?

The description is long, but every section earns its place: a bulleted view taxonomy up front, then tier and caveat paragraphs, then a compact Args block. The structure makes it scannable, and the density is justified for a 9-parameter, four-mode tool with auth gating.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description covers parameters, defaults, clamps, auth gating, null fields, data lag, and era differences, nearly everything needed to invoke it correctly. The only remaining gap is that return row shapes for the raw and features views are not enumerated the way enriched's ~21 decision columns and full-rows behavior are.

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 description coverage is 0%, so the Args block carries the entire burden, and it fully delivers: every one of the 9 parameters gets a value domain, default, view scoping, and clamps (min_score 0-10 raw-only, limit 1-50/100/20 by view, fields as a strict projection, offset enriched-only pagination). This completely compensates for the empty schema descriptions.

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?

The description defines get_pool as the GammaRips candidate pool and breaks it into four clearly distinct views (enriched, raw, features, preview), each with its own role and consumer. It differentiates from siblings inline, pointing to get_playbook for contract selection and get_liquidity for live re-checking, so an agent can tell exactly which resource this tool serves and how it differs.

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?

The description gives explicit when-to-use guidance: enriched is the daily candidate set the agent reasons over, features is the substrate for joining against query_outcomes, preview is named the free entry point, and raw is the pre-cut scan. It also names alternatives with conditions (get_playbook, get_liquidity) and states exclusions like view-scoped filters and the paid-tier requirement.

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

All GammaRips Options Intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool owns a clearly distinct surface: reports, liquidity, market calendar, methodology, pool data, regime context, per-ticker signals, outcome research, and raw price replay. Even the closest neighbors (get_pool, get_signal, get_daily_report) are separated by pool-wide versus single-ticker versus report granularity, and the view parameters remove ambiguity.

Naming Consistency4/5

Seven tools follow a consistent get_<noun> pattern, while query_outcomes and replay_contract deviate with a different verb style. All names are snake_case and predictable, so this is a minor inconsistency rather than chaotic naming.

Tool Count5/5

Nine tools is well within the ideal range for an intelligence and research server. Each tool earns its place, covering a distinct part of the workflow without bloat or thinness.

Completeness5/5

The toolset covers the full research workflow: market/reference context, methodology, candidate pool, live liquidity, per-ticker signals, regime context, outcome research, and raw price replay for custom exit rules. There are no obvious dead ends or missing lifecycle steps for the server's stated purpose.

Resources