Skip to main content
Glama

SquawkFlow Market Structure

CFTC futures positioning: long, short and net by trader classification

get_positioning
Read-onlyIdempotent

Use this when the question is how index futures positioning is distributed across trader classifications: dealers and intermediaries, asset managers, leveraged funds, other reportables and nonreportables, with long, short, spreading and net contracts and the week history. Omit the contract to list the published pages. Coverage: the CFTC Traders in Financial Futures futures-only report for the index futures SquawkFlow publishes a page for. Weekly US government data, not a market feed. Not for: options positioning or dealer gamma (get_gex_levels); commodity futures, which this server does not publish; any reading of the session in progress. Limits: positions are held as of the stated Tuesday and published the following Friday afternoon, so this is a weekly picture that is three days old by construction. Net is long minus short in contracts, an arithmetic difference between two published counts, not a sentiment reading. Contract markets with different index multipliers are never added together. 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
weeksNoWeekly readings of history to return, 1 to 52, oldest first.
contractNoA published page slug, for example sp500 or nasdaq100. Omit to list the pages. An unknown slug returns the list, never a similar page.

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.5/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses the Tuesday-as-of / Friday-publication lag, defines net as an arithmetic difference rather than sentiment, states that markets with different multipliers are never aggregated, and specifies failure handling (return last good reading with as-of time, never a recalled number) and citation obligations. That is substantive operational context an agent cannot get from the 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.

Conciseness3/5

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

Purpose and coverage are correctly front-loaded, but the body runs long with repetition ('not a market feed' / 'Data is delayed and derived, never real time', and a triple 'never ... never ... never' policy block). The compliance and citation material earns its place, but the same constraint is asserted two or three times.

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?

Covers the universe of published pages, the temporal semantics of the data, cross-market aggregation limits, and the output contract, with return values left to the existing output schema. Nothing an agent needs to call this correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and the contract parameter's omit-to-list behaviour is already documented in the schema, so the description's restatement adds little. The weeks parameter (1-52, oldest first) is never mentioned in the description, leaving the schema to carry it; baseline 3 is appropriate.

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 the precise resource (index futures positioning by trader classification, enumerating dealers, asset managers, leveraged funds, other/nonreportables) and the exact output shape (long, short, spreading, net plus week history). It also contrasts itself with get_gex_levels and with commodity futures, so the agent can distinguish it from siblings without opening a schema.

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 an explicit trigger ('Use this when the question is how index futures positioning is distributed...'), explicit exclusions ('Not for: options positioning or dealer gamma (get_gex_levels); commodity futures...; any reading of the session in progress'), and a fallback behaviour (omit contract to list pages). The alternative tool is named with the condition that selects it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources