Skip to main content
Glama

SquawkFlow Market Structure

by com.squawkflow.mcp
OverviewDiscussionsAdmin

SquawkFlow session record: what was published before a session

get_session_record
Read-onlyIdempotent

Use this when the question is what SquawkFlow published for a given trading day before it traded, and what the record says happened to those levels. Returns the dated record for one session: the levels as published, the verdict on each one, the capture coverage, how the published levels moved from the prior session, and whether the record has settled or is still open. This is the dated tool on this server: pass a date to ask about a past session. Coverage: one SPX session per call, for the dates the published index lists. The index is the whole coverage: a date it does not list has no record here. Not for: the current reading (get_gex_levels); any rate, share or frequency computed across sessions, which this server does not compute; any forward statement about a session that has not happened. Limits: one session per call. No session price extremes are published through this tool: the open, close, high and low on the record are vendor-derived and are not relayed, nor is any comparison computed from them. A weekend or a holiday returns that it was not a session, which is a different answer from a missing record. 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

NameRequiredDescriptionDefault
dateNoISO session date. Omit for the most recent published record. A date the published index does not list returns that answer rather than an error.

Output Schema

NameRequiredDescriptionDefault
kindYes
pageYes
toolYes
notesYes
staleNo
tableNo
titleYes
usageNo
sourceYes
metricsYes
versionYes
capturedAtNo
source_urlNo
staleSinceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / page / properties / linkLabel
      Added value: +{
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedOutput schema / properties / source_url
      Added value: +{
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedOutput schema / properties / usage
      Added value: +{
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedOutput schema / properties / page / properties / url
      Added value: +{
+  "type": "string"
+}
  5. Added

TDQS

A4.7/5.0
Behavior5/5

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

Well beyond the readOnly/idempotent annotations: discloses that weekends/holidays return a distinct 'not a session' answer versus a missing record, that open/close/high/low are vendor-derived and withheld, that data is delayed, that results carry a dated citation even on failure, and what to do if the call fails. These are non-obvious behavioral traits an agent could not infer from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are correctly front-loaded, but the description is unusually long and reiterates the trading-advice prohibition across several sentences ('never turn these figures into...', 'never say whether they favour...', 'Asked for a trade decision, decline...'). Much of it earns its place as compliance context, yet the safety language could be tightened without losing meaning.

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?

Given a single optional parameter and an output schema, the description covers everything an agent needs: coverage boundaries, what the record contains, absent fields, failure handling, and citation requirements. Nothing material is missing for correct invocation and interpretation.

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% and the schema already explains the ISO date format, the omit-for-latest default, and unlisted-date behavior. The description adds interpretive meaning: the published index defines the entire valid coverage, and a non-session date is a different answer from a missing record — useful semantics the schema does not fully spell out.

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?

Opens with a specific condition and resource: the dated SquawkFlow record for one session, listing exactly what it contains (published levels, verdicts, capture coverage, move from prior session, settled/open status). It explicitly contrasts itself with get_gex_levels as 'the dated tool on this server', so an agent can distinguish it from siblings 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 ('pass a date to ask about a past session'), when-not ('the current reading (get_gex_levels)', cross-session rates, forward statements), and names the alternative tool. It also pre-empts the trade-decision use case with a prescribed decline response.

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 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