DraftCall

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral value beyond them: it discloses that parameters are inert and that the response body contains only download links, with no stats or scoring. It does not restate anything the annotations contradict.

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 critical fact — 'Returns NO comparison' — is front-loaded, followed by the explanation and the alternative in one compact block. No sentence is wasted; each clause (what it returns, what it doesn't, where the real data lives) earns its place.

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 an output schema present and all three parameters documented at 100% coverage, the description needn't explain return values or parameter formats. It fully discharges its remaining duty: telling the agent this tool cannot fulfill comparison requests and where to go instead.

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% and every parameter is explicitly marked 'Ignored', so the schema already carries the semantics. The description reinforces this ('answers every call with... nothing else') but adds no format or syntax detail 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 immediately and unambiguously states what happens on every call: it returns NO comparison and answers with download links only. It distinguishes itself from the sibling get_player by naming it, so an agent knows this tool is a dead end for comparison data and must not expect stats.

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 states the condition under which this tool is useful (never, for the actual data) and explicitly routes the agent to an alternative: 'For facts about one player, use get_player.' The exclusion is explicit rather than inferred, which is exactly the routing an agent needs.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral nuance by explaining that production is from last season and ADP already prices in injuries, trades, and rookies, preventing misinterpretation of the gap. No contradiction 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?

Three sentences carry definition, directional interpretation, intended usage, and a caveat with zero repetition. The core concept is front-loaded and every sentence adds meaning. This is an efficiently structured description.

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 definition, interpretation of both directions, use case, and key data caveats are all present, and the output schema covers return structure. For a read-only tool with four optional parameters, nothing critical is missing for an agent to call and interpret 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 coverage is 75%, with limit lacking a description. The tool description helps by explaining what earlier/later than production means, reinforcing the direction enum semantics, and the schema itself documents position and scoring_format well. The limit parameter remains undocumented in both schema and description, a minor residual gap.

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 precise definition: players whose consensus ADP disagrees most with production ranking. It distinguishes itself from raw rankings by explicitly declaring 'This is a disagreement, NOT a recommendation,' and the earlier/later explanation grounds the directional semantics. This clearly differentiates the tool from siblings like get_rankings 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 gives an explicit use case: 'Use this for draft-prep questions about who the room may be mispricing.' It also provides a clear when-not-to-use signal by stating the output is not a recommendation. However, it does not name alternative sibling tools or state when to prefer them, so it stops short of full 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that conflicts are reported only when two or more players share a bye week, which is useful but does not disclose additional behavioral details such as output ordering or handling of unmatched players.

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 concise sentences deliver the core behavior and intended use with no filler. The operation is front-loaded and every sentence earns its place.

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 tool has one well-documented parameter, strong annotations, and an output schema. The description covers what the tool does, how to use it, and when to use it, leaving no meaningful gap for an agent 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%, with the players parameter already described as 'Player names, two or more.' The description's phrase 'Given a list of players' adds no new semantic detail beyond the schema, so the baseline of 3 applies.

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 and resource: given a list of players, report shared bye weeks. It clearly distinguishes itself from sibling tools like get_player and compare_players by focusing on bye-week conflict aggregation.

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 gives the intended use: roster planning and draft questions about stacking byes. It does not name alternative tools or exclusions, but the use case is clear enough for an agent to select this over siblings.

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 establish that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat those traits. The description adds useful context about what data the profile contains, but it does not disclose additional behavioral constraints such as authentication, rate limits, or error conditions.

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 single efficient sentence that front-loads the core scope and then lists the specific profile attributes. There is no wasted wording, and the structure makes the tool's purpose immediately understandable.

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-parameter tool with a full input schema, an output schema, and strong read-only annotations, the description provides enough information for an agent to call it appropriately. The included list of return fields covers what an agent would likely need to know about the tool's output.

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 provides 100% coverage of the single 'name' parameter, including an example value. The description does not add meaning beyond the schema, but with full schema coverage, the baseline score of 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's scope as a single player's fantasy profile and enumerates the specific stats returned, such as positional rank, points per game, and bye week. It distinguishes itself from compare_players and search_players through the word 'single', but it does not name a sibling or use an explicit action verb like 'gets' or 'retrieves'.

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 implies that this tool should be used when you need a detailed profile for one known player, especially compared to search or comparison tools. However, it provides no explicit guidance about when not to use it or which sibling tool would be a better fit for related needs.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond those: it explains the measurement method ('dropoff from top player to replacement level') and indicates dependence on scoring format. This is consistent with the annotations and adds useful nuance about what the tool computes.

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, both purposeful and front-loaded. The first defines the metric and its measurement basis; the second gives a concrete use case. No filler or repetition of schema details. Every word earns its place.

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 one-parameter tool with an output schema, the description covers the core concept and typical use. It does not describe what positions are included or how the output is structured, but the output schema handles the latter, and the tool is conceptually straightforward. A minor gap: it doesn't mention that the default scoring_format is half_ppr, but the schema covers that. Overall, sufficient for correct invocation.

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 provides 100% coverage for the single parameter scoring_format, including descriptions of each enum value and its default. The tool description does not add any parameter-specific details beyond mentioning 'in a given scoring format'—which is already implicit. Since the schema handles the semantics fully, a 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 states what the tool computes: 'How steep the fantasy dropoff is at each position in a given scoring format, measured from the top player to replacement level.' It gives a specific verb ('compare' per title) and resource ('positional scarcity'), and distinguishes it from sibling tools like compare_players by focusing on scarcity rather than direct player comparison. The example use case further pins down its 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 explicitly says 'Use this for draft-strategy questions like whether to take a running back or a wide receiver first,' which provides clear when-to-use guidance. It does not mention alternatives or exclusions (e.g., 'for direct player comparison use compare_players'), so it lacks explicit sibling differentiation, but the intended use case is clear enough for an agent to route correctly.

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, idempotentHint: true, and destructiveHint: false, which lowers the disclosure burden. The description adds useful behavioral detail: rankings are ordered by points per game and cover a specific position set. It does not mention pagination, response shape, or data freshness, but these are less critical given the annotations and output 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 two sentences with no redundant phrasing. It front-loads the core function, then gives a practical use case. Every sentence earns its place.

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 rankings tool, the description covers purpose, ordering, positions, and example queries. The output schema exists and parameter descriptions are complete, so the description doesn't need to explain return values. The only minor gap is not mentioning defaults for limit and scoring_format, but those are already in the schema.

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%, with meaningful parameter descriptions (e.g., flex covers RB, WR, and TE together). The description repeats the position list but does not add meaning beyond the schema. The baseline of 3 is appropriate since the schema carries the parameter detail.

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 function: returning fantasy football rankings for a position in a given scoring format, ordered by points per game. It enumerates all supported positions and provides concrete example queries ('who are the best X', draft board questions). This distinguishes it from other player-related tools, though siblings are not named.

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 gives a usage context: answering 'who are the best X' and helping with draft board questions. However, it does not mention when to avoid this tool in favor of siblings like get_positional_scarcity or get_adp_market_gaps, so it stops short of full exclusion 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?

Annotations already state readOnly, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds useful context beyond annotations: the metric uses the prior completed season's data and covers weeks 14-17, which clarifies the data source and scope. No contradiction 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 two sentences with high information density. It front-loads the core computation, then lists usage modes and use cases, with zero wasted words. It is perfectly sized for the tool's complexity.

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 tool has an output schema, so return format is covered. The description fully covers the metric, time windows, input combinations, and intended use cases. It also distinguishes itself from siblings, making it completely self-sufficient for an agent to select 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?

Schema coverage is 100%, so parameters are individually documented. The description adds relational meaning: 'Give a team abbreviation or a player name' and 'give only a position to rank all 32 teams' clarifies the optionality and inference rules between team, player, and position — this is beyond what the schema descriptions provide.

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 exactly what the tool computes: schedule difficulty for a fantasy position based on opponents' average fantasy points allowed, over full season and playoff weeks. It clearly differentiates from sibling tools like get_rankings or get_weekly_matchup by focusing on schedule strength rather than player performance or matchups.

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?

Explicitly gives when-to-use guidance: 'Use this for rest-of-season stash, trade deadline, and playoff planning questions.' It also explains the three invocation modes (team abbreviation, player name, or position alone to rank all teams), leaving no ambiguity about how to call it correctly.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine non-annotation context: this is a single-player schedule lookup with a fixed response shape (opponent, home/away, date, points allowed) and a hard scope boundary against comparison or start/sit reasoning.

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, both earning their place. The response contents are front-loaded and the scope exclusion is packed into the second sentence with no filler.

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 an output schema present, return values need no explanation, and the annotations carry the safety profile. The description supplies purpose, scope, and exclusions—everything an agent needs to select and call this single-player lookup 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%, and the schema already documents week (1-18), player name format, and the scoring_format enum with its default—so the schema does the heavy lifting. The description's mention of "fantasy points that opponent allowed" loosely ties to scoring_format but adds no syntax or format detail beyond 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 names a specific resource (a player's weekly opponent) and enumerates what is returned: home/away, game date, and fantasy points allowed to his position. It also names what it is not (compare players, start/sit), which cleanly separates it from siblings like compare_players and get_strength_of_schedule.

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 explicitly states the negative scope: "it does not compare players or make a start or sit call," steering the agent away from compare_players and any advice-style tool. It stops short of naming the alternative tool by name, but the exclusion is concrete enough to route correctly.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds little behavioral context beyond the search intent; it does not mention result ordering, pagination, or matching behavior. This is acceptable but not rich.

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 concise sentences, front-loaded with the functional purpose and followed by a usage cue. No wasted words or repetitive schema restatement.

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 tool is simple with two parameters, an output schema is present, and annotations cover safety. The description gives enough context for selecting the tool, though it could briefly clarify the limit parameter's role. Overall, it is complete for its complexity.

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 only 50%, because the limit parameter has no schema description. The description mostly restates the query parameter's meaning and does not explain limit behavior, defaults, or constraints, leaving the undocumented parameter uncompensated.

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 clear verb and resource: find players by partial name, team abbreviation, or position. It also positions the tool as a pre-step before using other player tools, which distinguishes it from sibling tools, though it does not name a specific alternative.

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 explicitly says to use this when a name is ambiguous or only partly known before calling the other tools, giving a clear context. It does not list explicit when-not-to-use conditions or name specific sibling alternatives, but the guidance is still actionable.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it returns a match verdict and the actual value when the figure does not match, and it scopes the check to one player. It does not specify matching tolerance/precision, a minor gap.

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?

Three sentences, each earning its place: purpose+scope, return behavior, and usage rule. The core action is front-loaded and there is no filler or repetition of schema content.

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 an output schema, so return details need not be re-explained, and the annotations carry the safety profile. The description covers scope, metrics, and when to invoke the tool. The one meaningful gap is the lack of precision semantics (does 'matches' mean exact equality or tolerant rounding?), which matters for a verification tool but is not disabling.

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 adds meaningful framing beyond the schema by categorizing the metric choices into logical groups (per-game stats, schedule items like bye week, positional rank, and season totals) and by framing 'value' as a figure to verify rather than merely look up. This helps an agent reason about which metric enum value fits the user's request.

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 first sentence states a specific verb ('Check'), a specific resource ('DraftCall data for one player'), and a concrete scope ('points per game, games played, bye week, positional rank, or any season stat'). It also reveals the output behavior (matches vs. actual value), making it unmistakably a verification tool. It is clearly distinct from all siblings such as compare_players, get_rankings, or get_player.

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?

Explicit usage timing is given: 'Use this before quoting a figure from memory, and whenever a user asserts a stat.' This covers both proactive and reactive scenarios. It does not explicitly name alternatives or exclusions, but the tool's verification niche is so distinct from the siblings that the guidance is sufficient.

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