Skip to main content
Glama

GammaRips Options Intelligence

Realized Outcomes

query_outcomes
Read-onlyIdempotent
The realized-outcome history behind the pool: use it to set a target and
a stop from what past pool contracts actually did. One tool, nine
`view`s. A pool-wide result under one fixed exit describes that one rule,
not a forecast for the plan you build.

  * 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" — history of a RETIRED engine test: closed paper
    trades from the engine's former one-pick-a-day tournament under one
    fixed exit (retired 2026-09-28). Not the product and not the pool; do
    not use it to judge the pool. Row-level, over `days`, `limit`.
  * view="performance" — aggregate of that retired test over `days`
    (`direction`, `min_premium_score`, `policy_version`). Same caveat:
    history of one retired rule, not a GammaRips result. When it has no
    closed trades, every aggregate is `null` and `total_trades` is 0.

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.

  1. Changed19 schema fields changed
    • addedInput schema / properties / activation_pct
      Added value: +{
      +  "default": 0,
      +  "title": "Activation Pct",
      +  "type": "number"
      +}
    • addedInput schema / properties / days
      Added value: +{
      +  "default": 30,
      +  "title": "Days",
      +  "type": "integer"
      +}
    • addedInput schema / properties / direction
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Direction"
      +}
    • addedInput schema / properties / group_by
      Added value: +{
      +  "default": "none",
      +  "title": "Group By",
      +  "type": "string"
      +}
    • addedInput schema / properties / horizon / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / horizon / default
      Previous value: -"same_day"New value: +null
    • removedInput schema / properties / horizon / type
      Removed value: -"string"
    • addedInput schema / properties / include_open
      Added value: +{
      +  "default": false,
      +  "title": "Include Open",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / min_premium_score
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Min Premium Score"
      +}
    • addedInput schema / properties / outcome
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Outcome"
      +}
    • addedInput schema / properties / policy_version
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": "V7_1_TILTED_GIGO",
      +  "title": "Policy Version"
      +}
    • addedInput schema / properties / rule
      Added value: +{
      +  "default": "bracket",
      +  "title": "Rule",
      +  "type": "string"
      +}
    • addedInput schema / properties / scan_date
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Scan Date"
      +}
    • addedInput schema / properties / stop_pct
      Added value: +{
      +  "default": 30,
      +  "title": "Stop Pct",
      +  "type": "number"
      +}
    • addedInput schema / properties / stops
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "number"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Stops"
      +}
    • addedInput schema / properties / target_pct
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Target Pct"
      +}
    • addedInput schema / properties / targets
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "number"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Targets"
      +}
    • addedInput schema / properties / trail_pct
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Trail Pct"
      +}
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "labels",
      +  "title": "View",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), but the description adds substantive behavior beyond them: NULL-label and illiquid row exclusion, the 200-row cap truncating oldest-first WITHIN a scan_date plus truncated/matched_rows/partial_scan_date reporting, null-vs-0.0 aggregate semantics, repudiated cohort caveats, and a read-the-note warning.

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?

Very long, but proportionate to nine views and 26 parameters, front-loaded with the framing sentence and organized as scannable bullets. A few caveats (retired-test warnings) are restated in two places, which is slight redundancy rather than waste.

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, yet the description still flags the response 'note', cohort_start, and null aggregate behavior. Given 26 params, nine modes, and a mutation-free read tool, nothing an agent needs to call this correctly is missing.

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% across 26 params, so the description must carry the full burden, and it largely does: per-view applicability, defaults per view, limit ranges (labels 1-200, signal_performance 1-50, positions 1-200), grid units (PERCENT grids), fraction return units, and the policy_version label+cohort_start pairing nuance. Only delta_min/delta_max are named without elaboration.

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 concrete verb+resource framing ('the realized-outcome history behind the pool') and then enumerates all nine views with distinct semantics, making it unmistakable against siblings like get_pool or get_playbook. An agent knows exactly what each view returns without opening the 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?

Explicit routing guidance throughout: 'use it to set a target and a stop', 'use it for exit design', 'do not use it to judge the pool', 'RESEARCH-ONLY', plus the warning that a pool-wide result under a fixed exit 'describes that one rule, not a forecast'. Alternatives and exclusions are stated, not implied.

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.