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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious boundary information beyond that: private sources and unrecorded narrative reasoning are explicitly NOT returned, which tells the agent the data scope it cannot expect.

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, no filler, with the audience/scope constraint front-loaded before the returned fields and the exclusion clause. It is tight, though the 'Active members:' prefix is slightly cryptic without explanation.

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 usefully enumerates what a caller gets back and what is withheld, which is the right compensation for a read-only, single-required-parameter tool. It lacks any note on auth/plan requirements beyond 'active members' and no notes on result sizing, so it is solid but not exhaustive.

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 75%: week, season, and market carry inline descriptions with defaults and enum meaning, while pick_id has no schema description. The description adds no parameter-level detail (e.g., candidate IDs come from sibling tools), so this sits at the baseline for high schema coverage.

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 gives a specific verb ('retrieve') and enumerates the resource contents (confidence, spread, total, selected-side price, winning condition, grading context) for a published pick, so an agent knows exactly what it returns. It does not, however, distinguish itself from close siblings like get_pick_record, leaving the agent to infer the boundary.

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?

'Active members:' scopes the audience and the phrase 'published pick' scopes the target, which is a mild contextual cue. But there is no explicit when-to-use versus get_pick_record or get_member_weekly_picks, and no statement of prerequisites or when this tool should be avoided.

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