GammaRips Options Intelligence
Server Details
Anti-firehose options-flow data for AI agents: curated daily pool, features, realized outcomes.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- DevDizzle/gammarips-mcp
- GitHub Stars
- 0
- Server Listing
- GammaRips Options Intelligence
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: daily report, liquidity, market calendar, playbook, pool, regime, signal, outcomes, replay. No overlap or ambiguity.
Most tools use 'get_' prefix, but 'query_outcomes' and 'replay_contract' break the pattern. However, the naming is still descriptive and follows a verb_noun convention, making it mostly consistent.
9 tools is well-scoped for the complex domain of options intelligence, covering data retrieval, analysis, and historical research without being excessive.
The tool surface covers all key areas: report, liquidity, calendar, methodology, candidate pool, regime, deep signal, outcomes, and price replay. No obvious gaps for the server's intelligence purpose.
Available Tools
9 toolsget_daily_reportAInspect
The daily intelligence report. Two `view`s:
* view="report" (DEFAULT) — the full report (title, markdown content,
scan_date) for `date`, or the most recent report if `date` is omitted.
* view="list" — recent reports, most recent first (scan_date, title,
created_at), titles deduped. Use `limit`.
Args:
date: report date YYYY-MM-DD (report view; default: most recent).
view: "report" (default) | "list".
limit: list view — how many reports (default 10, clamped 1-30).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| view | No | report | |
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behaviors: default date behavior, view options, limit clamping, and title deduplication in list view. No contradictions; annotations absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for views and args. Front-loaded with purpose. Could be slightly more concise but no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description details return fields for each view (title, markdown, scan_date for report; scan_date, title, created_at for list). Sufficient for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description fully explains all three parameters: date format YYYY-MM-DD, view values with defaults, limit range 1-30. Adds practical constraints and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves daily intelligence reports with two distinct views (report and list), each with specific behavior. Distinguishes from sibling tools like get_liquidity and get_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use each view (report vs list) and their parameters. Could further note that this tool is for report retrieval, while siblings serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_liquidityAInspect
FRESH (entry-day) liquidity — the read the pool's session-frozen
`recommended_oi`/`recommended_volume` cannot give you (the overnight sweep
only becomes OI the next morning). Two modes, chosen by whether you pass a
single `contract`:
* `contract` given — ONE contract's snapshot: open interest, session
volume, last trade, day range, underlying price, greeks. Cache-first
(the engine re-reads the pool every ~10 min in market hours); pass
live=true to force a fresh upstream fetch or read a contract NOT in
today's pool.
* `contract` omitted — the WHOLE current pool (or your `contracts`
shortlist, max 60) in ONE call — the batch companion for the ~10:00 ET
decision window. Most-recent read per contract with explicit `as_of`.
Deliberately serves NO bid/ask/mid/spread (not available on the current
data plan — absent, not NULL). Judge fill risk from open_interest (updates
once each morning), day_volume (live session), last_trade recency, and the
day range.
Args:
contract: OCC ticker for the single-contract mode (verbatim from the
pool's `recommended_contract`). Omit for the whole-pool batch.
scan_date: pool date YYYY-MM-DD (batch mode; default: latest pool).
contracts: optional shortlist filter for the batch mode (max 60).
live: single-contract mode — force a fresh upstream fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | ||
| contract | No | ||
| contracts | No | ||
| scan_date | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the responsibility of behavioral disclosure. It reveals cache-first behavior, the option to force a fresh fetch via live=true, and explicitly states that bid/ask are absent (not NULL) due to data plan limitations. It also explains the timing of data updates (overnight sweep, session volume).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured with sections (two modes, what it serves, Args). It is front-loaded with the core concept. A slight reduction in wording could improve conciseness, but it remains efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, cache behavior, no bid/ask), the description is complete. It covers all critical aspects: mode selection, data content, data freshness, limitations, and parameter explanations. The existence of an output schema reduces the need to explain return values here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description compensates with a dedicated 'Args:' section that explains each parameter in detail, including the roles of `contract`, `scan_date`, `contracts`, and `live`. This adds significant meaning beyond the raw schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'FRESH (entry-day) liquidity' and explains two distinct modes (single contract snapshot vs whole-pool batch). It uses specific verbs and resources, and the description is detailed enough to distinctly identify its function among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: the batch mode is for the '~10:00 ET decision window' and the single-contract mode for individual snapshots. It also advises what the tool does not provide (bid/ask) and how to judge fill risk. However, it does not explicitly contrast with sibling tools or state when not to use it, which would elevate the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_calendar_statusAInspect
Market-calendar reference. Two `view`s:
* view="status" (DEFAULT) — is the US equity market open today, plus the
next open/close, holiday, and early-close flags (NYSE calendar,
deterministic — no "is the market open?" hallucination).
* view="scan_dates" — which recent scan dates have GammaRips data, with
per-date signal counts (the pool's data-availability calendar).
Args:
view: "status" (default) | "scan_dates".
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | status |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the 'status' view is deterministic and based on NYSE calendar, preventing hallucination. This is good behavioral context, but it omits details like authentication requirements, rate limits, or side effects (though likely read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an introductory sentence, bulleted list of views, and an 'Args' section for the parameter. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's functionality for its complexity (one parameter, two views). It explains what each view provides. However, it does not describe the output format or return structure, which would be helpful since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions for the 'view' parameter (0% coverage). The description fully compensates by explaining the two allowed values ('status' and 'scan_dates') and their meanings, adding essential semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'Market-calendar reference' and enumerates two specific views with distinct purposes: checking US equity market status and checking data availability. It implicitly distinguishes from sibling tools (e.g., get_daily_report, get_liquidity) which focus on different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each view: view='status' for market open status and next events, view='scan_dates' for data availability. However, it does not explicitly state when not to use this tool or mention alternative tools, leaving slight gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_playbookAInspect
Methodology + reference, versioned server-side (re-fetch rather than
caching long-term). Arg-driven:
* `field` given — the plain-English DEFINITION + role of a signal field
(deterministic lookup, no LLM). e.g. field="mom_60". The response's
`available_fields` lists every documented field.
* `name` given — a methodology playbook (markdown) by name, OR two
special reference pages:
- name="schema" (or "data-contract") -> the machine-readable
substrate DATA CONTRACT: every outcome/label column with its
leakage classification (feature|label|opportunity|
regime_telemetry|identity) and as-of boundary. Only `feature`
columns are safe as selection inputs.
- any other name -> the playbook markdown (start-here,
daily-workflow, run-your-own-tournament, exit-lab,
leakage-and-data-contract, changelog).
* neither — the CATALOG of published playbooks (name/title/summary),
plus a pointer to the field dict (`field=`) and schema page.
Args:
name: playbook name, or "schema"/"data-contract" for the data contract.
field: a signal field name to explain (overrides `name`).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| field | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: deterministic lookup, no LLM, versioned server-side, re-fetch recommendation, and special name values. It lacks mention of error handling or rate limits, but given the read-only nature, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with bullet points and clear sections, making it easy to parse. It is somewhat long but each sentence adds value. Minor redundancy could be trimmed, but overall well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description hints at response contents (available_fields, markdown, catalog). It covers the three modes comprehensively. Could mention output format more explicitly, but sufficient for agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining exactly what happens for each parameter value: field gives definition, name gives playbook or special pages, neither gives catalog. It enumerates special name values and response contents, providing complete semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves methodology playbooks, field definitions, or a catalog, with three distinct modes spelled out. It uses specific verbs and resources, and differentiates from siblings implicitly by being a documentation reference tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each parameter (field, name, or none) and provides examples. It does not explicitly contrast with sibling tools or state when not to use, but it gives sufficient context for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_poolAInspect
The GammaRips candidate pool for a scan date. One tool, four `view`s:
* view="enriched" (DEFAULT) — the curated AI-enriched pool: news,
technicals, catalyst, a delta-targeted recommended contract, and the
60-day momentum feature `mom_60`. Enrichment gate: overnight_score>=4
AND directional UOA>$500K, edge-ranked to the top ~50 BULLISH names.
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 pre-curation overnight scan (where unusual
options activity concentrated across the whole universe, BEFORE
curation). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | enriched | |
| limit | No | ||
| fields | No | ||
| offset | No | ||
| ticker | No | ||
| summary | No | ||
| direction | No | ||
| min_score | No | ||
| scan_date | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses key behaviors: data freshness (scan-time snapshots), `recommended_spread_pct` being NULL, leakage-safe views, and authentication/subscription requirements for different views. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, bullet points, and sections for tiers, caveats, and arguments. It is front-loaded with the core purpose. However, it is somewhat verbose; some details could be condensed without losing clarity, but given the complexity it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description thoroughly explains what each view returns, including data limitations, column sets, and relationships to other tools. It covers all necessary context for an agent to correctly use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining all 9 parameters, including view options, filters, pagination, and view-specific constraints. However, some details like `scan_date` format could be more precise, but overall it adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as providing 'the GammaRips candidate pool for a scan date' with four distinct views, each with specific purposes and use cases. It distinguishes from sibling tools like `get_playbook` and `get_liquidity`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use each view, including the free tier (`preview`) and paid views, and recommends alternative tools like `get_playbook('run-your-own-tournament')` and `get_liquidity`. It also explains parameter filters and limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regime_contextAInspect
Point-in-time market-regime context for a scan date: VIX close, VIX3M,
SPY trend state, and the 5-day VIX delta — all as-of <= scan_date (the
selection point, leakage-safe), plus the engine's regime safety rail
evaluated on those values.
The rail: the engine fail-closes (no trade) when spot VIX > VIX3M
(backwardation — the market pricing imminent volatility is an adverse
regime for short-dated directional longs).
Served from the labeled substrate, which lags the live pool by ~1-2
trading days. Values are constant per scan_date.
Args:
scan_date: YYYY-MM-DD. Defaults to the latest scan date carrying
regime features.
Returns:
{scan_date, vix_at_scan, vix3m_at_enrich, spy_trend_at_scan,
vix_5d_delta_at_scan, regime_rail_pass, rail_definition}
| Name | Required | Description | Default |
|---|---|---|---|
| scan_date | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses critical behaviors: the engine fail-closes when VIX > VIX3M (backwardation), data lags the live pool by 1-2 days, and values are constant per scan_date. This provides rich behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but efficient, with a clear first sentence summarizing the tool's output. However, the docstring-style Args/Returns section adds length; a more front-loaded structure could improve readability without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema (described in Returns), the description covers all necessary context: input parameter, return fields, data freshness warning, and the critical regime rail logic. It is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter scan_date is well described: format (YYYY-MM-DD), default behavior (latest available scan date), and its role as the selection point. Schema description coverage is 0%, so the description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides point-in-time market-regime context for a scan date, listing specific fields (VIX close, VIX3M, SPY trend state, 5-day VIX delta, regime safety rail). This distinguishes it from sibling tools like get_daily_report or get_liquidity, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is used for a specific scan date, defaults to the latest, and is leakage-safe. However, it does not explicitly state when not to use it or compare to alternatives, missing a clear exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signalAInspect
Deep dive on a single ticker/contract. Two `view`s:
* view="detail" (DEFAULT) — the full enriched signal for one ticker:
thesis, catalyst, the recommended contract, and point-in-time
features (leakage-safe view). `full=true` includes the long narrative
(news_summary, flow_intent_reasoning). If the ticker isn't in the
pool for the date, the error lists the dates on which it does appear.
* view="earnings" — the doctrine earnings-window check (RM-003): the
next scheduled earnings date and whether it lands ON OR BEFORE the
contract expiration (`earnings_in_window`). The engine applies this
rail only at its own pick time, NOT in the pool, so pool rows CAN
carry earnings-window names — check every candidate yourself. Pass
the pool's `recommended_contract` and both ticker and expiration are
derived. FAIL-CLOSED: unknown date -> earnings_in_window=null, treat
as in-window.
Args:
ticker: underlying symbol (required for detail; optional for earnings
if `contract` is given).
view: "detail" (default) | "earnings".
scan_date: detail only — YYYY-MM-DD (default: latest for the ticker).
full: detail only — include the long narrative fields.
expiration: earnings only — option expiration YYYY-MM-DD to test.
contract: earnings only — OCC ticker supplying ticker+expiration.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| view | No | detail | |
| ticker | No | ||
| contract | No | ||
| scan_date | No | ||
| expiration | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is a read operation, describes fail-closed semantics (unknown date -> earnings_in_window=null, treat as in-window), error listing of dates, and parameter dependencies. No surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections, but somewhat lengthy. It earns its place by providing essential detail, but could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two views, multiple parameters, error cases, fail-closed behavior) and the presence of an output schema, the description covers all necessary context. It explains edge cases and usage patterns completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema (0% coverage). It explains each parameter's purpose, defaults, and dependencies (e.g., full includes long narrative, contract supplies ticker+expiration for earnings view). This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'deep dive on a single ticker/contract' with two views, distinguishing it from sibling tools like get_pool or get_playbook. The verb 'deep dive' and resource 'signal' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use each view (detail for full signal, earnings for earnings-window check). Provides guidance on error handling (ticker not in pool) and warnings about pool rows carrying earnings-window names, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_outcomesAInspect
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`, `include_open`.
* 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`.
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 view — summary stats instead of rows.
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 ("all" for every era).
min_premium_score: performance view floor.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| rule | No | bracket | |
| view | No | labels | |
| limit | No | ||
| stops | No | ||
| ticker | No | ||
| horizon | No | ||
| outcome | No | ||
| targets | No | ||
| group_by | No | none | |
| stop_pct | No | ||
| delta_max | No | ||
| delta_min | No | ||
| direction | No | ||
| scan_date | No | ||
| trail_pct | No | ||
| target_pct | No | ||
| exit_reason | No | ||
| include_open | No | ||
| scan_date_to | No | ||
| activation_pct | No | ||
| aggregate_only | No | ||
| policy_version | No | V7_1_TILTED_GIGO | |
| scan_date_from | No | ||
| min_premium_score | No | ||
| min_overnight_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description carries the full burden. It discloses that the tool is read-only ('realized data serves closed windows only'), returns fractions, and is paper-traded research. It also warns about negative composites. No annotation contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and dense, but well-structured with sections, bullet points, and an 'Args' list. While thorough, it could be more concise without losing crucial details. The front-loading is moderate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (26 parameters, 9 views, no annotations, output schema exists), the description is remarkably complete. It covers all views, parameter usage, defaults, warnings, and return formats. The output schema is present, so return values are handled externally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does so by explaining parameters in context of each view, grouping them logically. However, not every parameter is individually described (e.g., 'days' is mentioned only in some views). Still, the description adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides access to realized-outcome and receipts data with nine distinct views. It uses specific verbs like 'query' and 'substrate', and distinguishes each view. The purpose is unambiguous and distinct from sibling tools which focus on reports, liquidity, calendar, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive guidance is given for each view, including default horizons, filters, and what the view returns. Warnings about research-only surfaces and not being a track record are included. However, explicit when-not-to-use or direct comparison to alternatives within the sibling set is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replay_contractAInspect
Raw option price data for YOUR OWN entry/exit rule. This server does NOT
simulate or validate exits — it returns bars (the RM-002/RM-004 boundary).
Two `granularity` modes:
* granularity="minute" (DEFAULT) — the intraday minute path for one
session (`date` required). Optionally pass a bracket (target_pct/
stop_pct, PERCENT of the 10:00 ET anchor) and the response also reports
the exact FIRST-CROSSING sequence measured from the tape. Pool
excursion windows are served from the engine's minute-path table;
anything else falls back to an upstream minute fetch.
* granularity="day" — the DAILY mark series (OHLCV) over a date range,
to mark a live paper position day by day or replay a closed one. Uses
`from_date`/`to_date` (span capped at 120 days); `date` is ignored.
Option tape is THIN — minutes/days with no prints have no bar; treat
touch times as evidence, not tick-perfect truth. Paper-trade research
data; not investment advice.
Args:
contract: OCC option ticker (e.g. "O:UNIT260717C00030000").
date: minute mode — ET session date YYYY-MM-DD (required).
granularity: "minute" (default) | "day".
target_pct: minute mode — optional +X% level for first-crossing.
stop_pct: minute mode — optional -Y% level for first-crossing.
from_date: day mode — start YYYY-MM-DD (default: 30d before to_date).
to_date: day mode — end YYYY-MM-DD inclusive (default: today ET).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| to_date | No | ||
| contract | Yes | ||
| stop_pct | No | ||
| from_date | No | ||
| target_pct | No | ||
| granularity | No | minute |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job. It discloses that the tool returns bars (OHLCV), does not simulate exits, uses first-crossing logic, pool excursion windows, thin tape (no prints = no bar), and that data is for research only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for each granularity mode, front-loading the main purpose. It is slightly verbose but each sentence is informative and necessary given the tool's complexity. The organization makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, optional parameters, caveats about data quality) and the presence of an output schema (handling return values), the description provides complete context for an agent to understand when and how to use the tool, including limitations and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter in detail: contract, date, granularity, target_pct, stop_pct, from_date, to_date, including their defaults, constraints (e.g., date required for minute mode, day mode span capped at 120 days), and meaning. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides raw option price data for entry/exit rules, distinguishes between minute and day granularity modes, and explicitly says what it does NOT do (simulate or validate exits). It is specific about the resource (option contract) and action (replay/retrieve bars), and the sibling tools are different enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each granularity mode (intraday minute path vs daily marks over a date range) and the required parameters for each. It gives context but does not explicitly compare to sibling tools or state when not to use it, though the clear distinction from siblings makes it adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.