Get picks made so far

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It reveals that player data is resolved from a cached player dictionary with fallback to pick metadata, hinting at potential data staleness, and it specifies a polling interval. This is useful context, though it omits any explicit statement of side-effect freedom or response details.

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?

Two sentences, each carrying essential information: the result type, the polling guidance, and the data resolution behavior. The most usable information is front-loaded and there is no redundancy with the schema. This is model conciseness.

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?

There is no output schema, so the description must convey enough about the return value. It communicates an ordered list of picks and the fact that player names, positions, and teams are resolved, giving the agent a mental model of each pick's contents. While the exact fields of a pick object are not enumerated, the stated ordering and fallback behavior are sufficient for a simple polling tool.

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 documents the optional limit parameter as returning the most recent N picks, while draft_id is only typed as a string with no description. The tool description adds no detail about either parameter and thus doesn't compensate for the missing draft_id semantics. Since draft_id is self-evident from the tool name and limit is already well-described, this is adequate but not exceptional.

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 states the tool returns an ordered list of draft picks already made, which clearly identifies the resource and behavior. It distinguishes itself from sibling tools like get_available_players (unpicked players) and whose_turn (next pick) by focusing on completed picks. The title 'Get picks made so far' reinforces this precision.

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 advice to poll every 5–10 seconds during a live draft, which defines a concrete use case and cadence. It does not explicitly contrast with alternatives, but the mention of live polling and cached resolution implies when it is appropriate. Without exclusions or named fallback tools, it falls just short of the strongest guidance.

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