Batru — Competitive Game Intelligence for AI Agents

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

Annotations already mark readOnlyHint=true, and the description reinforces that the tool is read-only. It adds meaningful behavioral detail beyond annotations: MCP Apps render a compact card while other clients get JSON/text, Dota 2 supports partial drafts with calibrated probability and next-pick win rates, and Deadlock/Marvel Rivals only return calibrated probability for complete 6v6 drafts. This is exactly the kind of context that helps an agent understand side effects and output variability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The main behavior is front-loaded and well written, but the Args block repeats much of the schema's parameter documentation and includes a long privacy instruction already present in the schema. The sentence about presenting citation/source_url also feels misplaced. The description is adequate but not as tight as it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with this complexity, the description is thorough: it covers supported games, partial-draft behavior per game, output rendering differences, read-only semantics, and a presentation note for citations. Since an output schema exists, the description does not need to enumerate return fields in detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter. The description adds useful semantics beyond the schema, especially the count constraints: my_heroes is 0-5 for Dota 2 and 0-6 otherwise. Most other Args text duplicates schema descriptions, but this added constraint is valuable for avoiding invalid calls.

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: analyze a draft and render an interactive Batru win-rate board. It explicitly names the supported games and says it combines prediction and recommendation, which clearly distinguishes it from sibling tools like predict_winrate, recommend_pick, and get_matchup.

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 states when to use the tool: for visual draft, matchup, win-probability, or next-pick questions. It also explains that it combines existing prediction and recommendation tools. It does not explicitly list exclusion cases for individual sibling tools, but the guidance is strong enough for an agent to select it appropriately.

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 operation as read-only and non-destructive. The description adds useful behavioral context: it returns live document content, describes how text is structured, and instructs the agent to report numbers verbatim and cite the url. Error behavior is not covered, but that is a minor gap for a simple fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, examples are useful, and the return format is stated. The final presentation sentence is slightly redundant and uses field names like 'citation'/'source_url' that do not match the declared return object, but overall the description is well organized and 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?

Since there is no output schema, the description compensates by explaining the return object and the meaning of text. It provides enough id-format, citation, and presentation guidance for correct invocation, though failure behavior is left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by providing concrete id format examples and clarifying that the id comes from search results, which helps the agent construct valid calls.

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 action ('Fetch'), a specific resource ('the full live document'), and the entry point ('behind a search result id'). The included id examples and return shape make the purpose unambiguous and distinguishable from sibling search/get_* 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 explicitly establishes the intended workflow: this tool is used after search, with an id exactly as returned by search. It does not explicitly describe when not to use it or name alternative tools, so it lacks full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds behavioral context by noting the lack of Dota draft-phase export, requiring verbatim number reporting, and instructing the agent to show citation/source_url to the user. 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 compact and front-loaded, with a clear opening statement, an Args section, and two important output-handling rules. Every sentence adds value without unnecessary detail.

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?

All necessary call guidance is present: supported games, limit default, the alternative for Dota, verbatim reporting, and citation display. The context param is fully documented in the schema, and the absence of an output schema is mitigated by describing the return concept and required 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?

Schema description coverage is 100%, so the schema already documents game and limit thoroughly, including the Dota caveat and default. The description reinforces these but does not meaningfully extend them, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('draft-phase ban rates') and names the games it covers. Also distinguishes itself from get_tournament_stats by noting the Dota alternative, making its scope unambiguous among siblings.

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 when to use this tool: for Deadlock or Marvel Rivals draft-phase bans. It also names the alternative get_tournament_stats for pro Dota bans and explains why ranked Dota is not applicable. This gives clear routing guidance.

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

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

