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

Annotations already declare readOnlyHint: true and openWorldHint: true, so the description need not re-state that this is a read-only market lookup. The description adds useful behavioral context: the 'Pro key required' requirement, the behavior that only modeled strikes return a signal, the explicit 'never a fabricated edge' promise for unmodeled tickers, and the return-value composition as a trade ticket. It does not disclose rate limits, latency, or what happens if no edge exists today, but those are secondary gaps. Bar is lower given annotations, so a 3 is fair.

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 a single dense paragraph but front-loads the core capability in the first clause and packs each subsequent phrase with actionable information: output ticket fields, pro requirement, query phrases, and ticker filtering semantics. It is somewhat long, but every clause earns its place; there is no filler. The only minor issue is the mid-description parenthetical about screening and the ''is there a commodity edge'' phrase could perhaps be tightened, but the density is justified.

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?

Given that there is no output schema, the description compensates well by enumerating the trade ticket fields (entry side/price, resolve criterion, model probability, edge, confidence tier, quarter-Kelly sizing). It also covers the pro-key requirement and error behavior for unmodeled tickers. It does not specify what happens when there is no edge for the chosen commodity, whether both commodities can be queried in one call, or how the 'quarter-Kelly sizing' should be interpreted without a bankroll input; these are modest gaps for a read-only signal tool with openWorldHint.

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 100%, and the description adds even more semantic value beyond the schema. For the tickers parameter it explains that full market or 3-segment event tickers both work, that up to 25 are accepted, that unmodeled tickers return not_covered rather than invented data, and gives the concrete use-case of pasting a Kalshi Pro screener watchlist. For commodity it enumerates the two valid values and associates them with the underlying Kalshi markets (KXSILVERW and KXBTCD). This exceeds the schema's baseline.

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 names the tool as returning the highest-conviction silver or bitcoin trade signal from the PMP edge model, with a specific list of output fields: entry side and price, resolve criterion, model probability, edge, confidence tier, and quarter-Kelly sizing. It also disambiguates from sibling tools by focusing on commodity/silver/bitcoin signals, which none of the listed siblings (which are mostly NFL/fantasy/player-focused) cover. The inclusion of natural-language trigger phrases like 'silver edge today', 'bitcoin trade signal', and 'is there a commodity edge' makes it immediately clear what the tool does and how to invoke it.

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 explicitly states when to use the tool: for silver or bitcoin edge queries, and provides example phrasings. It also explains a specific use case for the optional tickers parameter: paste a Kalshi Pro screener watchlist to check specific markets, and clarifies that the signal is only returned if it matches the strike PMP is modeling. It does not name an alternative tool, but the sibling list contains no other commodity edge tool, so the when-to-use guidance is sufficient for selection and there is no misleading alternative.

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