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

No annotations exist, so the description carries the full burden. It discloses useful behavioral traits: markets are ranked by absolute probability change, results include volume surge ratios, and calls cost $0.04 via x402. But it omits pagination/limit behavior, error modes, and what 'liquidity' filtering does at runtime.

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 core purpose is front-loaded in the first clause, with the ranking/output detail following. The trailing [HTTP/pricing/docs] bracket is meta noise but useful operationally; overall it is efficient with only mild redundancy between 'probability moves' and 'probability change'.

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?

With no annotations and no output schema, the description does a good job explaining the return shape (markets ranked by absolute probability change plus volume surge ratios) and the pre-filtering, plus price and endpoint. It is let down only by the thin parameter coverage, but the return-value gap is well covered.

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?

Schema description coverage is only 25% (only min_liquidity is documented in-schema), so the description should compensate. It repeats the window values (1h/6h/24h) that the enum already exposes but says nothing about limit, category, or min_liquidity semantics, leaving half the parameters undocumented across both sources.

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?

States a specific verb+resource (ranking MLB baseball probability moves) with explicit scope (1h/6h/24h, volume surge ratios) and differentiates itself from siblings by being 'pre-filtered to MLB baseball markets' versus the base /v1/movers and the nba/nfl/soccer variants. An agent can distinguish it from probability_movers_sports-nba without opening either schema.

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?

Positions itself as 'the fastest way to see where news is landing in MLB baseball' and notes it is a pre-filtered version of /v1/movers, which implies when to reach for it. However, it never explicitly names the sibling alternative or states when NOT to use it (e.g., for non-MLB sports or cross-category scans), leaving routing to inference.

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