NatGasLens — US Natural Gas & Henry Hub Data

get_us_natural_gas_market_brief

Read-onlyIdempotent

START HERE for any US natural gas / Henry Hub question: the whole dashboard in one call, so an agent does not have to chain five tools and stitch the numbers itself.

Returns, as of the latest data we hold: (1) pressure — every fundamental
we track (LNG feedgas, liquefaction outages, weather-model shifts, the
EIA injection pace, power burn vs normal, NOAA cooling demand, total
demand week-over-week) with its direction on price, strength, the number
behind it and a plain-English sentence, plus an overall roll-up naming
which signals push down and which push up; (2) demand — total US demand
in Bcf/d with its components (power burn, LNG feedgas, industrial,
residential+commercial, Mexican exports, other), the change against the
same weekday a week ago, per-component week-over-week deltas, power burn
year-over-year, and supply minus demand; (3) storage, production, the
Henry Hub forward curve six months out and CFTC managed-money
positioning, each reduced to its latest reading.

Also returns `note` — the rules for reading these numbers correctly:
demand has a weekly profile so day-to-day moves are noise and only
week-over-week comparisons mean anything, the monthly EIA components are
flat steps rather than live signals, and the curve and positioning are
context, not a forecast. Long histories and daily series are deliberately
left out; fetch the dedicated tool when you need one.

Direction is the sign of a deviation from normal, not a probability that
price moves. Market analysis, NOT investment advice. Demo scope returns
the same shape on delayed data.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`asof`	No
`data`	No
`note`	No
`tool`	No
`scope`	No
`stale`	No
`disclaimer`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the data-as-of condition, demo-scope delayed data, the fact that pressure direction is a deviation sign not a price probability, and the interpretation rules embedded in `note`. This materially changes how an agent should consume the result.

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?

Despite its length, it is front-loaded with the core directive and the one-call value proposition, then organized into numbered return groups and caveats. Each sentence earns its place, providing dense specification without fluff.

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?

The description enumerates all returned components, explains the reading rules that prevent common misuses, names the data that is deliberately excluded, and notes demo behavior. With an output schema also present, this is fully complete for an agent to select and call it correctly.

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?

The tool has zero parameters, so the schema already exhausts the input contract and the baseline for empty-parameter tools is 4. The description does not need to explain any parameter syntax; it adds value by explaining what the single call returns.

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 'START HERE for any US natural gas / Henry Hub question' and names the exact resource: the whole dashboard in one call. It also distinguishes itself from the dedicated sibling tools by noting that long histories and daily series are deliberately left out.

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?

The description explicitly tells the agent when to start with this tool ('START HERE') and why it beats chaining five aggregating tools. It also gives a clear when-not-to-use signal: when long histories or daily series are needed, fetch the dedicated tool instead.

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

All NatGasLens — US Natural Gas & Henry Hub Data 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?