Skip to main content
Glama

GammaRips Options Intelligence

Realized Outcomes

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

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds substantial behavioral context: returns are fractions, only closed windows are served, row-level surface output truncates oldest-first and reports that truncation, null aggregates mean 'not measured yet' rather than zero, and policy_version carries cohort-start semantics. This is exactly the kind of context that prevents misuse.

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 tightly organized: a front-loaded framing, nine scannable view bullets, and a complete Args list. Every paragraph adds necessary cautions or semantics, and repeated warnings address high-cost misinterpretations rather than padding the text.

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?

For a tool with nine view modes and 26 parameters, the description covers selection criteria, defaults, units, truncation behavior, null semantics, cohort disclaimers, and research-only boundaries. Since an output schema exists, the absence of detailed return-field documentation is acceptable; the description covers everything needed to call the tool correctly.

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?

The input schema has 26 parameters and 0% description coverage, so the description carries the full burden. It defines every parameter in the Args section, including valid values for horizon, rule, and group_by, per-view applicability, limit ranges, defaults, and the nuanced behavior of policy_version. This fully 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 clearly identifies the tool as querying realized outcomes and receipts across nine distinct views. It distinguishes itself from strategy-performance reporting by emphasizing that pooled composites are a research surface, never a strategy track record. This gives an agent a precise mental model of what resource the tool operates on.

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 comes with an explicit use case and often a warning: use surface for exit design, harvest for touch probability, positions/performance for receipts, and exit_rule only for research. It also provides strong when-not guidance: never treat repudiated cohorts as track records, do not render null aggregates as 0.0, and do not confuse underlying-direction outcomes with option PnL.

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.

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.