Skip to main content
Glama

Cftc Cot

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Latest Report

latest_report
Read-onlyIdempotent

Most recent weekly COT positioning for one futures market. Pass the exact market_and_exchange_names from search_markets, e.g. "CRUDE OIL, LIGHT SWEET-WTI - NEW YORK MERCANTILE EXCHANGE" or "GOLD - COMMODITY EXCHANGE INC.". Returns open interest plus long/short/net for non-commercial (≈ speculators: managed money / large traders), commercial (≈ hedgers / producers), and non-reportable (small traders), with this week's changes. Keyless.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
market_nameYesExact market_and_exchange_names from search_markets, e.g. "CRUDE OIL, LIGHT SWEET-WTI - NEW YORK MERCANTILE EXCHANGE".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "market_name": "CRUDE OIL, LIGHT SWEET-WTI - NEW YORK MERCANTILE EXCHANGE"
-  }
-]New value: +[
+  {
+    "market_name": "CRUDE OIL, LIGHT SWEET - NEW YORK MERCANTILE EXCHANGE"
+  }
+]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "market_name": "CRUDE OIL, LIGHT SWEET-WTI - NEW YORK MERCANTILE EXCHANGE"
+  }
+]
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond that: what data is returned (open interest, long/short/net for non-commercial, commercial, and non-reportable traders) and the 'this week's changes' detail, plus the keyless access note.

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

Conciseness5/5

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

The description is a single dense, well-ordered paragraph: purpose first, then input instructions with examples, then return content, then the keyless note. Every sentence earns its place with no filler.

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 only one parameter and no output schema, the description fully compensates by detailing the output categories and comparing them to common terms (speculators, hedgers, small traders). An agent has enough to call it correctly and interpret the response.

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 description coverage is 100%, and the description largely repeats the schema's own parameter guidance. It adds a second example ('GOLD - COMMODITY EXCHANGE INC.') and reinforces the exactness requirement, but it does not substantially expand on the schema beyond that.

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?

The description states a specific verb and resource: returns the 'most recent weekly COT positioning for one futures market'. The domain (COT) and scope (single market) are unique among all sibling tools, so an agent can clearly distinguish it 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 Guidelines5/5

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

It explicitly names the prerequisite sibling tool, search_markets, and instructs passing the exact market_and_exchange_names from it, including concrete examples. This gives clear when-to-use and input-sourcing guidance; no alternative sibling would serve the same purpose.

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

All Cftc Cot 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