Day-type probabilities

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

The description adds substantial behavior beyond the readOnlyHint and openWorldHint annotations: it explains that the output is a calibrated distribution, based on S&P 500 futures 5-minute bars, descriptive rather than predictive, and provisional under certain bar counts. It also discloses that the Asia session is explicitly unvalidated.

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

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

The description is dense but every sentence adds value: it front-loads the core purpose, then covers output interpretation, caveats, and prerequisites without fluff. It is appropriately sized given the tool's complexity and safety checks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description fully explains what the tool returns (a calibrated five-class distribution plus descriptive statistics about past sessions), and it covers important context like the model training data and when results are provisional. The complexity is well handled with no major gaps.

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

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

The schema already covers both parameters thoroughly, so the baseline is 3. The description adds meaningful context by explaining that the default US session is the only window the model was measured on, and that the 'asia' session is accepted only for 24-hour instruments and is explicitly unvalidated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides day-type probabilities for the trading session in progress, naming the five specific classes and the underlying model. It directly answers 'what kind of day is this so far', distinguishing it from the sibling tools which address other quantdata metrics.

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

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

It gives explicit prerequisites: check session_is_live before reading 'today', and fewer than 18 bars means the distribution is provisional. It also clearly warns against treating the output as a forecast or recommendation, and explains when to omit or pass the 'session' parameter, including the unvalidated Asia session.

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