Skip to main content
Glama
DevDizzle

GammaRips Options Intelligence

Realized Outcomes

query_outcomes
Read-onlyIdempotent

Retrieve realized options outcomes, opportunity surfaces, and receipts across nine analytical views to research outcome distributions, design exit rules, and review paper-traded performance.

Instructions

The realized-outcome + receipts substrate behind the engine. One tool,
nine `view`s. Whole-pool composites under any FIXED exit are NEGATIVE by
construction — these are a research surface (how outcomes distribute
across features and exits), never a strategy track record.

  * view="labels" (DEFAULT) — row-level realized bracket LABELS joined to
    point-in-time features. horizon "same_day" (live V7.1 GIGO +40/-30) or
    "3d" (legacy +80/-60) — never pooled. NULL-label and illiquid rows
    excluded (counts in meta). `aggregate_only=True` returns summary stats
    instead of rows. Filters: scan_date_from/to, ticker, delta_min/max,
    min_overnight_score, exit_reason.
  * view="summary" — grouped aggregates over the labeled pool. `group_by`
    one of none|delta_bucket|overnight_score|premium_score|exit_reason|
    day_of_week|moneyness_bucket.
  * view="surface" — the OPPORTUNITY SURFACE: per-contract realized MFE/MAE
    excursions with NO exit applied (profit potential, exit free). Uses
    scan_date OR a `days` lookback, `ticker`, `delta_min/max`,
    `include_open`. `aggregate_only=True` returns MFE/MAE quantiles over
    the FULL filtered set — use it for exit design. The row mode is capped
    at 200 and truncates oldest-first WITHIN a scan_date, so its oldest
    date is a highest-MFE-only slice; it reports `truncated`,
    `matched_rows`, and `partial_scan_date` so you can see that happen.
  * view="harvest" — the touch-probability curve: P(premium touched +X%)
    with CIs, day-of-peak buckets, stop-touch rates. `targets`, `stops`,
    date range, delta band.
  * view="exit_rule" — RESEARCH-ONLY "bring your exit, we score it":
    rule="bracket" (target_pct/stop_pct) or rule="trailing" (trail_pct,
    activation_pct) scored against the surface / minute tape.
  * view="signal_performance" — UNDERLYING-STOCK direction outcomes for
    the broad pool (NOT option PnL). Filters scan_date, ticker, direction,
    outcome.
  * view="win_rate" — aggregate UNDERLYING-direction win rate over `days`
    (NOT option PnL; headline key carries its universe).
  * view="positions" — the RECEIPTS: realized (closed) paper trades from
    the engine's own daily pick, row-level, cohort-filtered
    (`policy_version`, default live). Over `days`, `limit`.
  * view="performance" — cohort AGGREGATE of the receipts over `days`
    (win rate, avg/median/best/worst), `direction`, `min_premium_score`,
    `policy_version`. When the cohort has no closed trades, every aggregate
    is `null` and `total_trades` is 0 — NEVER 0.0. A `null` here means "not
    measured yet", not "zero percent"; do not render it as a result.

All returns are FRACTIONS (0.40 = +40%). Realized data serves closed
windows only. Paper-traded research data; not investment advice.

Args:
    view: which surface (see above). Default "labels".
    horizon: "same_day" | "3d" (labels/summary/exit_rule). If omitted, the
        native default per view is used: labels/summary => "same_day" (the
        live GIGO policy), exit_rule => "3d" (its excursion window).
    group_by: summary grouping dimension.
    scan_date / scan_date_from / scan_date_to: date filters (per view).
    ticker / direction / delta_min / delta_max / min_overnight_score /
        exit_reason / outcome: row/aggregate filters (per view).
    days: lookback window (surface/win_rate/positions/performance).
    limit: max rows (labels 1-200, signal_performance 1-50, positions 1-200).
    aggregate_only: labels/surface views — summary stats instead of rows.
        On `surface` this is also the only mode immune to the 200-row cap.
    include_open: surface view — include not-yet-closed windows.
    targets / stops: harvest view — PERCENT grids.
    target_pct / stop_pct / rule / trail_pct / activation_pct: exit_rule view.
    policy_version: positions/performance cohort filter. The live default
        is the PAIR (policy label + cohort start date) — the label alone
        does not define the cohort, since disowned cohorts remain in the
        ledger under the same label. Responses carry `cohort_start`; a zero
        row_count under the live cohort means it has not accrued closed
        trades yet, not that there is no track record, and the aggregates
        come back `null` rather than 0.0. Pass "all" for every era, but
        note that "all" returns cohorts the engine has REPUDIATED — not
        merely older exit mechanics — so it is not a track record and must
        not be aggregated into one. Read the response `note` before
        quoting any number from it.
    min_premium_score: performance view floor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
ruleNobracket
viewNolabels
limitNo
stopsNo
tickerNo
horizonNo
outcomeNo
targetsNo
group_byNonone
stop_pctNo
delta_maxNo
delta_minNo
directionNo
scan_dateNo
trail_pctNo
target_pctNo
exit_reasonNo
include_openNo
scan_date_toNo
activation_pctNo
aggregate_onlyNo
policy_versionNoV7_1_TILTED_GIGO
scan_date_fromNo
min_premium_scoreNo
min_overnight_scoreNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this read-only, idempotent, and non-destructive; the description adds rich non-obvious behavior beyond that: the 200-row surface cap truncates oldest-first and reports truncated/matched_rows/partial_scan_date, null aggregates mean not measured yet rather than zero, and policy_version 'all' returns repudiated cohorts that must not be aggregated. It also warns fixed-exit composites are negative by construction and that data is closed-window paper research.

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 structure is excellent: high-level framing, bulleted views, then a parameter list, with the most important caveats front-loaded in the first paragraph. Its length is mostly justified by the tool's complexity, but it is not tight: policy_version/null semantics are explained twice and non-actionable boilerplate such as 'not investment advice' adds little.

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 high-complexity tool with no schema descriptions and no enums, the description is unusually complete: it covers return units, truncation behavior, cohort caveats, null conventions, and view-specific modes. It still leaves some string filter values implicit (e.g. allowed direction, outcome, and exit_reason values, and the expected scan_date format), and an output schema exists so return-shape details are not needed here.

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 and 26 parameters, the description carries the full burden and succeeds: it explains per-view filter applicability, horizon defaults, limit ranges, aggregate_only behavior, include_open semantics, and policy_version's pair-plus-cohort_start meaning. It also clarifies tricky distinctions such as same_day vs 3d and labels vs surface modes.

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 by identifying the tool as the realized-outcome and receipts substrate and then enumerates nine named views with distinct resources and verbs, e.g. labels row-level realized bracket labels, surface MFE/MAE excursions, positions receipts. This makes the tool's purpose unmistakable and separates it from the sibling signal/pool/report tools.

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?

Each view bullet is an applicability rule: aggregate_only on surface is explicitly 'use it for exit design', exit_rule is 'RESEARCH-ONLY bring your exit, we score it', and positions/performance are defined as receipts vs cohort aggregates. Negative guidance is also explicit: never pooled, never a strategy track record, NOT option PnL, and don't render null aggregates as results.

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