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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds real behavioral context beyond that: the full field payload, the 1.5x CPT projection multiplier, the rp_p_appear reliever probability, the DK opener/bulk tags (dk_tag PO or PLR), and the row-shape change when slots=true. No auth or rate-limit notes, keeping it at a solid 4.

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 purpose leads the paragraph and the enumerated field list is justified because there is no output schema. It is a long single block, but almost every clause carries informational weight; only the dense mid-sentence field run slightly hurts scanability.

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 output schema, the description correctly compensates by listing the returned fields. Slate selection, the slots behavior, and the bullpen inclusion toggle are all covered, leaving only sort semantics and the difference from the showdown optimizer unaddressed.

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 already 88%, so a 3 is the floor. The description goes further by explaining the slots flag's row expansion and the slate_id-versus-game targeting choice, adding meaning the schema entries only gesture at. It does not clarify sort_by semantics or the interaction of limit with the plan limit beyond what the schema says.

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 resource and mode: 'DraftKings MLB Showdown (captain mode) pool for one game', then enumerates the exact fields produced (salary, projection, CPT projection 1.5x, ceiling, ownership, DK ids, batting order). It is clearly a single-game captain-mode pool, but it never names the siblings it must be distinguished from (e.g. invoke_mlb_showdown_optimizer or the season-long invoke_mlb_player_pool), leaving the boundary implicit.

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?

'Pass slate_id or a game like PHI@ATL' gives concrete input guidance, and 'slots true returns one CPT row and one FLEX row per player' tells the agent how to shape output. However there is no when-to-use versus when-not guidance and no routing to invoke_mlb_showdown_optimizer for lineup construction, so usage is only implied.

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