Fantasy Football Draft Assistant

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

Annotations already flag readOnlyHint=true; the description adds beyond that by stating no key/email is required and all 154 gaps are free, plus the Pro tier adds a judgment layer. This gives the agent useful invocation and access context without contradicting the annotations.

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 core behavior and the key example are front-loaded, and the rest of the sentences add access details, query examples, and the filter. It is slightly more verbose and marketing-flavored ('FREE', 'Pro adds...') but every sentence carries operational information, so there is no significant waste.

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 simple read-only tool with no required parameters and no output schema, the description is largely complete: it names the platforms, gives a row-level example, notes the free access, and covers the position filter. A short statement of the output columns would be the only remaining enrichment.

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%, so the schema already documents limit, scoring, and position. The description mostly restates the position filter and adds domain color about platforms, but it does not add parameter-level meaning beyond the schema or explain values like limit/scoring.

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 opens with a specific verb and resource: 'Find the 2026 fantasy players whose Average Draft Position swings most between platforms', then names the platforms and the value signal. This clearly differentiates it from sibling tools like compare_players or draft_board, since it is specifically about cross-platform ADP gaps rather than general rankings or head-to-head comparisons.

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 clear invocation context with concrete search phrases: 'ADP differences by platform', 'where is a player cheapest', 'ADP arbitrage', and 'who falls on ESPN vs Sleeper'. It does not explicitly state when not to use it or name sibling alternatives, so it misses the full exclusion guidance needed for a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful behavioral context beyond that: the full pool is free with no key/email, and Pro adds boom/bust odds and positional tier breaks. It does not cover rate limits or data-freshness details, but it meaningfully extends the annotation-level transparency.

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 front-loaded with the core behavior and then gives usage guidance and input hints. The FREE/Pro sentence adds valuable pricing and capability context, though some of the wording is slightly promotional; overall every sentence contributes.

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 compensates by listing returned fields (projection, ADP, value flag, biggest model value). It also covers when to use it, key inputs, and pricing/auth behavior. It could be more explicit about the exact return shape, but it is sufficient for an agent to invoke the tool correctly.

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%, so the schema already documents all parameters well. The description reinforces pick_number and drafted in plain terms but adds no new parameter meaning beyond what the schema provides.

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 states the tool's job: given a pick number and drafted players, return the best remaining players with projection, ADP, and value flag. It is specific and uses a concrete verb and resource, but it does not explicitly distinguish itself from sibling tools such as who_do_i_draft or draft_board.

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 gives explicit context for when to use the tool: 'Prefer this mid-draft when the user asks...' and lists canonical phrasings. It does not mention exclusions or when to prefer a sibling tool, so it stops short of full alternative routing.

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

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

Annotations already flag read-only; the description adds concrete behavioral context by promising a pick recommendation, best market value, and the specific comparison dimensions included. It also notes the tool is free and keyless, which is useful operational context.

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 pack action, scope, outputs, and query examples without excessive length. 'Free, no key' is minor filler but not costly, and the key behavior is front-loaded.

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 low-complexity comparison tool with no output schema, it covers inputs, scoring options, output dimensions, and example queries. Slight ambiguity remains because 'start' examples could imply weekly lineups despite the draft-focused description.

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%, so baseline is 3. The prose mostly restates what the schema already covers (2–4 players, standard/half-PPR/PPR) and adds no new parameter-level semantics beyond phrase examples.

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 verb/resource: compare 2–4 players side by side, and enumerates outputs (projection, floor/ceiling, ADP, draft round, value flag, recommendation). The draft-specific framing and query examples distinguish it from sibling tools like explain_player and best_available.

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?

Gives explicit natural-language triggers ('Use for "<A> or <B> in fantasy"', 'compare <A> and <B>', etc.), which makes when-to-call clear. It does not name sibling alternatives or state exclusions, so it misses the top score.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: the board is free, includes ~330 players, can be filtered by position, and exposes projected points, ADP, draft round, and value flags. It also explains that Pro content (boom/bust odds, tier breaks) is not part of the base behavior. This goes beyond the structured annotations.

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 front-loaded with the purpose and core features, but it becomes verbose and promotional with 'THE COMPLETE BOARD IS FREE' and the 'Pro adds' pitch. The query examples are useful, but some sentences read like marketing copy rather than functional guidance, making this less concise than it could be.

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 read-only tool with no required parameters and no output schema, the description covers the main things an agent needs: what data is returned, what filters exist, the scoring options, and access constraints. It does not explain when to prefer this over sibling tools, and response shape is unspecified, but the schema covers parameters and the description covers domain intent reasonably well.

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%, so the schema fully documents limit, teams, scoring, platform, and position. The description adds some context, such as the ~330 player count and position filter values, but it does not materially improve understanding of parameter semantics beyond the schema. Baseline 3 is appropriate.

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 identifies the tool as a ranked fantasy football draft board with a specific data model (projection model + consensus ADP) and lists the output fields (projected points, ADP, round, SLEEPER/BUST flag). It is unambiguous about what the resource is, but it does not differentiate itself from siblings like best_available or who_do_i_draft, which may overlap in user intent.

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 provides concrete example queries ('fantasy football rankings 2026', 'who are the top RBs', 'best available by position'), which implies usage context. However, it never explicitly distinguishes this tool from the sibling tools best_available, who_do_i_draft, or sleepers_and_busts, so an agent may struggle to choose among overlapping options.

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

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

Annotations declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: it explicitly states what the projection does NOT model (injuries, camp news, schedule) and notes that the tool is free with no key. No contradiction with annotations exists. It could add rate-limit or staleness details, but for a read-only explanation tool the disclosure is strong.

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 dense but every clause earns its place: it front-loads the core purpose, enumerates the output factors, states exclusions, notes cost/auth, gives concrete invocation phrasings, and routes to the sibling alternative. Nothing is redundant or padding.

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?

Even without an output schema, the description fully conveys what the explanation will contain (factor-by-factor breakdown, ranks, edge, and non-modeled items) and when to use it. It covers the tool's scope, limitations, and differentiation, so an agent has everything needed to call it correctly.

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%, so the schema already documents the player, scoring, and platform parameters. The description does not add much parameter-level detail beyond what the schema provides, though it does mention platform/scoring concepts indirectly via the explanation factors. Baseline 3 is appropriate given the 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 names a specific verb ('Explain WHY') and resource ('2026 draft board'), then enumerates exactly which factors are covered: projection, floor/ceiling band, boom/bust week shape, model rank, ADP, blend, and edge. It clearly differentiates from the sibling player_outlook by stating it is reasoning rather than an outlook/verdict.

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 gives explicit trigger phrases ('why do you have <player> there', 'explain <player> ranking', 'what's driving <player>'s projection', 'why is <player> a sleeper/bust') and names the alternative tool to use when a plain outlook or verdict is wanted. This leaves no ambiguity about when to invoke this tool.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds meaningful context: it is free, requires no key, covers 2026, and discloses the exact output components including projections, ADP, rank, and sleeper/bust tag. No contradictions with annotations.

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 reasonably concise and front-loaded with the core purpose before enumerating output details and example queries. Every sentence adds useful information, though the output list is somewhat long.

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 3-parameter read-only tool with no output schema, the description provides a solid picture of what the agent will get and when to use it. It covers output fields, scoring options, free access, and use cases; only deeper operational details like data freshness or response format are left implicit.

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%, so the schema already fully documents the player, scoring, and platform parameters. The description reinforces the scoring formats (standard, half-PPR, full-PPR) but does not add deeper parameter meaning beyond the structured schema.

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 identifies the tool as returning a single player's 2026 fantasy outlook and enumerates the specific content delivered. It does not explicitly name sibling tools, but the 'single player' framing and sleeper/bust tag distinguish it from list-oriented siblings like sleepers_and_busts and draft_board.

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 provides concrete 'Use for' examples with natural-language queries such as 'is <player> a sleeper' and '<player> fantasy outlook 2026'. It clearly implies when to invoke the tool, though it does not give explicit when-not-to-use guidance or name alternatives.

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

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

The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context that the data is completely free, requires no key/email, and provides the full list rather than a preview or teaser. No contradiction with the annotations exists.

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 reasonably concise and front-loaded with the core concept. The free/complete-list sentence earns its place by conveying access behavior, and the 'Use for' examples are compact. It could trim a few redundant search phrases, but there is no significant waste.

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 read-only list tool with no required parameters, the description covers the key aspects: what the list is, how it is filtered, which scoring systems it applies to, and that it is complete and free. It does not describe the exact response structure, but there is no output schema and the nature of a player list is reasonably inferable.

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%, so the baseline is 3. The description complements the schema by mentioning position and draft round filtering and the standard/half-PPR/full-PPR scoring options, but it adds little beyond what the parameter descriptions already state clearly.

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 defines sleepers and busts as players where the PredictionMarketsPicks model and consensus ADP diverge, and states the resource is a list of the biggest gaps. It is specific enough to be useful, but it lacks an explicit verb like 'list' or 'get' and does not directly distinguish itself from the sibling adp_market_gaps.

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 tells the agent when to use the tool by providing concrete search queries: 'fantasy sleepers 2026', 'draft busts to avoid', 'undervalued players', and 'late-round sleepers'. It does not mention when not to use it or name alternative tools, so it falls just short of a 5.

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

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

Annotations say readOnlyHint=true, but the description goes further by disclosing that the pick and alternatives are free without key/email and that Pro adds reasoning. It also transparently states the fallback when drafted is omitted ('board is estimated from pick_number using consensus ADP') and the return value. This is behavior beyond what annotations convey.

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 longer than average but front-loads the core purpose and trigger phrases, then organizes ancillary details (free/pro, input summary, return) in sequence. Every sentence adds value; minor redundancy between the 'Input:' list and schema is acceptable.

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 6-parameter tool with no output schema, the description covers input expectations, optionality, fallback logic, pricing tier behavior, and return shape. It does not dive into error handling or alternative tool routing, but nothing an agent needs to call the tool 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%, so baseline is 3. The description adds real semantics beyond the schema: it clarifies that drafted is optional and that supplying it is 'always more accurate', and explains that pick_number drives an ADP-based board estimate when drafted is absent. This enriches the bare schema definitions.

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 opens with a specific verb and resource: 'Recommend the single best player to draft right now' given roster and pick number. It also names the output scope ('one pick + a one-line reason') and distinguishes itself from siblings by stating when to prefer it ('mid-draft when the user asks "who should I take"').

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?

Gives explicit context: 'Prefer this mid-draft when the user asks...' and explains the optional drafted parameter's effect on accuracy. It does not explicitly contrast with sibling tools such as best_available or draft_board, so it lacks a formal when-not, but the guidance is clear.

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