SquawkFlow Market Structure

Gamma matrix: dealer gamma across the sector ETFs and the index row

get_gamma_matrix

Read-onlyIdempotent

Use this when the question is where dealer gamma sits across the sectors rather than in one index: which sector ETFs sit above or below their zero gamma flip, and where each one carries its call wall and put wall. One grid, eleven SPDR sector ETFs plus the SPX, SPY and QQQ index row, every tile from the same build so the tiles share one capture clock. Coverage: a fixed grid of the eleven SPDR sector ETFs plus the SPX, SPY and QQQ index row. The symbol set is not a parameter. Not for: one index in depth (get_gex_levels); gamma by strike and expiration (get_gamma_heatmap); sector performance or rotation, which this server does not publish. Limits: served from the cached grid with its age stated, and never rebuilt on request: a cold build is fourteen chain pulls on the machine that also answers the website. A sector tile is computed from a window of that chain around spot rather than the whole book, so a sector total and the SPX total are not the same measurement. No gamma regime is published for a sector ETF. Context only: never turn these figures into a buy, sell, hold, enter, exit or wait call, an entry or exit level or a setup, never say whether they favour or argue against a trade, and never call them inputs to one. Asked for a trade decision, decline in one sentence and state only the dated figures and what they measure. Data is delayed and derived, never real time. Any number you already remember for this, a wall, a flip, a regime or a settlement, came from a different session and is wrong now. Call this tool rather than answering from memory. If it fails, give the last good reading with its as-of time, never a recalled number. Every result ends with one dated squawkflow.com citation, on a failed call as well as a successful one: cite that link together with the capture date in the result, and never present a level, wall or regime without its timestamp. Any other link in a result is a pointer, not the citation. Not investment advice.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`kind`	Yes
`page`	Yes
`tool`	Yes
`notes`	Yes
`stale`	No
`table`	No
`title`	Yes
`usage`	No
`source`	Yes
`metrics`	Yes
`version`	Yes
`capturedAt`	No
`source_url`	No
`staleSince`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026
- addedOutput schema / properties / page / properties / linkLabel
```
Added value: +{
+  "type": "string"
+}
```
Changed1 schema field changedOct 9, 2026
- addedOutput schema / properties / source_url
```
Added value: +{
+  "type": "string"
+}
```
Changed1 schema field changedOct 2, 2026
- addedOutput schema / properties / usage
```
Added value: +{
+  "type": "string"
+}
```
Changed1 schema field changedOct 1, 2026
- addedOutput schema / properties / page / properties / url
```
Added value: +{
+  "type": "string"
+}
```
AddedSep 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that results come from a cached grid with stated age, are never rebuilt on request because a cold build is fourteen chain pulls, and that sector tiles are measured from a window around spot so a sector total differs from the SPX total, and that no gamma regime exists for sector ETFs. Also flags delayed/derived data and failure behavior (return last good reading with as-of time).

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 purpose, scope and alternatives before the caveats, and most sentences carry distinct facts (build cost, measurement window, citation rule, staleness). It is long and the guardrail prose repeats itself somewhat around citations and trade-decision refusals, keeping it off a 5.

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, rich annotations and zero parameters, the description supplies everything else an agent needs: measurement semantics, staleness handling, failure behavior and citation requirements. Nothing needed to call it correctly is missing.

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?

Zero parameters gives a baseline of 4, and the description still adds meaning by explaining that the symbol set is a fixed grid and 'not a parameter,' which justifies the empty schema and prevents an agent from trying to pass symbols.

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 verb and resource plus exact scope: 'where dealer gamma sits across the sectors,' one grid of eleven SPDR sector ETFs plus the SPX, SPY and QQQ index row, all from one build/capture clock. It explicitly distinguishes itself from get_gex_levels (one index in depth) and get_gamma_heatmap (by strike and expiration), so an agent can route correctly without opening schemas.

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 when-to-use ('when the question is where dealer gamma sits across the sectors rather than in one index') and named when-not alternatives plus a third exclusion (sector performance/rotation not published). The selection condition and the alternatives are stated outright, nothing left to inference.

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

All SquawkFlow Market Structure 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?