Beyond the readOnly/openWorld annotations, the description discloses meaningful behavior: hero names are normalized internally, winrate_pct > 50 means the queried hero beats the opponent, results are based on real observed win rates with sample sizes, and the agent should report the returned citation/source_url to the user. This exceeds what 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: a front-loaded purpose statement, a short explanation of the empirical nature, concise args, and a clear output convention. Every sentence contributes value, and the most important usage guidance appears first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool returns (best and worst matchups by win rate with sample sizes), how to call it (args, defaults, normalization), and how to present results (citation/source_url). Since there is no output schema, slightly more detail about the exact response shape would improve completeness, but the description is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers 100% of parameters, so the baseline is 3. The description adds useful semantics beyond the schema: the meaning of winrate_pct > 50, default limit of 12, internal hero name normalization, and the requirement to present the citation. It omits the required 'context' parameter from its Args summary, but the schema fully documents that 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 opens with a clear, specific statement of what the tool does: 'Who counters a hero (and who it beats) — measured matchup win rates for Dota 2, Deadlock or Marvel Rivals.' It names the resource (matchup counters), the action (get/measure), and the supported games, which distinguishes it from sibling tools like get_synergy or get_matchup.

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: this is for observed matchup win rates and empirical meta data, so an agent knows to call it when a user asks which heroes counter or are countered by a given hero. It does not explicitly name sibling alternatives or state when not to use it, but the context is strong enough to guide 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 cover read-only and non-destructive behavior. The description adds valuable context: the data source (batru.gg rolling match aggregation), the instruction to report numbers verbatim, and the requirement to present the citation/source_url to the user. These go beyond the annotations and inform the agent's output handling.

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 concise intro, an Args list mirroring the schema, and presentation instructions. It is slightly lengthy but each section serves a purpose. The main purpose is front-loaded, making it easy for an agent to quickly grasp the tool's function.

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 omits any mention of the required 'context' parameter, which is a significant omission because the schema mandates it but the description gives no guidance on how to fill it. Additionally, without an output schema, the description only hints at the return structure via the citation/source_url mention. These gaps reduce completeness for a tool that otherwise seems straightforward.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter is described in the input schema. The description adds a subtle clarification for the hero parameter (one hero's trend vs. the movers list) but does not explain the required 'context' parameter at all, which is a gap. Overall, the description provides minimal additional semantic value beyond what the schema already offers.

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: identifying heroes that are rising or falling based on week-over-week win-rate movement. It names the resource (hero momentum) and distinguishes it from siblings like get_tier_list and get_ban_rates by focusing on time-based trends rather than static rankings or ban percentages.

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 the two usage modes (movers list or a single hero's trend) but does not explicitly state when to prefer this tool over alternatives such as get_tier_list or get_counters. The 'when to use' is implied by the word 'momentum' but not made explicit, leaving the agent to infer the appropriate context.

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/safe, and the description adds genuine behavioral disclosures beyond them: the result includes sample size, names are normalised internally, the number must be reported verbatim, and the citation/source_url must be shown to the user. It does not cover edge cases like missing data or tiny sample sizes, which keeps it at 4.

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 compact and front-loaded with its most defining sentence ('One hero vs one opponent — the measured head-to-head win rate...'). The verbatim and citation instructions earn their place as output-contract guidance. However, the Args section is redundant with the fully-covered schema and omits context, so not every sentence pulls its weight.

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 4-required-param tool with no output schema, the description covers the essential return contract (the number, sample size, citation/source_url to display) and the normalization behavior. The only real gap is that the description's own arg summary omits the context parameter, though the schema fully documents it. Overall adequate-to-strong for a simple read-only lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 even with no parameter info in the description. The Args section largely restates the schema (game enum, hero, opponent) and adds no new meaning; 'names normalised internally' appears in both. Notably the Args list omits the required context parameter, so the description does not compensate for or even acknowledge the full parameter set. 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 first line states a specific verb and resource: one hero vs one opponent, the measured head-to-head win rate from real games in three named games. The explicit 'measured/direct matchup from real games' framing cleanly separates it from predictive siblings like predict_winrate, and the 'does X beat Y?' scope distinguishes it from get_synergy and get_counters. The title and description align well.

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 call it — 'the direct matchup number from real games' signals this is the empirical/measured tool for head-to-head questions. It does not name alternatives explicitly or state when-not-to-use, so it stops short of a 5, but the 'measured vs predicted' contrast is a strong practical routing signal.

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 safety profile is covered. The description adds that the ledger is auto-generated from an append-only log and nothing is hand-picked, plus presentation rules like reporting numbers verbatim and showing the citation/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 longer than average, yet each segment serves a purpose: core action, when-to-use, presentation guidance, argument semantics, return shape, and source-link instruction. It is front-loaded with the core purpose before diving into presentation details.

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 enumerates the exact return structure and instructs verbain reporting and source attribution. Together with annotations and full schema coverage for parameters, an agent has everything needed to invoke the tool 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 coverage is 100%, so the baseline is 3. The description clarifies that limit is 'newest first' and defaults to 10, a detail not in the schema, adding a bit of extra meaning. It does not elaborate on the required context parameter, which the schema already defines thoroughly.

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 'Get batru.gg's public model evatility ledger' — a specific verb, resource, and scope. It explicitly states the tool's role: returning every weekly test (wins and losses) and when to use it for model validation queries, distinguishing it from gameplay-analysis siblings.

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 says 'Use this when a user asks whether the model is any good or how it is validated,'which gives a clear trigger condition. It does not name alternative sibling tools or state when not to use it, so it falls short of an exhaustive routing guide.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context such as what 'check' entails, whether it makes a network call, or what side effects (if any) occur beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It quickly communicates the action and the conditions for use, making it efficient and easy to parse, though it could be slightly more structured with a separate usage note.

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 gives clear usage guidance but does not explain what the tool returns or what happens after 'checking' for tools. With no output schema present, the description carries the burden of explaining the result, which it fails to do. For a simple one-parameter tool, this is a notable gap, though not severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the single parameter 'context' is already documented with a clear description in the schema. The tool description adds no additional semantic meaning beyond what the schema provides, which aligns with the baseline of 3.

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: checking for additional tools when a task could benefit from specialized capabilities. It distinguishes itself from the sibling clipform_* tools by being a meta-tool for tool discovery rather than a domain-specific operation, though it does not explicitly name this distinction.

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 usage guidance: use this tool whenever specialized capabilities might help, even if existing tools could work as a fallback. This gives the agent a clear decision rule, though it does not mention when not to use it or list alternative 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 already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context beyond this: 'The hero name is normalised internally' discloses alias handling, 'Report numbers verbatim' and 'show the returned citation/source_url to the user' specify presentation behavior, and 'with sample sizes' signals data-quality transparency. This adds genuine behavioral value without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well front-loaded with the core purpose and includes useful usage directives, but the Args block redundantly restates schema parameter documentation, adding length without new information. The presentation instructions (verbatim reporting, citation display) are valuable but could be tightened. It is organized and readable, but not maximally 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?

With no output schema, the description partially compensates by describing the return content: best/worst allies, real observed win rates, sample sizes, and the presence of citation/source_url fields. For a moderate-complexity read-only tool whose safety profile is covered by annotations, the description provides sufficient information for an agent to call it correctly and present results properly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description's Args section largely repeats the schema's parameter docs (game enum, hero alias normalization, limit default 12). It adds marginal value by noting game is needed to disambiguate hero names and that hero names are normalized internally, but these are also echoed in the schema. No substantial meaning is added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: find best/duo partners for a hero based on measured together-win-rates. It clearly scopes to three named games and distinguishes itself from related siblings like get_counters (matchup win rates) and get_matchup (specific matchups) by focusing on ally synergies rather than enemy counters. The 'best teammates / duo partners' phrasing immediately conveys the purpose.

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 (finding synergy partners when a hero is chosen) and adds a game-scoping note, but it does not explicitly name alternatives or state when not to use this tool versus get_counters, get_matchup, or recommend_pick. Usage context is implied rather than explicit, so agents must infer the distinction from the purpose description.

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 annotations, it discloses that rankings come from real match aggregation 'not a guess,' that heroes are sorted best-first, that total_matches is the sample behind the ranking, and that results include citation/source_url to show the user. It also instructs reporting numbers verbatim. This is substantial added 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 front-loaded with the core purpose and keeps parameter documentation compact. It has slight redundancy with the schema's param descriptions, but the added notes on rank resolution and citation behavior earn their place. It is appropriately sized for a tool with four parameters.

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 describing return behavior: heroes sorted best-first, limit for max rows, total_matches as the sample size, and citation/source_url to display. It does not specify the exact response shape per hero, but it provides enough for an agent to invoke the tool and use the 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 coverage is 100%, so the schema already documents game, rank, limit, and context. The description adds extra meaning by explaining rank bands, stating that rank words like 'oracle' or 'eternus' also resolve, and clarifying that empty rank means all ranks combined. This goes beyond the schema's enum values.

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 phrase 'Best heroes right now — the current-patch tier list' states a specific verb, resource, and scope across three named games. It also communicates that results are 'Empirical rankings from batru.gg's match aggregation' and 'sorted best-first,' which cleanly distinguishes it from sibling tools like get_ban_rates or get_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 makes the use case clear: retrieve the current-patch tier list when the user wants the best heroes, optionally filtered by skill bracket. It does not explicitly name alternatives or exclusions, but the context is strong enough that an agent can infer when this tool is 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?

Annotations already mark it read-only, open-world, and non-destructive; the description adds useful caveats: data comes from parsed replays, only dota2 has box scores today, and the citation/source_url must be surfaced to the user. 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 core purpose, followed by a concise field list, parameter bullets, and a display instruction. The Args bullet list duplicates schema text somewhat, but the structure keeps it scannable and no part is misleading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even with no output schema, the description names the returned data fields and the citation/source_url display requirement, and the schema fully documents all parameters including the required context argument. An agent has everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The Args list mostly restates the schema's defaults and descriptions; the only extra semantic is grouping team/stage/match_id as filters, which is marginal.

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 'Per-game BOX SCORES from parsed replays of a pro Dota 2 tournament' and then enumerates exactly what each box score contains, such as lane winners, K/D/A, GPM, item timings, and Roshans. This clearly identifies a read-only retrieval of per-game stats and differentiates it from sibling tools like get_tournament_stats or get_ban_rates by scope and 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?

It gives clear context: use when per-game Dota 2 box scores are needed, with optional filters by team, stage, or match_id, and it notes that only 'dota2' is supported today. It does not explicitly name alternatives or say when not to use this tool, so it stops 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?

Beyond the readOnlyHint/openWorldHint annotations, the description warns that these are small-sample recorded results, not calibrated probabilities, and instructs the agent to display the returned citation/source_url. This provides meaningful behavioral context about data reliability and output handling without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a summary, followed by data caveats, example questions, Args, and a citation instruction. It is well organized and mostly efficient, though the Args section partially duplicates the schema.

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 enough by naming the returned metrics and the source-link requirement. It omits the required 'context' parameter from its Args summary, but the schema carries an extensive explanation for that parameter, so the tool remains callable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters, including defaults and the event slug format. The description adds little beyond restating the defaults and the 'only dota2' restriction, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (TI/EWC pro tournament stats) and the specific outputs (most-picked, most-banned, win rates per hero, standings). It is easy to understand what the tool returns, though it does not explicitly contrast itself with siblings like get_tournament_game_stats or get_ban_rates.

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 by focusing on aggregate tournament statistics and by listing example questions ('most picked / banned / contested at TI'). However, it never explicitly tells the agent when to prefer this tool over alternatives or when not to use it, leaving the sibling distinction to inference.

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 read-only annotations, the description discloses a critical backend behavior: unrecognised hero names are silently dropped. It also explains the error shape (did_you_mean candidates) and the empty-query roster response. This is valuable behavioral context an agent would not otherwise know.

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 appropriately sized and front-loaded with the core purpose. Subsequent sentences each add necessary operational detail: silent-drop warning, empty-query roster behavior, args, and return shapes. 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?

There is no output schema, so the description appropriately covers return values for all three cases: match, error, and roster list. Combined with the rich schema and safe annotations, an agent has everything needed to call this 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?

The schema already documents query and game with 100% coverage. The description slightly reinforces query semantics (empty string = roster) but largely repeats the schema and does not add deeper parameter-level insight. It also omits the required context parameter, although the schema describes it 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 first sentence states a specific verb (normalise), a specific resource (hero name/alias/shortName), and the fallback mode (list roster). It also tells the agent why this matters: the exact key batru.gg expects before prediction tools. This makes it clearly distinct from sibling prediction/stats 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?

Explicitly states when to use it: to convert messy user input before calling prediction tools. It also gives a conditional usage rule: if unsure which heroes exist, call with an empty query. This is actionable and contextual.

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 meaningful behavioral context beyond that: calibration details (60% means 60% empirical win rate), internal hero name normalization, per-game semantics (empty draft = 50/50, my_side ignored for non-Dota), and instruction to show citation/source_url. This enriches the agent's understanding without contradicting 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 clear sections for purpose, per-game semantics, and arguments. It's longer than average but every sentence adds value—no fluff. The front-loading of the core purpose and calibration is effective. Slightly verbose but appropriately so given the multi-game complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (three games, different draft rules), the description is remarkably complete. It covers per-game behavior, prerequisites (full vs partial drafts), alternative tools, return format, and presentation instructions. Without an output schema, the description fully explains what the tool returns and how to handle it, leaving no gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds extra semantics: explains the meaning of my_side (Radiant/Dire) in the context of the draft, notes that hero aliases are normalized, and clarifies that an empty draft yields 50/50. It also cross-references lookup_hero for valid hero names, which goes beyond the schema's basic descriptions.

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: predicting which team wins a draft, with calibrated win probabilities for three specific games. It distinguishes itself from siblings like recommend_pick (for partial drafts in non-Dota games) and predict_winrate_batch, making the purpose 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 guidance on when to use this tool vs alternatives: for dota2 it accepts partial drafts, for deadlock/marvel-rivals full rosters are required, and partial drafts in those games should use recommend_pick. It also instructs to report results verbatim and cite the source URL, providing clear operational context.

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, covering the safety profile. The description adds useful behavioral context beyond the annotations: the entire batch runs as one server-side model invoke, results are calibrated, each candidate includes a delta vs. the draft without it, and up to 150 candidates fit in a single call.

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: a front-loaded summary, explicit usage guidance, a compact Args list, and a return-format line. The Args section is somewhat redundant with the input schema, but for a six-parameter tool it is reasonably sized and the key behavioral points are placed before the redundant details.

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 schema coverage at 100%, no output schema, and annotations covering safety, the description supplies the remaining critical context: return shape, sorting (best-first), delta semantics, batch behavior, and supported game. It is complete enough for an agent to call the tool correctly, though a short example would have made it fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's Args block largely restates schema descriptions (e.g., my_heroes 0-4, candidates 1-150, my_side radiant/dire) without adding new semantic nuance beyond what the schema already documents.

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 action, resource, and scope: "Score MANY candidate next-picks for a Dota 2 draft in ONE call." It names the exact outputs (calibrated win rate, delta) and explicitly contrasts with the sibling predict_winrate, so an agent can immediately distinguish the batch tool from the single-pick tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing guidance: "Use this instead of looping predict_winrate over candidates" and explains why (a single model invoke server-side). It also sets a clear boundary with "Currently dota2-only," telling the agent not to use it for other games despite the enum containing more options.

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

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

The tool has annotations readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds behavioral context by explaining the difference between the calibrated model for Dota and the empirical heuristic for other games, and instructs to report win rates verbatim and show citations. This goes beyond the annotations, which only indicate read-only and open-world hints.

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 per-game semantics and a parameter list, but it is somewhat verbose with the long context parameter description and the instruction to report win rates. The core purpose is front-loaded, but the parameter list could be more concise by removing redundant information already in the schema.

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 is complete for a tool with no output schema, as it explains the return values (top 3 for Dota, limit for others, win rates to report) and how to present citations. It also covers cross-game differences and gives a clear call-to-action for verification with predict_winrate, making it fully adequate for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% as every parameter has a description. The description adds value by explaining the meaning of my_side (only for Dota), the limit's behavior (only for Deadlock/Marvel, Dota always returns top 3), and the context parameter's analytics purpose. It clarifies that my_heroes may be empty and reinforces the required nature of game and enemy_heroes, going beyond the schema's basic text.

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: recommending the best heroes to pick next against an enemy draft, and explicitly lists the supported games. It distinguishes itself from sibling tools by noting that for Deadlock/Marvel Rivals it uses real observed pair data and recommends verifying with predict_winrate, which helps differentiate it from other draft-analysis tools like analyze_draft or get_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 per-game semantics, explaining that Dota uses a calibrated model while other games use an empirical heuristic, and even suggests verifying full 6v6 with predict_winrate. However, it does not explicitly state when not to use this tool or mention alternatives beyond predict_winrate, but the context is sufficient for most use cases.

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 readOnlyHint=true and destructiveHint=false; the description adds that results are {results: [{id, title, url}]}, that data is computed from 140M+ real matches, and that the agent should call `fetch` with an id. It does not disclose pagination or result limits, but for a read-only search tool this is adequate.

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, followed by a compact topic list, a one-line data-provenance point, and a clear Args/Returns section. Every sentence contributes either scope, workflow, or return-format information, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers the search domain, data source, query examples, return shape, and the follow-up call to `fetch`; with no output schema this return description is necessary and present. It does not mention result ordering/count or error behavior, and it leaves `context` to the schema, so it is good but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema carries most of the parameter burden; the description still adds value with concrete query examples ('who counters axe dota', 'best deadlock heroes') and clarifies query is free-text. The Args section omits the required `context` parameter, but the schema fully documents it, so this is a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Search batru.gg's live competitive datasets') and names the covered games and topics. It differentiates itself from the get_* siblings by describing document-level search returns and telling the agent to pass a result id to `fetch`, which separates it from direct-data 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 when-to-use context by enumerating query intents: counters, synergies, tier lists, ban rates, tournament results, and the model's evaluation ledger. It does not explicitly list exclusions or name alternative siblings such as get_counters or get_ban_rates for direct stats, so it misses the full 5.

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