Batru — Dota 2, Deadlock & Marvel Rivals win predictor

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

Even with readOnlyHint=true and destructiveHint=false, the description adds rich behavioral context: MCP Apps render a compact card while other clients receive JSON/text, Dota supports partial drafts with calibrated next-pick win rates, Deadlock/Marvel Rivals require a complete 6v6 for calibrated probability, and partial drafts return labeled empirical pair-data scores. It also states the tool is read-only, matching the annotations without contradicting them.

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 purpose and use cases, then organized into behavior, args, returns, and presentation. It is somewhat long but every section adds operational value; the only minor redundancy is restating read-only when annotations already declare it.

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 tool spanning three games with different capabilities, partial-draft behavior, rendering differences, output fields, and citation handling, the description is remarkably complete. It covers per-game limitations, return contents, and even instructs the agent to surface the citation/source_url to the user, which is especially useful given the large sibling-tool ecosystem.

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 20%, so the description carries the burden for parameter meaning. It provides game enum values, hero count limits per game, team-side semantics for my_heroes/enemy_heroes, and clarifies my_side is Dota-only. The required context parameter is fully documented in the schema itself, so its absence from the Args list is not a significant 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?

Description states a specific verb and resource: 'Analyze a draft and render an interactive Batru win-rate board,' and enumerates concrete use cases (visual draft, matchup, win-probability, next-pick). It also distinguishes itself from sibling prediction/recommendation tools by saying it 'combines the existing prediction and recommendation tools into one stable structured result.'

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 clearly names when to use the tool: 'for visual draft, matchup, win-probability, or next-pick questions in Dota 2, Deadlock, or Marvel Rivals.' It explains it is the combined umbrella tool, which implies alternatives like predict_dota_winrate or recommend_dota_pick exist for more targeted queries, though it does not explicitly say 'use those instead when you only need a single number.'

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 it read-only, and the description adds meaningful behavioral detail: data source (batru.gg), ranked-match provenance, sorted most-banned-first order, sample semantics of ban_matches, freshness/citation guidance, and instruction to report numbers verbatim and show the source link. 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 front-loaded with the purpose and uses compact Args/Returns sections. Every sentence adds value, including the presentation guidance for source attribution. No wasteful repetition.

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?

In the absence of an output schema, the description explains the return shape and key caveats such as freshness and sample size. It is slightly incomplete because it references returned citation/source_url fields that are not listed in the Returns shape, and it does not mention the required context parameter in prose.

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 description adds useful meaning for limit ('Max number of heroes to return (default 15)'), which the schema does not describe. However, its Args section omits the required context parameter entirely, and with only 50% schema coverage the description only partially compensates for the missing parameter documentation.

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 resource as Deadlock ban rates from real ranked games and explains the core use case: who to ban / most-banned heroes. It stops short of a crisp imperative verb, but it is specific enough to distinguish from the sibling stat tools.

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 usage context: use this when ban-related strategy matters and contrasts ban rate with win rate as a different signal. It does not explicitly name alternative tools or state when not to use this tool, so it does not fully reach 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?

Beyond the readOnlyHint annotation, the description adds meaningful behavior: hero names are normalized internally, results come from real observed batru.gg match aggregation, sample sizes are included, and winrate_pct > 50 means the hero beats the opponent. The reference to a returned citation/source_url is slightly confusing because that field is not present in the described return shape.

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 a plain-language purpose and then organized into Args and Returns sections. Each sentence adds operational value, including the winrate interpretation rule, verbatim reporting instruction, and citation presentation requirement. It is detailed without being bloated.

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 provides a full return shape, explains row fields, and clarifies the winrate threshold. The only gap is the dangling mention of citation/source_url in the presentation instruction, which is not part of the declared return structure. Overall, the description is nearly complete for this tool's 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 coverage is only 33%, with context described in the schema but hero and limit lacking descriptions. The tool description compensates well by defining hero as a name/alias and limit as the max number of matchups with a default of 12. The context parameter is already sufficiently explained in the schema, so no extra compensation is needed there.

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 clear question 'Who counters a Deadlock hero' and states it 'Returns opponents this hero performs BEST and WORST against' by real win rate. This clearly differentiates the tool from siblings like get_deadlock_matchup or get_deadlock_synergy by focusing on aggregate best/worst 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?

The description implies when to use the tool: when the agent needs empirically measured counter matchups rather than guesses. However, it does not explicitly mention alternatives or state when to prefer this over get_deadlock_matchup or get_deadlock_synergy, so the agent must infer routing from sibling names.

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 and non-destructive behavior, and the description adds valuable behavioral context beyond that: data provenance from batru.gg, the update-boundary caveat, the 'small deltas are noise' guidance, and the requirement to surface citation/source_url. There is no contradiction with 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 efficiently structured in short labeled sections: purpose, behavioral caveat, args, returns, and presentation instruction. Each sentence adds directly to correct usage and interpretation; there is no fluff or repetition that weakens it.

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?

Given there is no output schema, the description robustly documents the return envelope ({patch, window_days, data_through, ...}) and the two possible payload shapes, plus the meaning of delta_pp. It also covers the noise guideline and source citation expectation, so an agent has enough to call and present 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 low (33%), but the description fully compensates by explaining hero's optional semantics and the empty-value overview behavior, and limit's role as the cap on risers/fallers. It also ties parameter choices to the two possible return shapes. The context parameter is already thoroughly documented in 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 compares each Deadlock hero's win rate over the last 14 days vs the prior 14 days and returns rising/falling lists or a single hero's momentum. It is specific in verb, resource, and scope, and differentiates from sibling tier-list and matchup tools through the 'win-rate momentum' framing and the Deadlock-specific data source.

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 makes the use case obvious: when a user wants to know which Deadlock heroes are gaining or losing meta traction. It also explains why the update-boundary behavior matters and how to interpret small deltas. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full comparative 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 mark the tool as read-only and non-destructive. The description adds useful behavioral context: data comes from batru.gg aggregation, names are normalized internally, and winrate_pct > 50 means the hero wins more often. 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 well-structured with a front-loaded summary, behavioral context, args, return semantics, and presentation guidance. It is slightly redundant in repeating win rate/sample size, and the Args list omits the required context parameter, but overall it is appropriately sized.

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?

Since there is no output schema, the description adequately explains the return shape and the interpretation of winrate_pct. The only noticeable gap is that the return list omits the citation/source_url fields mentioned later, and invalid hero/opponent handling is not discussed.

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 lacks descriptions for hero and opponent, so the description's Args section adds meaningful semantics: hero is the user's hero/alias, opponent is the enemy hero/alias, and aliases are normalized. The context parameter is already documented in the schema, so its omission from the description is acceptable.

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 purpose: compare one Deadlock hero against another head-to-head using measured win rate and sample size. It explicitly says the comparison is between opposite teams, which differentiates it from synergy or counter tools.

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 case is clear—hero vs opponent matchup with empirical data—but there is no explicit guidance on when to prefer this tool over siblings like get_deadlock_counters or get_deadlock_synergy. Selection is implied rather than stated.

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 useful behavioral traits: it uses real observed duo win rates with sample sizes, normalizes the hero name internally, and tells the agent to report numbers verbatim and show the citation/source URL. This is substantial context that the annotations alone do not provide.

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 purpose is front-loaded in the first sentence, and the Args/Returns sections are cleanly separated and scannable. There is minor redundancy between the first and second sentences, both stating best/worst teammates by win rate, but the overall structure is efficient and readable.

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 tool with no output schema, the description provides a full return shape ({hero, best_with, worst_with}), row fields (teammate, winrate_pct, matches), and the meaning of winrate_pct, plus source and sample-size context. The only minor gap is that it references a returned citation/source_url without listing those fields in the stated return object, and it does not cover unknown-hero behavior.

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 documents only the context parameter, while the description independently explains hero (name/alias) and limit (max teammates, default 12), and defines the output row fields. It does not repeat the context parameter, but that parameter already has a full schema description, so the practical coverage for calling the tool is strong.

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 clear, specific statement: this tool finds the best and worst Deadlock hero teammates by measured duo win rate. It explicitly says 'same team' and names the data source, which distinguishes it from sibling tools like counters, matchup, and tier lists. The operation and resource are unambiguous.

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 clear context for when to use the tool: whenever the goal is Deadlock hero team synergy or best/worst teammate pairings. It does not explicitly name alternatives or state when not to use it, so it misses the top score, but the 'with a Deadlock hero' and 'same team' wording makes the intended use obvious among the Deadlock/Dota/Marvel 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's burden is lower. It adds useful context about real-game data, sorted ordering, and presentation rules like 'Report numbers verbatim' and 'Cite total_matches for the sample size.' However, it lists a return shape that omits citation/source_url, then instructs to 'show the returned citation / source_url,' creating an internal inconsistency about the actual return payload.

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 well-organized with front-loaded purpose, then Args, Returns, and presentation sections. Each sentence serves a purpose, and there is minimal fluff. The main flaw is the inconsistent mention of citation/source_url not in the stated Returns shape, which is a clarity issue rather than a conciseness issue.

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 correctly supplies a return shape, which is necessary. But it fails to mention the required context parameter and its special constraints, and the ambiguous citation/source_url guidance leaves the exact response structure unclear. These are material gaps for correct invocation and result presentation.

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 description documents limit ('Max number of heroes to return (default 20)'), which adds a bit beyond the schema's bare integer type. But it completely omits the required context parameter, which carries strict 15-25 word third-person instructions. An agent reading only the tool description could easily invoke the tool without the mandatory context 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 clearly identifies the tool's purpose: 'Best Deadlock heroes right now — the current meta tier list from real games.' It adds concrete detail about ordering ('sorted best-first (rank 1 = strongest)') and provenance ('empirical meta, not a guess'). However, it does not explicitly distinguish this tool from the sibling tool get_deadlock_tier_list_by_rank, which an agent might confuse with the overall meta tier list.

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 no guidance on when to use this tool versus alternatives like get_deadlock_tier_list_by_rank, get_deadlock_counters, or get_deadlock_matchup. It states what the tool returns but offers no 'use this when' or 'prefer this tool over X' instructions. An agent must infer the appropriate selection from the tool name and sibling names alone.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by stating the return structure explicitly (bracket, rank_range, total_matches, generated_at, heroes array with fields) and instructing the agent to report numbers verbatim and mention the band. The description also hints at potential data unavailability (early patch), which is a behavioral nuance beyond the annotations. It could be improved by noting any rate limits or how often data refreshes, but overall it's 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 well-structured with a brief purpose statement, followed by contextual details and usage guidelines, then explicit parameter descriptions, and finally return format and presentation instructions. The first sentence is a clear front-loaded purpose. Some of the output instructions (e.g., 'Report numbers verbatim') could be viewed as extra but are helpful for correct behavior. The final line about showing citation might be better in the return format section, but it's not excessive.

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?

Given that there is no output schema, the description fully compensates by explicitly listing the return shape and fields. The 3 parameters are all explained with examples and defaults. The tool is moderately complex (rank band lookup), and the description covers the key nuance of data availability and fallback. No obvious gaps remain 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 only 33% (2 of 3 params have docs). However, the description compensates by providing detailed semantics for 'rank' (e.g., examples 'oracle, eternus', band keys 'low, mid, high, top') and for 'limit' (default 20). The remaining parameter 'context' is documented in the schema with a thorough description of its purpose and usage rules. The description also adds the return structure which helps the agent understand how parameters affect the output.

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 purpose: 'Get the Deadlock hero tier list for a specific rank band.' It specifies the verb ('Get'), resource ('Deadlock hero tier list'), and the critical distinguishing dimension ('rank band'). It also explains why rank matters ('The meta differs by skill level'), which differentiates it from the sibling get_deadlock_tier_list (general list).

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 guidance on when to use this tool vs the fallback: 'Early in a patch window a band may not have enough matches yet — fall back to get_deadlock_tier_list if so.' This is a clear when-not condition with a named alternative. It also describes the four rank bands (Low, Mid, High, Top) and that rank can be a band key or a specific rank name, helping the agent select the correct input.

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 signal read-only, non-destructive, open-world behavior, and the description adds meaningful context: data source from batru.gg match aggregation, internal hero-name normalization, sample sizes, the winrate_pct > 50 interpretation, and instructions to report numbers verbatim and cite source_url. 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 front-loaded with purpose and uses clear sections for args and returns. Each sentence adds useful information, though the Args section omits the required context parameter and the early sentences slightly restate the best/worst concept.

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 of documenting the return shape, the meaning of winrate_pct, and the expected reporting behavior. Minor gaps are that citation/source_url is referenced but not included in the return structure, and the required context parameter is absent from the Args section, but both are recoverable from schema or 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?

Schema coverage is only 33%, but the description compensates by defining hero as name/alias/shortName and limit with its default and meaning. The context parameter is not covered in the description, but the schema provides a thorough instruction block for it, so the agent has enough to invoke correctly.

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 clear verb-object statement: 'Who counters a Dota 2 hero (and who it beats)' and then specifies it returns best/worst opponents by observed matchup win rate. This clearly defines the tool's purpose and distinguishes it from related matchup/synergy tools, even without naming them.

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 the use case: when the agent needs best/worst matchup data for a single hero, as opposed to comparing two heroes or drafting. However, it never explicitly names alternatives such as get_dota_matchup or states when not to use this tool, so the guidance remains implicit rather than explicit.

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 readOnly/openWorld/destructive annotations, the description discloses the 14-day vs prior-14-day window, the batru.gg data source, the noise caveat for small deltas, and the citation/source_url presentation requirement. This is substantial behavioral context that the annotations alone do not provide.

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 organized into purpose, method, usage, Args, Returns, and presentation instructions, with the key question front-loaded. Despite covering many details, every sentence earns its place and there is 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?

Because there is no output schema, the description supplies the return shape for both single-hero and overview modes, explains delta_pp, flags noise, and even handles source attribution. For a read-only query tool of this complexity, nothing essential 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?

With only 33% schema coverage, the description compensates by explaining hero (optional, empty returns overview) and limit (max risers/fallers, default 10). The required context parameter is left to the schema's own detailed description, and hero name formatting is not specified, so it is helpful but not exhaustive.

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 question—'Which Dota 2 heroes got better or worse after the patch'—and identifies the exact resource (heroes by win-rate shift). It clearly differentiates from siblings like get_dota_tier_list or predict_dota_winrate by emphasizing 14-day momentum and 'winners/losers by win-rate shift.' The unique comparison window makes the tool's role unmistakable.

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 frames the right use case: 'what's getting stronger lately?' questions between patches. It does not mention when to prefer sibling tools such as get_dota_tier_list or predict_dota_winrate, 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=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: data is empirical from batru.gg, 'not a guess,' names are normalized internally, and numbers should be reported verbatim. The mention of citation/source_url adds presentation guidance, though it slightly conflicts with the earlier return shape.

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 purpose and remains mostly efficient. It includes useful detail like return format, interpretation, and presentation rules. A small deduction is warranted because of the inconsistency between the declared return object and the later citation/source_url instruction, plus the Args section omitting the required context parameter.

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 matchup tool with no output schema, the description explains return fields, winrate interpretation, data source, and output presentation. However, it omits the required context parameter from its Args list and gives an incomplete/possibly inconsistent return shape (missing citation/source_url). These are meaningful but not fatal gaps for an agent invoking 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?

Schema description coverage is only 33%, so the description carries the burden for hero and opponent. It does this well by explaining that both accept names, aliases, or shortNames and clarifying the directional relationship. The context parameter is not described in the tool description, but the schema itself provides extensive context guidance, so the combined coverage is strong.

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 a specific verb and resource: it gets a head-to-head matchup between hero and opponent in Dota 2, with win rate and sample size. It explicitly uses 'AGAINST `opponent` (opposite teams)' and 'head-to-head,' which helps distinguish it from sibling tools like synergy or momentum.

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 intended use is implied: call this when you need a hero-vs-hero matchup outcome from real games. However, it does not explicitly mention when not to use it or point to alternatives such as get_dota_counters, get_dota_synergy, or predict_dota_winrate. The guidance is decent but not explicitly comparative.

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 and destructiveHint, so the description adds real value by disclosing data provenance (batru.gg aggregation), internal hero-name normalization, the empirical nature of the stats, and the instruction to report numbers verbatim. No annotation contradiction 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 purpose is front-loaded and the return format is clearly explained. There is minor duplication of 'best and worst' and the citation instruction is placed awkwardly after the returns description, but overall the text is focused and useful.

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?

Since there is no output schema, the description correctly documents the full return shape and field semantics. It falls slightly short by referring to citated citation/source_url fields that are not included in the stated return object, and it does not mention no-data or edge-case behavior.

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?

With schema coverage at only 33%, the description compensates for the undocumented hero and limit parameters by defining aliases and the default/limit semantics. However, it omits context from its Args list, so the parameter documentation feels slightly incomplete even though the schema covers context well.

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 opening line states a specific verb and resource: 'Who works best with a Dota 2 hero — best (and worst) teammates by measured duo win rate.' It clearly focuses on teammate synergy and distinguishes itself from counter/matchup siblings without needing their descriptions.

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 makes the tool's domain obvious, but it never explicitly identifies alternatives or says when not to use it. Sibling tools like get_dota_counters and get_dota_matchup exist, yet no routing guidance is provided.

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 useful behavioral detail beyond that: data source (batru.gg), empirical aggregation, sort order, and the instruction to report numbers verbatim and cite total_matches. It also explains what the returned object contains, which helps the agent interpret the result.

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 well-structured with Args and Returns sections and front-loaded with the headline purpose. It is slightly verbose and contains a minor typo ('~real games') plus an inconsistency where `citation`/`source_url` are referenced but not listed in the described return object.

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 output schema, the description provides enough operational detail: return shape, meaning of total_matches, sorting semantics, and the instruction to surface the source link. The unresolved mention of `citation`/`source_url` not present in the stated return object is a small completeness 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?

The schema only fully describes the `context` parameter, while `limit` has no description. The description compensates by explicitly documenting `limit` as 'Max number of heroes to return (default 20).' This fills the main schema gap, though it does not add anything beyond that.

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 does: returns the current-patch Dota 2 meta tier list based on real-game aggregation, sorted best-first. It does not explicitly contrast itself with the sibling get_dota_tier_list_by_rank, but the 'rank 1 = strongest' framing makes the base-list purpose clear enough.

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?

Usage context is implied through 'Best Dota 2 heroes right now' and 'empirical meta, not a guess,' but there is no explicit guidance about when to prefer this tool over alternatives like get_dota_tier_list_by_rank, get_dota_counters, or matchup tools. No exclusions or conditional routing are provided.

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 destructiveHint=false, so the description builds on that by adding behavioral details: the data comes in four merged rank bands, numbers should be reported verbatim, and a citation/source_url must be shown to the user. This adds value beyond what annotations provide.

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 well-structured with a front-loaded purpose, followed by context, args, return format, and presentation guidance. Each sentence adds essential information without wordiness, making it concise yet comprehensive.

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 three parameters and no output schema, the description covers input semantics, return structure, and even post-processing instructions. The only omitted parameter is 'context', but that is fully specified in the schema, so the tool is complete from an agent's perspective.

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 only provides a full description for the 'context' parameter, leaving rank and limit with minimal info. The description compensates by explaining rank values and band keys, and by defining limit as max heroes returned. Context is already well-covered in the schema, so no redundancy.

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 begins with a precise statement: 'Get the Dota 2 hero tier list for a specific rank bracket.' This clearly identifies the verb, resource, and scope, and the additional context about rank bands distinguishes it from sibling tools like get_dota_tier_list.

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 clear context for when to use this tool by explaining that the meta differs by skill level and listing the rank bands. However, it does not explicitly name alternative tools or exclusion criteria, 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 already mark this read-only and non-destructive, and the description adds valuable behavior beyond that: data comes from parsed replays via OpenDota and is 'not model output', fresh games can lag about an hour, only TI-2026 is covered, and the response includes a citation/source_url that must be surfaced. This is strong context; it only misses optional details like rate limits or exact error behavior.

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 long but information-dense, front-loading the core purpose and then systematically covering scope, filters, parameters, and return shape. The only minor redundancy is the citation display instruction appearing both in Returns and at the end; otherwise every section 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 no output schema, the description compensates by specifying the full return structure, including optional fields marked with '?' and the citation requirement. It also covers coverage limitations, latency, filtering semantics, and cross-tool routing to get_dota_tournament_stats, making the tool callable correctly without external documentation.

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 17%, so the description carries the burden, and it delivers: the Args section explains event, team, stage, match_id, and limit with defaults, case-insensitive substring matching, and the cap of 5. It adds meaning beyond property names and compensates fully for the sparse schema; the only unmentioned param, context, already has a thorough schema description.

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: 'Get per-game BOX SCORES from parsed replays for a pro Dota 2 tournament.' It then enumerates the concrete data fields (lane gold diff, hero, K/D/A, GPM, key items, first blood, Roshan kills) and gives illustrative questions, which clearly distinguish it from siblings like get_dota_tournament_stats (bracket-level) and hero statistic tools.

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 when-to-use guidance: filter by stage vs team vs match_id depending on the user's question, and states that no filter returns the event's most recent games. It also names the alternative get_dota_tournament_stats and tells the agent to call it first when teams or stages are unknown, plus warns that other events don't carry per-game data yet.

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 mark the tool as read-only, and the description enriches this by clarifying that numbers are computed from official drafts, are 'REAL tournament results, not model output', refresh automatically, and should be treated as small-sample records rather than calibrated probabilities. It also discloses that unplayed bracket slots do not appear as rows, guiding correct interpretation of results.

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 long, but every section earns its place: the opening states purpose, the second paragraph adds data provenance and caveats, the third defines event coverage and parameters, and the final paragraphs explain return shape and navigation guidance. The front-loaded first sentence gives immediate clarity, though the later sections could be more tightly compressed.

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 present, the description compensates by enumerating the full response shape, including `aggregates`, `hero_stats`, `team_top_picks`, `standings_group_stage`, and `playoff_results`, and by instructing the agent to include the citation. It also covers event statuses, bracket inference, and sibling-tool routing, making it complete for a complex tournament-stats 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?

Schema description coverage is low at 33%, but the description compensates by explaining the `event` parameter in detail (valid slugs, covered events, aliases, default 'ti-2026') and `limit` (max hero rows, most contested first, default 15). The `context` parameter is not mentioned in the description, but the schema already provides a thorough explanation and example for it, so the gap is minor.

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-resource pair: 'TI / EWC pro tournament stats — actual most-picked, most-banned and win rates per hero.' It clearly distinguishes this tool from the sibling get_dota_tournament_game_stats by naming that tool as the drill-down follow-up, so an agent can select between them without ambiguity.

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 states when to use this tool first ('call THIS first to learn which teams exist and who is playing the final/semifinals') and when to switch to the sibling tool ('then drill into a single game with get_dota_tournament_game_stats'). It also gives concrete event slug examples and aliases, making invocation decisions unambiguous.

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 readOnly and openWorld annotations, the description discloses the empirical data source (batru.gg competitive mode aggregation), freshness limitations (snapshots can lag the season), and mandatory output behaviors like citing generated_at, reporting numbers verbatim, and surfacing the source link. This is genuinely useful behavioral 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?

The description is well-structured and readable: purpose first, then parameter help, return shape, and warnings. There is minor redundancy between 'real competitive games' and 'competitive mode, where bans exist', but the important caveats are emphasized without excessive 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?

With no output schema, the explicit return shape and sorting behavior are valuable. The main gap is that the description tells the agent to show the returned `citation` / `source_url`, but those fields are not included in the documented return object — a minor inconsistency that could affect how the agent formats results.

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 only documents the required context parameter, leaving limit undocumented in the schema. The description compensates by explaining limit as the max number of heroes to return with a default of 15. It does not need to restate the already-detailed context instructions from 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 identifies the resource as Marvel Rivals ban rates and the purpose as determining who to ban / the most-banned heroes. It also explains the distinct signal being measured (what players fear facing) and differentiates it from win rate, which separates it from sibling tools like tier lists and counters.

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 clear context: use this tool for ban-oriented decisions from real competitive matches, and it explicitly contrasts ban rate with win rate. However, it does not name alternative tools or state explicit when-not-to-use conditions, so it falls just 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?

The description goes well beyond the readOnly and destructive annotations by disclosing data provenance (batru.gg match aggregation), internal hero-name normalization, return structure, the meaning of winrate_pct, and the instruction to report numbers verbatin and show the citation/source_url. This gives an agent critical behavioral and presentational 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?

The description is concisely organized with a short summary, an Args section, a clear return contract, and a presentation note. Each sentence adds useful information without padding or unnecessary repetition.

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 provides a complete return contract: the top-level keys, the row fields, the interpretation of winrate_pct, and the source attribution requirement. This is more than sufficient for an agent to invoke and present 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 only 33%, but the description directly explains both hero (name/lias, normalized internally) and limit (max number of matchups, default 12) in its Args section. The context parameter is fully described in the schema, so all parameters are effectively covered.

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 purpose with a specific verb and resource: it returns which heroes counter a given Marvel Rivals hero and which heroes it beats, based on measured win rates. This distinguishes it from sibling tools like get_marvel_rivals_matchup by focusing on an aggregate best/worst matchup list rather than a single matchup lookup.

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 conveys a clear use case: look up a hero's strongest and weakest matchups from real observed data, with sample sizes. It does not explicitly name sibling alternatives or state when not to use the tool, but the return shape and 'empirical meta data' framing make the intended scenario unambiguous.

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 description adds substantial behavioral context beyond the readOnly/openWorld annotations: data comes from batru.gg match aggregation, windows may cross season boundaries, season is context, and delta_pp below 1pp should be treated as noise. It also instructs the agent to surface the citation/source_url, which is important for responsible presentation.

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 purpose, then uses labeled Args/Returns sections and a final presentation note. Every sentence adds value: season-boundary nuance, noise guidance, and citation handling are all relevant. No filler or repetition.

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 present, the description provides a thorough return shape for both overview and single-hero modes, explains key fields like delta_pp, and covers interpretation caveats. An agent has enough information to call the tool, interpret the result, and present it appropriately.

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 only 33%, but the description compensates well: it defines hero as optional, explains that an empty value returns the risers/fallers overview, and clarifies that limit caps risers/fallers in overview mode with a default of 10. The required context parameter is left to the schema, but its purpose is already well-documented there.

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 purpose: identifying which Marvel Rivals heroes are rising or falling in the meta via win-rate momentum. It states the exact comparison window (last 14 days vs prior 14 days) and distinguishes this from static tier-list or counter tools by emphasizing trend data.

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 clearly establishes when to use the tool: to see meta momentum rather than static rankings. It also gives practical interpretation advice around season boundaries and small deltas. It does not explicitly name sibling alternatives or say when not to use it, but the context is strong enough for selection.

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 establish read-only, non-destructive behavior, and the description adds useful context: empirical data source, internal name normalization, the meaning of winrate_pct > 50, and instructions to report numbers verbatim and show citation/source_url. This goes beyond the structured annotations without contradicting them.

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 well-structured with purpose, return behavior, args, and presentation guidance. Some redundancy exists: 'with measured win rate and sample size' is echoed by 'with the sample size' in the next sentence. Overall it is reasonably concise and 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?

With no output schema, the description compensates by documenting the return fields, their interpretation, and the source-citation requirement. It does not describe the context parameter or edge cases, but the schema covers context and the core calling contract is clear enough for an agent.

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 only describes the context parameter, while hero and opponent lack descriptions. The tool description adds 'name/alias' semantics for hero and opponent, which is helpful, but it omits the required context parameter entirely. With schema coverage at 33%, the description partially compensates but leaves a 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 clearly states the tool's function: comparing two Marvel Rivals heroes head-to-head with win rate and sample size. It distinguishes this from sibling tools like counters or synergy by explicitly framing it as hero-vs-hero matchup data from real games.

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 intended use is implied by the wording 'X vs Y' and 'hero performs AGAINST opponent,' but there is no explicit when-to-use guidance or exclusion of alternatives. It does not name sibling tools or explain when counters/synergy would be more appropriate.

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 readOnly annotation, the description reveals internal normalization of hero names, data provenance from batru.gg, use of observed sample sizes, a non-guess empirical basis, and an instruction to report numbers verbatim and show the source link. This is substantial behavioral 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?

The description is well-organized with a clear goal upfront, then Args and Returns sections. Every sentence carries useful information; there is no filler or repetition.

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 a return shape, field semantics, win-rate interpretation, and data source. The only significant gap is that it references returning citation/source_url without including them in the stated return object, which could confuse an agent.

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 low (33%), but the description compensates for the two functional parameters: hero is documented as accepting a name/alias, and limit is documented for max teammates with default 12. The context parameter is adequately explained in the schema itself.

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: get best/worst teammates for a hero by measured duo win rates. This clearly distinguishes it from sibling tools like counters, matchup, and tier lists.

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 makes the intended use case clear: looking up teammate synergy/team-up partners for a Marvel Rivals hero, based on empirical win rates. However, it does not explicitly name alternatives or state when not to use it, though the sibling names make the distinction fairly obvious.

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 mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: the data source, empirical aggregation, best-first sorting, and the instruction to cite the sample size. The only minor inconsistency is that the return shape listed does not include citation/source_url even though the description tells the agent to show those fields, but this 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 description is well-structured and front-loaded with the core purpose, then moves through ranking source, sort order, parameters, return shape, and presentation instructions. It is slightly redundant in places, such as emphasizing empirical/meta after already saying 'from real games,' but overall every section earns its place and the formatting is scannable.

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 tool with no output schema, the description provides a reasonable return shape, sort order, and citation guidance. However, it does not explicitly differentiate from the by-rank sibling tool, and it instructs showing citation/source_url while omitting those fields from the listed return structure, which leaves a small but meaningful completeness 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?

