Helious market intelligence

Market imbalance into the open and close

get_market_imbalance

Read-onlyIdempotent

Net dollars to buy or sell into the NYSE opening and closing auctions, calculated by Helious from every NYSE listing's own imbalance print: the whole NYSE market and the S&P 500 names the feed carries, each with its paired volume, the ten largest single names to buy and to sell, and the Helious read of what the lean means for the print. Reads land at 9:28 and 9:29 ET for the open and 3:50, 3:55 and 3:58 PM ET for the close; every read is stored. THIS IS THE TOOL for 'what is the imbalance into the close', 'market on close', 'MOC' or 'how much is there to buy at the bell'. Pass symbol for ONE NYSE-listed name's own prints at every read of a session (side, shares, price, dollars, paired shares); a Nasdaq or NYSE Arca listing answers on_feed false. Market data: numbers follow the connected account.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_market_imbalance"
  }
}

Input Schema

Name	Required	Description
`date`	No	With symbol: the session to read, YYYY-MM-DD. Empty is the newest session.
`fresh`	No	Set true to ask for the live view of this one call, for 5 credits, where the connected account otherwise receives it an hour behind. Accepted and free where the account is already live. No effect without a key.
`limit`	No	Board only: most reads to list.
`since`	No	Board only: reads from this ISO instant forward, inside the plan's history window.
`symbol`	No	One NYSE-listed ticker, like JPM or XOM, for that name's own prints. Empty returns the market board.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the upstream source and coverage universe, the exact publication cadence (9:28 and 9:29 ET for the open; 3:50, 3:55 and 3:58 PM ET for the close), that every read is retained, that non-NYSE listings answer on_feed false, and the credit/latency trade-off on fresh. That is precisely the operational context annotations cannot carry.

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 resource definition and coverage, then cadence, then the routing sentence and the symbol mode. It is dense and long, but nearly every clause carries information an agent needs; the emphatic capitalization is justified because it disambiguates a commonly requested concept.

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 no output schema, the description carries the full burden of describing returns, and it does so at both the board level and the single-name level, including the paired-volume concept and the interpretive lean. Timing, entitlement caveats, and the on_feed negative case are all covered, leaving no material gap for correct invocation.

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%, so the baseline is 3, but the description adds real meaning: it explains what a symbol read returns field by field (side, shares, price, dollars, paired shares) at every read of a session, that date only applies with symbol, and that non-NYSE venues report on_feed false. The stored-reads statement also gives context for limit and since without restating their schema text.

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 pair (net dollars to buy or sell into the NYSE opening and closing auctions) and pins down exactly what the payload contains: whole-market and S&P 500 aggregates with paired volume, the ten largest names each side, and the Helious lean read. The symbol-scoped mode is described separately, so an agent can distinguish the two shapes of this tool 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?

Explicit routing language ("THIS IS THE TOOL for 'what is the imbalance into the close', 'market on close', 'MOC'...") tells the agent which natural-language requests belong here, and it explains the selection rule between the board and a single-name read. It stops short of naming a sibling or stating when another tool is the better choice, so it does not reach the top band.

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

All Helious market intelligence 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?