Skip to main content
Glama

Futures Positioning (COT)

positioning
Read-only

⭐ How the FUTURES market is POSITIONED — the CFTC Commitment of Traders lens for commodities, FX, rates and equity indices (the non-equity TWIN of options_sentiment; the two together cover positioning for every asset class). Answers 'is this trade crowded?', 'is the smart money leaning the other way?', 'is the good news already priced into positioning?'. Returns: crowding (the speculative crowd at a 3-year extreme = a contrarian RISK, NOT a timing call), smart_vs_crowd (are commercial hedgers — who know the physical/fundamental side — leaning against the crowd), momentum (building or unwinding; a flip = regime change), fragility (a few big traders holding it = reverses fast), and ⭐ news_vs_positioning (does recent news CONFIRM the crowd → priced-in, or CONTRADICT a crowded position → unwind risk). Weekly, as of the prior TUESDAY. For a RATE/YIELD asset (.GB/.MM) a long futures = positioned for LOWER yields (the reads already say it that way). 🗣 Every feature carries a PLAIN read — narrate it in EVERYDAY language for a beginner (no 'net'/'percentile'/'basis' jargon); say what it MEANS for risk. Facts, not advice — the verdict is yours. A stock / uncovered asset → __notfound: say futures positioning doesn't apply and use options_sentiment / the news read instead.

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": {
      "q": "<q>"
    },
    "name": "positioning"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesA COMMODITY / FX / RATES / INDEX to read FUTURES positioning for — a concept IN ENGLISH (oil, gold, copper, natural gas, US 10Y treasury, euro, S&P 500; translate first) or a Ava Advisor ticker (WTI.COMM, US-10Y.GB, EURUSD.FOREX, SPY.US). NOT a single stock — a stock's positioning lives in OPTIONS, use options_sentiment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations supply only readOnlyHint=true, and the description fills in the rest richly: data source (CFTC), weekly cadence as of the prior Tuesday, the five named output reads and what each means, the sign convention for .GB/.MM rate assets, and the __notfound fallback for equities. It also flags that a crowding extreme is a contrarian risk signal rather than a timing call — genuine behavioral context beyond the annotation.

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 core purpose and the return-field catalogue, and every clause carries content. It is on the long side for a one-parameter tool — the emoji markers and inline caps-lock emphasis add visual noise — but no sentence is truly wasted.

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?

There is no output schema, and the description compensates by naming and interpreting all five returned features, including that each carries a plain-language `read` to narrate. Cadence, data vintage, failure mode, and asset-class boundary are all stated, so an agent has enough to call and interpret it correctly.

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% on the single parameter and the schema's own description already covers English-concept-vs-ticker input, translation, and the 'not a single stock' exclusion, so the description mostly restates it. What it does add is peripheral to the parameter itself (rate-asset sign convention, notfound handling), so baseline 3 is the right ceiling.

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 — the CFTC Commitment of Traders futures-positioning read for commodities, FX, rates and equity indices — and immediately frames it against options_sentiment (the 'non-equity TWIN'). An agent can tell what it returns and what asset classes it covers without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering questions ('is this trade crowded?', 'is the smart money leaning the other way?') plus explicit negative routing — a stock or uncovered asset returns __notfound and should go to options_sentiment or the news read. The only gap is that the sibling cot_extremes is never mentioned or differentiated, which is a real overlap an agent may not resolve on its own.

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.