QuantGeeks GEX

Expiration map

quantgeeks_get_expiration_map

Read-onlyIdempotent

Requires a QuantGeeks plan; not available without signing in (the call asks the user to sign in) or with a free account (the call says it needs a plan). Forward expirations side by side for swing setups: the next few listed expirations, each with its primary and two major nodes, its total size in the strike window, and how its primary moved since the prior close, plus the summed book for everything within 35 days. The horizon is 35 calendar days. expirations is a count (default 5, at most 8) or a list of dates; center, or from_strike and to_strike, set the strike window (default 15 strikes each side of spot, at most 40); date reads a past session's close. size is QuantGeeks GEX (flow-based) by default; measure 'vex' returns VEX (vanna exposure) instead; size_oi is open-interest-based GEX, for comparison (GEX only). Sizes compare within one expiration. For one expiration's full ladder use quantgeeks_get_gex_ladder; for the same-day nodes over time, quantgeeks_get_node_history.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "quantgeeks_get_expiration_map"
  }
}

Input Schema

Name	Required	Description
`date`	No	Session date, YYYY-MM-DD (US Eastern): that session's close. Default: the latest session.
`center`	No	Strike the window is centered on (default: spot).
`symbol`	Yes	Ticker, e.g. SPX (maps to its 0DTE option root SPXW), SPY, QQQ, VIX.
`measure`	No	'gex' (default): QuantGeeks GEX (gamma exposure); 'vex': VEX (vanna exposure). Every number and node in the answer is in the measure it says.
`strikes`	No	Strikes on each side of the center (default 15, at most 40).
`to_strike`	No	Highest strike of the window.
`expirations`	No	A count of the next listed expirations (default 5, at most 8) or a list of YYYY-MM-DD dates within 35 days.
`from_strike`	No	Lowest strike of the window.

Output Schema

Name	Required	Description	Default
`date`	Yes
`spot`	No
`as_of`	Yes
`notes`	No
`access`	Yes
`notice`	Yes
`source`	Yes
`symbol`	Yes
`account`	No
`horizon`	No
`measure`	No
`message`	No
`preview`	Yes
`pro_plan`	No
`aggregate`	No
`truncated`	No
`expirations`	No
`measure_note`	No
`oi_layer_note`	No
`truncated_more`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further by disclosing the plan gating and that unauthenticated calls surface a sign-in prompt while free accounts get a plan requirement. It also discloses the 35-day horizon cap and the within-expiration comparison rule, which are behavioral constraints not present in structured fields.

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?

Dense and largely front-loaded, with the access precondition first and the return shape immediately after. It is packed with run-on clauses around the node/size explanation, but essentially every sentence carries a fact an agent needs; only the access-gating sentence is arguably better placed later.

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?

An output schema exists, so return values need no prose. For an 8-parameter read-only analytics tool, the description covers access requirements, horizon, window construction, measure choice, and sibling alternatives, leaving no material gap before the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds real value by clarifying that `center` and the `from_strike`/`to_strike` pair are alternative ways to set one window, and by explaining the measure distinction in interpretive terms. One weakness: it references `size` and `size_oi` selectors that do not appear in the input schema, which could send an agent looking for parameters that are not there.

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 concrete verb and resource: forward expirations side by side, each with its primary and two major nodes, total size in the strike window, and change since prior close, plus a summed book within 35 days. The scope (35 calendar day horizon) and the swing-setup framing make it distinguishable from a single-expiration ladder or a node time series.

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?

Gives explicit routing: 'For one expiration's full ladder use quantgeeks_get_gex_ladder; for the same-day nodes over time, use quantgeeks_get_node_history.' It also frames the intended use case ('for swing setups') and adds the interpretive caveat 'Sizes compare within one expiration,' so an agent knows the comparison constraints before calling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All QuantGeeks GEX tools Inspect

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

Need Help?