Skip to main content
Glama

GammaRips Options Intelligence

by io.github.DevDizzle
OverviewDiscussionsAdmin

Market Calendar Status

get_market_calendar_status
Read-onlyIdempotent
Market-calendar reference. Three `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 raw scan's data-availability calendar).
  * view="freshness" — is the pool you are about to trade the right pool?
    Returns schema "pool-freshness/1": expected_scan_date (the last NYSE
    session before today), each pipeline stage (scan, enrichment,
    liquidity) with its latest date, row count for the expected date,
    and ok (true / false = overdue / null = could not check); the
    enrichment stage also gives expected_rows (the rows the enrichment
    filter must produce, so rows < expected_rows is a partial pool); the
    scan_date get_pool(view="enriched") serves by default
    (pool_scan_date) and its row count (pool_rows), `fresh`, and machine
    `reasons` (scan-stale, enrichment-stale, liquidity-stale, pool-stale,
    pool-empty, unknown-<stage|pool>). Fail-closed: an unknown is never
    fresh. A stage not yet due reports ok=true, due=false; before the
    06:00 ET enrichment, fresh is false with reason pool-stale because
    the next pool does not exist yet. No row floor is applied; apply
    your own to pool_rows. Cached up to 60 s.

Args:
    view: "status" (default) | "scan_dates" | "freshness".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNostatus

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / view
      Added value: +{
+  "default": "status",
+  "title": "View",
+  "type": "string"
+}
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "get_market_calendar_statusDictOutput",
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover read-only/idempotent/non-destructive, but the description adds substantial behavior: deterministic NYSE calendar (explicitly anti-hallucination), fail-closed semantics (unknown is never fresh), 60s caching, stage-not-yet-due ok=true/due=false, and the pre-06:00 ET pool-stale case. This is rich context an agent cannot get from the annotations.

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?

Front-loaded with the three-view list and organized with bullets, so it scans well. The freshness bullet is dense with reason codes and edge cases, which mostly earn their place but make the block heavy relative to the other two views.

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 no output schema, the description must explain returns, and it details the freshness view's fields (expected_scan_date, per-stage dates, expected_rows, pool_scan_date, fresh, reasons) plus status and scan_dates contents. An agent has enough to call and interpret 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 schema lists the view parameter with 0% description coverage, so the description carries the full burden — and it does, naming all three enum values, marking status as default, and explaining the meaning and return shape of each. Well beyond the bare schema.

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?

States a specific resource (market-calendar reference) and enumerates three concrete modes with distinct purposes. An agent can tell instantly that this answers calendar/pool-freshness questions rather than anything the siblings (get_pool, get_daily_report, get_liquidity) do.

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 is framed by the question it answers, including view="freshness" being tied explicitly to the pool you are about to trade and cross-referencing get_pool(view="enriched"). The default is called out, so routing between views is unambiguous.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources