Fantasy Football Draft Assistant

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: the tool returns 154 fixed gaps, requires no key or email, has a Pro layer, and focuses on platform-specific ADP discrepancies. It does not describe the output shape in detail, but for a zero-parameter read-only tool this is a reasonable level of disclosure.

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 purpose is front-loaded in the first sentence, and the example and use-case list earn their place. It is slightly wordy with the 'Pro adds the judgment layer' and 'FREE' access details, but overall every section contributes actionable context and the description remains compact.

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?

The description conveys the data source, use cases, access requirements, and row count, which is strong for a zero-parameter read-only tool. However, there is no output schema and the description never specifies the exact fields returned beyond an illustrative rank example, and the unsupported filter claim leaves a gap in invocation correctness.

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 input schema has zero properties, so the baseline would normally be 4. However, the description advertises 'Filter by position (QB/RB/WR/TE/FLEX)' even though no filter parameter exists in the schema. This is misleading: an agent may attempt to pass an unsupported position argument and fail schema validation.

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.' It names the exact platforms and gives a concrete example, making the tool's unique ADP-arbitrage purpose unmistakable and clearly distinct from sibling tools like compare_players or scan_mispricings.

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 use cases ('Use for ADP differences by platform', 'ADP arbitrage', 'who falls on ESPN vs Sleeper') and context about access ('All 154 gaps are FREE — no key, no email'). It does not state when not to use it or name alternatives, but the context is clear enough for an agent to select it in the intended scenarios.

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 that no key/email is needed and that Pro unlocks boom/bust odds and positional tier breaks, which is useful context about access and feature gating. It does not contradict 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 is front-loaded, followed by pricing/access notes and usage triggers. It is reasonably concise, though the 'FREE — no key, no email' and 'Pro adds...' sentences are somewhat promotional and not strictly required for invocation.

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 supplies the return content (projection, ADP, value flag, biggest model value), the intended input, the draft/season context, and when to use it. This is complete enough for an agent to call and interpret the 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 input schema declares no parameters, so the description carries the full burden. It clearly specifies the two inputs, pick_number and drafted, and explains what they mean ('current pick number', 'names already gone'), giving an agent enough to invoke the tool correctly despite the empty 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 uses a specific action ('return the best players still on the board') and resource, and it defines the domain (2026, any scoring format) and output fields. It is clear, but it does not explicitly differentiate itself from sibling tools such as who_do_i_draft or draft_board, so the purpose is clear but not distinguished.

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 trigger phrases ('who is the best available', 'who should I take next', 'best player left') and a time context ('mid-draft'), which tells an agent when to prefer it. It does not list exclusions or alternate tools, so it falls just short of full alternative-routing guidance.

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?

Beyond the readOnlyHint annotation, the description discloses that the tool is 'Free, no key' and describes the output components it will produce: projection, floor/ceiling, ADP, draft round, value flag, pick recommendation, and market value. This gives an agent a good behavioral picture without revealing hidden side effects.

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 tight and information-dense: the first sentence covers scope and outputs, and the second sentence gives memorable invocation examples. No filler or redundant restatement exists.

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 zero-parameter tool with no output schema, the description is complete: it explains what the tool does, what output to expect, the supported scoring formats, and how to phrase the request. An agent has enough context to decide and invoke 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?

The tool has no structured input parameters, so the schema cannot document them. The description compensates by showing the expected input style through example phrases, making clear that player names and comparison intent are supplied in natural language.

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 compares 2–4 players, specifies the context (2026 fantasy draft with PPR variants), and lists the comparison dimensions. The example query patterns make the intended use immediately recognizable and distinguish it from siblings like who_do_i_draft.

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 says 'Use for' and gives concrete natural-language examples such as 'who should I draft, <A> or <B>'. It provides clear context for when to invoke the tool, though it does not explicitly state when not to use it or name alternative sibling tools.

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 annotations already declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds useful behavioral context: the board is free, requires no key/email/signup, covers all ~330 players, and is filterable. It does not describe the response format, but annotations already cover the safety profile.

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 minimal but information-dense; each sentence contributes something: board contents, access requirements, pro-only features, and sample queries. It is front-loaded with the core definition, though the pro-upsell sentence could be trimmed without losing essential invocation guidance.

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 zero parameters, read-only annotations, and no output schema, the description covers what an agent needs: board contents, filtering options, access constraints, and example user intents. It does not specify the exact output structure, but the listed fields largely substitute for that in this simple case.

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 tool has zero parameters and the schema reflects that, so there is no parameter ambiguity (baseline 4). The description still adds conceptual filtering context (position, PPR format) that is useful even though no formal parameters exist.

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 a concrete resource (the fantasy football draft board) and spells out its contents: rankings, projected points, ADP, draft round, and sleeper/bust flags, plus position filtering. It does not use an explicit action verb like 'get' or 'show,' and it does not directly name sibling tools, so it narrowly misses a 5.

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 'Use for' section provides concrete query examples and contexts (rankings, top RBs, draft board, best available by position), giving an agent strong cues for when to invoke it. It does not explicitly contrast it with nearby siblings like best_available or sleepers_and_busts, which prevents 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?

Beyond the readOnlyHint annotation, the description discloses that the tool is 'Free, no key' and explicitly states what the projection does NOT model (injuries, camp news, schedule). These behavioral limitations add meaningful context an agent could not infer from the annotations or schema.

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 each part earns its place: purpose, factors, limitations, key/access info, example phrases, and alternative tool. It is somewhat long, but front-loads the primary purpose and keeps the alternative guidance near the end, making it useful without excessive digression.

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 zero-parameter, no-output-schema tool, the description covers its purpose, output contents, limitations, and alternative tools thoroughly. The only minor gap is that it doesn't explicitly state how the target player is identified when calling the tool, but the examples imply the player is present in the user query or conversation context.

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 tool has zero parameters and an empty schema, so the baseline for this dimension is 4. The description doesn't need to explain schema parameters and instead clarifies that the caller refers to a player in natural-language terms, which is sufficient for the no-parameter situation.

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 a specific verb ('Explain WHY...') and a specific resource (the 2026 draft board ranking), enumerating the exact factors that are produced. It also differentiates from the sibling player_outlook by saying this is about reasoning, not a plain outlook or 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?

It gives explicit when-to-use patterns ('why do you have <player> there', 'explain <player> ranking', 'why is <player> a sleeper/bust') and an explicit when-not-to-use pointer ('For a plain outlook or a verdict rather than reasoning, use player_outlook'). This leaves no ambiguity about how the agent should route requests.

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 mark the tool as read-only, and the description adds useful behavioral context: it is free, requires no API key, returns projections in multiple PPR formats, and includes a one-line thesis. It does not explain how the target player is identified given zero parameters, which is a notable omission, but the disclosed content and access model go beyond 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 description is a dense but purposeful list of distinct output elements followed by concrete example queries. Every clause earns its place, though the colon-delimited enumeration is heavier than strictly necessary. It is front-loaded with the core result and ends with usage examples.

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 does a good job enumerating return fields and use cases. However, it never clarifies how the agent supplies the player in a zero-parameter call, and it does not address edge cases like invalid or ambiguous player names. For a tool with no structured inputs, this is a meaningful gap.

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?

There are no parameters, so the schema provides no selection mechanism; the description compensates by making clear the tool is about a single player and by giving query templates with <player> placeholders. Baseline for 0 parameters is 4, and this description adds enough meaning about the implied subject.

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 produces a single player's 2026 fantasy outlook with a clear list of outputs such as projected points, floor/ceiling, ADP, and sleeper/bust status. It is distinguishable from siblings like compare_players and draft_board by its 'single player' framing, though it never explicitly names those alternatives.

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 use cases like 'is <player> a sleeper' and '<player> fantasy outlook 2026', which tells an agent when to invoke it. It does not state exclusions or explicitly contrast with sibling tools, but the example queries are specific enough to route most relevant requests.

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?

Beyond the readOnlyHint annotation, the description adds that the complete list is free, requires no key or email, and covers standard, half-PPR, and full-PPR formats. This gives useful access and scope context, although it does not mention rate limits or output formatting.

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 main function and key differentiators are front-loaded, with the free-access note and example searches following logically. The list of five example queries is slightly repetitive but each example adds value for intent matching, so the overall structure is efficient.

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 zero-parameter, read-only list tool with no output schema, the description covers the model context, scoring formats, filter concept, access requirements, and example user intents. It is missing explicit details about the returned fields, but this is a minor gap given the tool's simplicity.

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 input schema has zero properties, so the baseline is 4, but the description claims 'Filter by position or draft round' without any corresponding parameters. This is misleading: an agent following the schema cannot pass these filters, creating a contradiction between the described capability and the 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 states the tool identifies the biggest gaps between the PredictionMarketsPicks model and consensus ADP for 2026, differentiating sleepers and busts. It is specific about the resource and output, and the context of fantasy football and draft cost distinguishes it from sibling tools like adp_market_gaps or compare_players.

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 explicit example search intents—'fantasy sleepers 2026', 'draft busts to avoid', 'undervalued players'—which tells an agent when to use this tool. It does not list exclusions or name alternatives, but the use cases are clear enough for 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 provide readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavior beyond them: the pick/alternatives are free with no key or email, the Pro tier adds reasoning, and the board is estimated from pick_number when drafted is omitted. This sets expectations about cost, tiering, and fallback logic, which the annotations do not cover.

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 front-loads the purpose and usage, then gives input and output details in a compact, readable format. The line about the pick/alternatives being free is useful pricing/access context, though slightly promotional. One or two sentences could be tightened, but there is no material 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?

The description covers what the tool does, the for the expected use case, the input parameters, the output shape, and the fallback when drafted is omitted. It lacks precise output schema details such as reason wording or team names, but for a simple read-only recommender it is complete enough for an agent to call 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?

The input schema has no documented properties, so the description becomes the only semantic source for parameters. It names three inputs (roster, pick_number, drafted), explains the type of each, and describes the default behavior when drafted is omitted. This fully compensates for the schema gap and exceeds the baseline for zero-parameter schemas.

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 main action: it recommends the single best player to draft given roster and pick number, reasoning value versus positional need. It is specific and actionable, but does not explicitly differentiate from sibling tools such as best_available or draft_board, so it earns a 4 rather than a 5.

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 explicit trigger phrases and situational guidance, saying this should be preferred mid-draft when the user asks questions like 'who should I take' or 'who do I draft.' It lacks a clear when-not-to-use or explicit alternative mapping, but the context is sufficiently clear for selecting this tool over ambiguity.

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