The description adds real semantic value for limit by stating it is the maximum number of heroes to return, which the schema does not explain beyond its default value. It omits the required context parameter from the Args section, but the schema itself provides a detailed and explicit description of context, so the missing natural-language coverage does not harm agent understanding.

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 purpose: it returns the current-season Marvel Rivals meta tier list, with heroes sorted best-first. It is specific about the resource (Marvel Rivals heroes) and the ranking basis (batru.gg match aggregation). However, it does not explicitly distinguish itself from the sibling get_marvel_rivals_tier_list_by_rank, so the differentiation is implied rather than stated.

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 when to use it: when the user wants current-season Marvel Rivals hero meta or tier rankings. It gives clear presentation guidance, such as reporting numbers verbatim, citing total_matches, and showing citation/source_url, but it does not explicitly state when not to use it or direct the agent to any 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?

Annotations declare `readOnlyHint: true` and `destructiveHint: false`, which the description does not contradict. The description adds valuable behavioral context beyond annotations: it explains the internal data construction (quartiles of average rank), what the returned object looks like (bracket, total_matches, etc.), and instructions to present numbers verbatim. It also warns that the data source uses percentiles rather than named ranks, which is a helpful nuance. No annotation contradiction.

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 but includes a lengthy inline docstring style block (Args, Returns) that is somewhat redundant with the schema. The final instruction about showing the source link is a bit misplaced and adds noise. At 240+ words for the narrative portion, it could be trimmed by 20-30% without losing value. The structure is clear but not perfectly front-loaded; the key purpose appears in the first sentence, which is good.

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?

Given three parameters (one undocumented in description), no output schema, and no nested objects, the description does a fair job explaining the return structure and data bands. However, it does not describe error cases (e.g., invalid band name), nor does it clarify that `context` is required but only documented in the schema. With sibling tools that are very similar, a brief 'when to use which' would improve completeness.

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 description explains the semantic meaning of the `rank` parameter (low/mid/high/top, plus a note about accepting 'top skill'), and the `limit` parameter (max heroes, default 20). The schema coverage is only 33%, but the description compensates by adding detail for the two parameters it does mention. However, the required `context` parameter is not described in the tool description at all, only in the input schema, which is a gap. The description adds value beyond the bare schema but misses one parameter.

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 fetches a Marvel Rivals hero tier list filtered by a specific skill band. It distinguishes itself from the sibling `get_marvel_rivals_tier_list` by specifying that this variant is per skill band, and uniquely describes the underlying data as quartiles of average competitive rank score, not named ranks. The verb 'Get' and resource 'hero tier list for a specific skill band' are precise and unambiguous.

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 explains what the four bands are and why they exist ('The meta differs by skill level'), which helps with when to use. However, it does not explicitly state when NOT to use this tool or direct the user to alternatives among siblings (e.g., when a broader tier list is needed, use `get_marvel_rivals_tier_list`). The inclusion of instruction about showing the source link is useful for presentation but not a usage guideline per se.

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 destructiveHint=false. The description adds valuable context: the ledger is auto-generated from an append-only log, nothing is hand-picked, and it includes both promoted and rejected evaluations. This clarifies the data's provenance and neutrality, going beyond the annotation's 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 moderately detailed but well-structured: it states purpose first, then usage context, presentation guidance, parameters, and return format. While longer than typical, each section serves a purpose (especially the nuanced 'how to present it' guidance), so it earns its length.

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 purpose, when to use, how to present results, the 'limit' parameter, and the complete return shape (including nested fields). There is no output schema, so this description carries the full burden, and it does so comprehensively enough for an agent to invoke and interpret results 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 50%, with only 'context' described in the schema. However, the description supplements by explaining 'limit' (Max evaluations to return, newest first, default 10) and also details the return structure, which helps interpret parameter effects. This adds meaningful semantic value beyond the schema alone.

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 retrieves batru.gg's public model evaluation ledger, listing every weekly test with wins and losses. It uses a specific verb ('Get') and resource, and it is distinct from sibling tools that focus on game meta stats (Dota, Deadlock, Marvel Rivals).

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 says 'Use this when a user asks whether the model is any good or how it is validated.' It also provides presentation instructions, clarifying what to emphasize (calibration over raw accuracy) and when not to headline accuracy, which serves as guidance for appropriate use.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds context about fallback usage but does not go beyond the safety profile already conveyed by 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 single, well-structured sentence of about 20 words with no wasted words. It is front-loaded and 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?

Given the tool's meta-purpose, the description is sufficient for understanding when to use it. Annotations cover safety and openness. The lack of output schema is acceptable as the tool likely returns dynamic tool suggestions.

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 100% description coverage, with a clear description for the one required parameter. The description does not add extra meaning beyond what the schema provides, so 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 the verb 'Check' and resource 'additional tools', distinguishing it from sibling tools which are domain-specific queries. It specifies that it is for discovering specialized capabilities.

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 when to use this tool: 'whenever your task might benefit from specialized capabilities - even if existing tools could work as a fallback.' It doesn't mention when not to use, but provides clear 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 indicate readOnlyHint, openWorldHint, and destructiveHint. The description adds key behavioral context: the backend silently drops unrecognized names, and the tool returns either a match with structured fields or an error with suggestions. This goes beyond what annotations provide.

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 structured with clear sections (Args, Returns) and uses straightforward language. Every sentence contributes to understanding, with no fluff. It could be slightly more concise, but the detail is warranted given the tool's critical role.

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?

Given the tool's simplicity (3 parameters, no output schema), the description covers all necessary aspects: purpose, usage, parameter meanings, return structure, and error handling. It is fully adequate for an AI agent to successfully invoke 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?

