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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral detail beyond that: the optional sport parameter doesn't merely filter but "adds that sport's teams," and it outlines the per-result payload. It omits pagination/rate-limit behavior, keeping it below a 5.

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, the resource and examples front-loaded, then the usage directive. The middle clause listing result fields is slightly enumerative but each element informs slug/team selection. No filler sentences.

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 one-optional-parameter discovery tool with an output schema and clear read-only annotations, the definition covers what it lists, what each entry yields, the side effect of the sport parameter, and how it feeds sibling tools. Nothing needed to invoke it correctly is missing.

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 coverage is 100% and the schema description already states that passing a slug "adds that sport's teams." The description restates this and lists concrete slug examples, but adds no new syntax, format, or defaulting semantics (e.g., what happens when sport is omitted). Baseline 3 is appropriate when the schema carries the parameter contract.

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 uses a specific verb ("List") plus a precise resource ("FanDuel Research sports and topics") and enumerates the domain (NFL, NBA, MLB, NHL, golf, soccer, horse racing, casino, FanDuel Predicts). It also states what each result carries (slug, position codes, team count, player-news types), which lets an agent distinguish it from the dozens of sibling fanduel_research_* tools without opening any schema.

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?

"Use it first to find the slugs and team ids the other research tools accept" gives an explicit ordering rule and names the consumer tools as alternatives. It stops short of naming specific when-not cases (e.g., versus fanduel_research_sub_categories) or stating what to do if the slug is already known, so it is strong but not exhaustive.

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