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

Annotations already mark the tool as read-only and open-world; the description adds useful context by specifying the model basis ('8,000+ archived matches', per format and innings, pre-match Elo) and the output shape (per-side probability and favored side). It does not cover limitations or edge cases, but it complements rather than contradicts the annotations.

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 compact and well-structured: it opens with the core computation, then gives invocation patterns, return values, and example use cases in just four sentences. There is minimal redundancy, and the most important context is front-loaded.

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?

For a tool without an output schema, the description adequately covers what the tool returns and when to use it. However, it is incomplete about how to encode a not-yet-started fixtures under the required fields, and it does not explain probability semantics, leaving some ambiguity for the agent to infer.

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 descriptions cover all nine parameters in detail (100% coverage), so the baseline is a 3. The description adds an invocation pattern ('pass a state' vs two team names), but it does not clarify how a pre-match call can satisfy the five required numeric state fields, which keeps it at the baseline rather than above it.

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 what the tool computes: win probability for a limited-overs match, live or hypothetical, based on a logistic model. It also names the return value ('each side's probability and who is favored') and gives concrete example queries, making it easy to distinguish from siblings like cricket_market_odds.

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?

The description gives explicit use cases ('who is winning', 'what are the odds at X/Y', 'who is favoured tomorrow') and separates in-play state usage from pre-match team-name usage. It does not name alternatives or exclusions, and the 'just two team names' hint is not fully reconciled with the required numeric schema fields, so it falls short of a 5.

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