With only 33% schema description coverage, the description compensates by explaining the 'query' parameter (hero name, alias, or short name) and the 'game' parameter (enumerated options with default). However, it does not detail the 'context' parameter beyond what the schema provides, missing a chance to clarify its purpose.

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 specific verbs ('normalise') and clearly identifies the resource ('hero name/alias/shortName to canonical identity'). It provides concrete examples of messy input and explicitly states it is the prerequisite for prediction tools, distinguishing it from sibling tools that perform analysis or predictions.

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 tells when to use the tool ('before calling the prediction tools') and why it's necessary ('backend silently drops hero names it doesn't recognise'). It offers a clear context, though it does not explicitly state when not to use it (e.g., if the name is already canonical).

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 destructiveHint=false. The description adds valuable behavioral context: the model is production-backed and calibrated ('not a guess'), hero names are normalized internally, and the returned citation/source_url must be shown to the user. This goes well beyond what the annotations alone provide.

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 well-structured and front-loaded: the first sentence is a clear summary, followed by calibration context, args, and return instructions. Each section earns its place, though the Args list could be tightened and integrated with the schema to reduce redundancy.

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 adequately covers what the tool returns (calibrated win-rate percentages), the need to report verbatim, and source-link presentation. The only meaningful gap is the missing `context` parameter in the description, which is required by the schema but not surfaced.

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 description adds useful meaning for team0_heroes and team1_heroes (6 heroes, names/aliases, internal normalization), which is important given only 33% schema coverage. However, the required `context` parameter is entirely omitted from the Args section, creating an incomplete picture of the calling contract and relying on the schema to fill a significant 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 states a specific verb ('predict'), resource ('Deadlock 6v6 comp' draft), and outcome ('calibrated win probability'), clearly distinguishing it from sibling tools like get_deadlock_matchup or tier-list utilities. The phrase 'for any draft' plus 'Provide 6 heroes per team' removes ambiguity about what this tool does.

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 clearly implies when to use this tool: when the user has two 6-hero Deadlock teams and wants a calibrated win-rate prediction. It does not, however, explicitly name alternatives or state when not to use it, so it stops short of the highest level of 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 reveals important behavioral details: the model is calibrated, reported probabilities are empirical, partial drafts are supported, empty drafts return 50/50, hero names are normalized to shortNames, and results must not be adjusted. It even instructs the agent to surface citation/source_url to the user. This is thorough, non-misleading, and fully consistent with 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 front-loaded with the core purpose and uses a clearly structured Args section. The calibration/trust sentence is somewhat long but justifies why the numbers should be trusted and reported verbatim. Minor redundancy around 'calibrated' keeps it from a perfect score.

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 appropriately states that both teams' win-rate percentages are returned and mentions the citation/source_url to display. It does not spell out the exact response shape or numeric format, but the core calling contract is clear enough for an agent to use the tool and present results 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 only 25%, so the description carries most of the parameter burden. It clearly explains my_heroes and enemy_heroes as 0-5 hero names/aliases, notes internal normalization, and defines my_side as radiant/dire. It does not mention the required context parameter, but the schema provides a detailed description for it, so the gap is partially mitigated.

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 purpose: predicting calibrated win probability for a Dota 2 draft, with specific behavior for full or partial drafts. It is more specific than generic stats siblings like get_dota_matchup or get_dota_counters, and the 'full or partial draft' phrasing separates it from batch/analytics tools. However, it does not explicitly contrast itself with the closely related predict_dota_winrate_batch sibling, so it loses a point on sibling differentiation.

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 useful usage context: it works on any full or partial draft, handles empty drafts with a 50/50 result, and normalizes hero names. It also tells the agent to report numbers verbatim and show the citation. However, it does not say when to choose this tool over predict_dota_winrate_batch or other draft-prediction siblings, nor does it state any exclusions.

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 destructiveHint=false, but the description adds valuable behavioral context: a single server-side model invoke, output calibration ('a reported 60% reflects a real ~60% empirical win rate'), internal hero name normalization, and the return structure with baseline and delta. This goes well beyond the annotations and provides deep transparency about how the tool behaves.

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 well-organized with a bold upfront summary, Args, Returns, and usage notes. It is generally concise given the complexity. However, the final sentence about 'citation' / 'source_url' seems extraneous and inconsistent with the stated return object (which does not include those fields), slightly undermining focus and tightness.

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?

Despite no output schema, the description fully covers return values, meaning of delta_pp, calibration context, and normalization. It also addresses performance, side semantics, and candidate limits. This is complete for an agent to invoke and interpret results correctly, leaving no major gaps.

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 only 20%, so the description carries the burden. The Args section adds critical semantics beyond the schema: my_heroes (0-4), enemy_heroes (0-5), candidates (1-150, full-roster sweep), my_side default ('radiant'). It also clarifies what each parameter represents in the draft context. This fully compensates for the sparse 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's purpose with a specific verb and resource: 'Score MANY candidate next-picks for a Dota 2 draft in ONE call.' It explicitly distinguishes itself from the sibling tool predict_dota_winrate by emphasizing batch processing and one-call efficiency, making the tool's unique scope unambiguous.

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 when-to-use guidance is provided: 'Use this instead of looping predict_dota_winrate over candidates' and explains the benefit ('much faster and cheaper for everyone'). It also clarifies that it uses the same production model, giving a clear alternative and rationale, which satisfies usage guidance fully.

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 readOnly, openWorld, and destructive annotations, the description reveals important behavioral traits: it is backed by a live auto-retrained model, reports calibrated probabilities, ignores skill/rank/execution, and requires verbatim reporting plus source citation. There is no contradiction with 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 front-loaded with the core purpose and structured into calibration, limitations, args, and output handling. It is slightly repetitive around 'report verbatim' and 'report the number verbatim', but nearly every sentence carries a constraint or usage instruction.

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?

Given that no output schema is present, the description adequately covers the returned calibrated win percentages and the citation/source_url to present to the user. It also covers input constraints, model provenance, and important limitations, making it complete enough for correct invocation and result reporting.

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 documents only the context parameter well (33% coverage), so the description must explain the hero parameters. It does: each team takes exactly 6 heroes, names/aliases are accepted and normalized internally. The context parameter is left to the schema, which covers it thoroughly, so there is no meaningful 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 opening sentence states the tool's function as a calibrated 6v6 win probability for any Marvel Rivals draft, naming the specific verb, resource, and scope. It is clearly distinguishable from sibling tools by game (Marvel Rivals vs Deadlock/Dota) and task (draft prediction vs static 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?

The description gives clear context for use: draft analysis only, not betting advice, composition-only, and requires exactly 6 heroes per team. It does not explicitly name alternative tools or state when not to use it, so it stops one step 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: the tool uses 'REAL observed pair data from batru.gg's match aggregation', ranks 'every hero not yet in the game', and answers with 'empirical numbers, not guesses.' It also specifies to 'Report numbers verbatim' and indicates the presence of 'citation'/'source_url' in the output. This methodology and behavior disclosure goes well beyond the minimum expected given 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 well-structured with a clear first sentence stating the purpose, followed by methodology, usage guidance, argument descriptions, and return format. It is front-loaded with the most important information. While it is somewhat long, every sentence adds value (e.g., the instruction about presenting the source URL is a concise behavioral note). There is no redundancy or 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?

Given the lack of an output schema, the description provides a detailed return format: '{recommendations:[{hero, score_pct, avg_winrate_vs_enemies_pct, enemy_matchups:[...], ...}]}'. It explains the blending logic for duo win rate, mentions the sort order ('sorted best-first'), and tells the agent to show the citation. It also addresses the draft-context by referring to the sibling 'predict_deadlock_draft'. This makes the tool largely self-contained for an AI agent, although the description could still clarify what happens with invalid hero names.

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 only 25% description coverage (only 'context' is described). The tool description compensates by explaining the other three parameters: 'enemy_heroes' (names/aliases, 1-6), 'my_heroes' (optional, 0-5), and 'limit' (default 5). It also notes that 'Hero names are normalised internally.' This adds meaningful semantics beyond the raw schema, though it does not enumerate valid aliases or edge cases. The 'context' parameter is already well-documented in 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's purpose: 'Recommend Deadlock heroes to pick against the given enemy hero(es).' It explains the methodology (match-weighted win rate and duo synergy) and explicitly differentiates from the sibling 'predict_deadlock_draft' by noting this is a 'pair-stat heuristic' best used before the full draft is set. The verb 'Recommend' and the resource 'Deadlock heroes' are specific, and the scope ('against the given enemy hero(es)') leaves no ambiguity.

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 clear when-to-use guidance: it is for getting counter picks during drafting. It explicitly states when NOT to use it: 'once both teams have 6, verify the full draft with predict_deadlock_draft.' This is a direct reference to an alternative sibling tool for the later drafting stage. It also mentions blending duo win rate when teammates are provided, implying the optional usage of 'my_heroes'. The guidance is precise and 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?

The description explains calibration meaning, internal hero name normalization, return list length, and the instruction to show citation/source_url. These details go beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) and add valuable behavioral context. 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?

Each paragraph has a distinct purpose: purpose, calibration/normalization, Args, and output/usage. The description is front-loaded with the main functionality and contains no redundant 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?

With no output schema, the description fills in the return shape and provides usage instructions. It misses the required context parameter and edge cases like empty hero lists, but covers the core functionality thoroughly enough for an agent to correctly invoke 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 description explains my_heroes (0-4), enemy_heroes (0-5), and my_side default/meaning, which the schema leaves as bare titles. However, it omits the required context parameter entirely, which has a detailed schema description but is absent from the Args section, possibly causing an agent to overlook its 15-25 word instruction.

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 opening sentence clearly states the tool recommends the top 3 Dota 2 heroes to pick next with calibrated win rates. This distinguishes it from sibling tools like get_dota_counters or predict_dota_winrate by focusing on actionable draft recommendations.

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 clear context for when to use the tool: given your already-picked heroes and enemy draft, it recommends the next best picks. It does not explicitly mention exclusions or alternatives, but the use case is strongly implied and the Args section clarifies input constraints.

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`, `openWorldHint: true`, and `destructiveHint: false`, so the bar is lower for the description. The description adds valuable context about the algorithmic approach (match-weighted win rate, duo win rate blending) and the data source ('batru.gg'), but does not disclose specifics like rate limits, API costs, or what happens if a hero name fails to normalize.

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 well-structured with clear sections for purpose, method, comparison, and parameters. It is efficient but includes a slight redundancy with 'Report numbers verbatim' (implied by returning raw data) and the instruction to show via `citation`/`source_url` which are not documented in the return structure.

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 recommendation tool with 4 parameters, no output schema, and 25% schema coverage, the description is comprehensive. It explains the algorithm, data source, return format, and relationship to sibling tools. The return format is described in enough detail for an agent to parse the output. Minor gap: the description references `citation` and `source_url` in the return object, but these are not explicitly documented in the return structure.

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 low at 25%, so the description must compensate. It does so effectively by explaining the semantics of `enemy_heroes` ('Enemy heroes to pick against'), `my_heroes` ('Optional — heroes your team already has (0-5)'), and `limit` ('Max recommendations to return (default 5)') in clear prose, and details the return structure. The `context` parameter's semantics are thoroughly explained in the schema. The description adds significant value beyond the sparse 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 highly specific verbs ('recommend', 'counters') and resources ('Marvel Rivals heroes'), defines the precise input/output format, and directly distinguishes itself from the sibling tool `predict_marvel_rivals_draft` by clarifying it is a 'pair-stat heuristic' and not the 'calibrated draft model'.

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 states when to use this tool ('Recommend... to pick against the given enemy hero(es)') and provides a clear escalation path to `predict_marvel_rivals_draft` for the full 6v6 scenario. It lacks explicit exclusions for when not to use it (e.g., if the user wants a synergy-only analysis vs counters).

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