Batru — Competitive Game Intelligence for AI Agents

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

Goes well beyond the annotations by disclosing client-dependent rendering (MCP Apps card vs JSON/text fallback), and, importantly, that Dota 2 handles partial drafts with calibrated probabilities plus calibrated next-pick win rates while Deadlock/Marvel/LoL only return a probability for a complete roster and label partial-draft recommendations as empirical pair-data scores. It also specifies a citation/source_url presentation obligation. 'This tool is read-only' merely restates readOnlyHint=true, and nothing is said about rate limits or cost.

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?

Front-loaded: the core purpose and the 'when to use' sentence come first, then regime details, then args. The Args block largely restates schema fields and could be trimmed, but the prose is dense and nearly every sentence carries actionable information.

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?

An output schema exists, so the returns paragraph is redundant but harmless; the essential gaps are covered, including the cross-client rendering difference and the per-game complete-roster constraints that would otherwise cause agents to misread a missing win rate. The only real hole is that the required `context` argument is never mentioned in the description and no alternative-tool routing is given.

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, but the description adds real meaning beyond the schema: hero-count bounds per game (0-5 for Dota/LoL, 0-6 otherwise), that my_heroes may be empty for a fresh draft, and that my_side is Dota-only. It omits the required `context` parameter entirely, leaving that to 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?

States a specific verb+resource (analyze a draft, render a win-rate board) and immediately scopes it to draft, matchup, win-probability and next-pick questions across four named games. It also differentiates itself from siblings by saying it combines the existing prediction and recommendation tools, so an agent can tell it apart from predict_winrate and recommend_pick without opening either schema.

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

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

Gives clear usage context ('use this for visual draft, matchup, win-probability, or next-pick questions') and per-game applicability rules. It does not say when to prefer the narrower siblings (predict_winrate, recommend_pick, get_matchup) instead, so the routing decision is only half-specified.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the description's main contribution is the return shape, which matters since there is no output schema. That contribution is undercut by an internal inconsistency: it says the return is `{id, title, text, url}` but then instructs showing `citation` / `source_url`, fields not in the stated shape, leaving the agent unsure what to cite.

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, the id formats are grouped compactly, and nothing is padded. The closing citation sentence partially restates the earlier 'cite `url`' instruction, which is minor redundancy rather than bloat.

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 takes on the burden of describing the return value and the expected handling of numbers verbatim, which is the right material for this simple two-parameter tool. The `url` vs `citation`/`source_url` discrepancy is the one completeness gap an agent would notice at call time.

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 would be 3, but the description earns credit by exemplifying the `id` format with six concrete patterns (`dota2:counters:axe`, `deadlock:tier-list`, `model:track-record`), which tells an agent what a well-formed id looks like beyond the schema's 'exactly as returned by search' note.

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 pairing, 'Fetch the full live document behind a `search` result id,' which tells an agent exactly what it retrieves. It names the upstream sibling (`search`) but does not distinguish itself from the specialized getters (`get_counters`, `get_tier_list`, etc.), so it stops short of a 5.

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

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

Usage is implied through the dependency on a `search` result id, so an agent can infer the search-then-fetch sequence. However, there is no explicit statement of when to prefer this over the many topic-specific getters in the sibling list, which is a meaningful ambiguity given that overlap.

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 this a safe read-only, open-world call, so the bar is lower. The description still adds real behavioral guidance: report numbers verbatim, and surface the returned citation/source_url as the source link — output-handling rules the annotations cannot convey.

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

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

The 'most-banned heroes' purpose is front-loaded in the first clause, alternatives and output rules follow in short order, and no sentence is filler. The Args listing is mildly redundant with the schema but brief.

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 data tool with no output schema, the definition covers scope, the Dota fallback, and citation handling. The remaining gap is the mismatch between the four-value enum and the two games the description claims, which could cause a failed 'lol' call.

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 game and limit are already documented with an enum and a default of 15; the description's Args block largely restates them. It adds no new semantics and, worse, under-describes the enum by naming only two of the four accepted games.

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

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

The description names a specific resource and scope — 'most-banned heroes, measured draft-phase ban rates' — and explicitly restricts it to Deadlock/Marvel Rivals, which is enough to distinguish it from tier-list and matchup 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 explicitly excludes ranked Dota and redirects to get_tournament_stats for pro Dota bans, which is exactly the kind of routing an agent needs. It stops short of saying when to prefer this over get_tier_list or get_hero_momentum, and never mentions the 'lol' value that the schema enum permits.

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 only declare readOnly/openWorld/non-destructive, so the description adds real value: it says the data is empirical with sample sizes rather than modeled, that hero names are normalized internally, and that a citation/source_url must be surfaced to the user. Missing only rate-limit or fallback behavior for unknown heroes.

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 first sentence is front-loaded and dense with the key purpose and gap between the two data classes. The Args section duplicates schema content and the citation instruction is tacked on, but nothing is genuinely misleading or 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?

No output schema exists, and the description does cover the return shape well enough to act on — best/worst lists with win-rate percentages and sample sizes plus a citation field. A reader knows exactly what comes back and how to present it.

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 four parameters, and the Args block largely restates it (game values, hero normalization, limit default 12). The only addition beyond the schema is that hero accepts alias/shortName, which the schema also states.

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

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

States a specific verb and resource — measured matchup win rates showing who a hero counters and who counters it — for four named games. The 'best and worst matchups' framing does differentiate it from the sibling get_matchup, though it never names that sibling explicitly.

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

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

Gives an interpretation rule ('winrate_pct > 50 means hero beats that opponent') and an output instruction (report verbatim, show citation), which is useful. But it never says when to call this versus get_matchup, get_synergy, or recommend_pick, so the choice among siblings is left 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuinely non-structured context: the upstream citation obligation ('report numbers verbatim', show `citation`/`source_url`), which materially affects how an agent presents 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 purpose and data source are front-loaded in two sentences, and the output-hygiene note comes last. The Args block largely duplicates the schema descriptions, which is mild waste but keeps the call usable without schema lookup.

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?

No output schema exists, and the description only hints at the return shape via `citation`/`source_url`. It does not say what a momentum record contains (win-rate delta, sample size, window length), and the game-list mismatch with the schema leaves a real ambiguity for a read tool an agent may call speculatively.

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 enum, defaults, and empty-string semantics for `hero` are already documented — description adds little beyond restating them. It also introduces an inconsistency: the prose lists only dota2/deadlock/marvel-rivals while the schema enum includes "lol", leaving the agent unsure whether LoL is actually supported.

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

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

States a specific verb and resource — 'week-over-week win-rate movement' for heroes — plus the exact data source (batru.gg rolling match aggregation) and the two modes (movers list vs. single-hero trend). An agent can distinguish this from get_tier_list, get_ban_rates, or lookup_hero without opening a schema.

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?

Clear about the two call modes: omit `hero` for the biggest movers, supply `hero` for a single trend. It never names a sibling alternative (e.g. get_tier_list when the user wants absolute win rates rather than movement), so it stops short of a full 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 cover readOnly=false destructive and openWorld, and the description adds genuinely new context: results come from real games, include a sample size, names are normalised internally, and the number must be reported verbatim with the citation/source_url surfaced. It does not mention error/empty-result behavior or rate limits, keeping it below a 5.

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?

Front-loaded with the core statement in the first line, followed by a clarification set and the output/citation instruction. The Args block is redundant with the 100%-covered schema and costs some space, but overall the text is tight and every remaining sentence carries an 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?

With no output schema, the description carries the return-value burden and does so adequately: it says the result is a win rate with sample size plus a citation/source_url. It leaves open the failure mode for invalid or unrecognized hero names, which prevents a 5.

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 the game enum and the context field. The description's Args block largely restates these, adding only 'Names are normalised internally', which is already present in the schema descriptions for hero and opponent.

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

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

States a specific verb+resource (measured head-to-head win rate for one hero vs one opponent) and adds the distinguishing scope 'direct matchup number' versus the sibling tools get_counters/predict_winrate. The four supported games are named up front, so an agent can tell immediately whether it applies.

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 is implied by 'the direct matchup number (does X beat Y?)', which signals a query-style call, but no sibling or alternative is named and there are no when-not-to-use conditions. An agent must infer on its own that get_counters or predict_winrate is the better choice for other questions.

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 the safety profile (readOnly, non-destructive, openWorld), and the description adds substantial context beyond them: the ledger is auto-generated from an append-only promotion log with nothing hand-picked, plus how to interpret and present the metrics (lead with ECE, don't headline raw accuracy because balanced drafts inflate it).

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?

Front-loaded with what the tool returns, followed by usage, presentation guidance, and args. The presentation instructions are lengthy but each sentence carries actionable value; only minor trimming is possible.

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 fully specifies the return shape (generated_at, ledger, totals, per-evaluation promote/ece/bce/acc/holdout_n), warns to report numbers verbatim, and instructs surfacing the citation/source_url. An agent has everything needed to call 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 100% and both parameters are documented in the schema, so the baseline is 3. The description reiterates that limit returns newest-first entries but adds no syntax or meaning beyond the schema; its extra detail is about the return payload, not the parameters.

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

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

States a specific verb and resource — the public model evaluation ledger of every weekly champion-vs-challenger test — and clarifies it includes wins AND losses. This is clearly distinguishable from hero/matchup/draft siblings like get_tier_list or analyze_draft.

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

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

Gives an explicit trigger: 'Use this when a user asks whether the model is any good or how it is validated.' That is a clear usage context. It does not name alternatives or state when-not to use it, so it falls just short of the top band.

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?

The description adds significant operational context beyond the standard safety annotations, such as stating the data is based on 'real observed win rate when picked together' and mandating specific output behavior ('Report numbers verbatim,' 'show the returned citation / source_url').

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 definition is comprehensive, requiring several paragraphs to cover methodology, parameter constraints, and output rules. While slightly verbose, its comprehensive structure ensures that every complex instruction—especially for the 'context' argument—is found and prioritized.

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

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

The definition is complete for a complex data retrieval tool. It defines the methodology, the required input framing (context rules), and the expected output format (verbatim numbers, citations), leaving no major ambiguity.

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?

Although schema coverage is 100%, the description provides crucial semantics for non-obvious fields. Specifically, it explains the internal hero name normalization and details the extreme constraints for the 'context' parameter (length, tone, and strict anonymization rules).

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 tool clearly defines its purpose: providing 'Best teammates / duo partners for a hero.' It specifies the metric (together-win-rates) and lists the supported games, immediately distinguishing itself from general win rate or matchup 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 implies the usage scenario (finding duo partners). While it doesn't explicitly state, 'Do not use get_counters,' the clear definition of 'synergy' versus 'counter/matchup' provides adequate guidance 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 declare readOnly/openWorld/non-destructive, so the description is free to add real behavioral context: the data source (batru.gg match aggregation), best-first sort order, the semantics of empty rank (all ranks combined, LoL pre-filtered to Diamond+), and the meaning of `total_matches` as the sample behind the ranking. It even instructs the agent to surface the citation/source_url, which is not derivable from annotations.

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

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

The core purpose is front-loaded in the first sentence, then args, then output/citation guidance — a logical order. It loses a point for re-listing the game enum and rank brackets that the schema already documents, which is mild redundancy rather than waste.

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

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

With no output schema, the description still covers the essentials an agent needs: source provenance, sort order, sample-size field, and the citation requirement for presenting results. Nothing material is missing for correct invocation or 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?

Schema coverage is 100%, so baseline is 3, but the description adds value beyond the schema: it notes that rank words like 'oracle' or 'eternus' also resolve, and it defines `total_matches` as the ranking sample size rather than just a row count. The game and rank enumerations are largely duplicated from the schema, which caps it below 5.

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

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

States a specific verb+resource ('current-patch tier list' of 'best heroes right now') and enumerates the four supported games, which lets an agent separate it from siblings like get_ban_rates, get_hero_momentum or predict_winrate without opening a schema. It also adds the meaningful qualifier that rankings are empirical match aggregation, not a guess.

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?

Clear on when this applies (current best-hero rankings for a given game/patch) and how to scope it with `rank` and `limit`. It does not explicitly route the agent away from siblings or state when-not to use it (e.g. 'use get_ban_rates for ban data'), so it falls short of the explicit-alternatives bar.

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

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

Annotations already declare readOnly, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact stat payload per game (lane winners at 10 min, K/D/A, GPM, net worth, item timings, first blood, Roshans, comeback flags) and the note that each returned game is a full box score, which affects limit choices. It doesn't disclose pagination or data-coverage limits across events.

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 opening sentence front-loads purpose, and the field enumeration gives an agent a quick sense of payload. The Args block duplicates schema content and is somewhat redundant, but the citation instruction at the end earns its place for presentation behavior.

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 enumerating the returned fields and flagging that each game is a full box score. Combined with annotations covering safety and open-world access, an agent has enough to call 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 100%, so every parameter already has documented semantics and defaults. The description's Args block largely restates the schema (defaults for event/limit, the dota2-only caveat) with only marginal added nuance, so the 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?

States a specific verb and resource — per-game box scores from parsed replays of a pro Dota 2 tournament — and its emphasis on 'per-game' implicitly contrasts with the aggregate get_tournament_stats sibling. However, it never names that sibling explicitly, so the differentiation requires inference.

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 that you can filter by team, stage, or a single match_id, which implies when the tool is useful, but it gives no explicit 'use this instead of X when...' guidance relative to get_tournament_stats or get_matchup. Usage is implied rather than directed.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the bar is lower. The description still adds real value: it warns that samples are small and not probabilities, and it instructs the agent to surface the returned `citation` / `source_url` to the user — an output-handling requirement annotations cannot express.

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, the small-sample caveat and the citation instruction are all front-loaded and each sentence earns its place. The trailing Args block largely restates the schema and is the only redundant portion.

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 query tool with no output schema, it covers scope, data provenance, sample-size caveat, and required output attribution. It does not state whether results are paginated or how many rows the hero tables can contain beyond `limit`, but nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so 3 is the baseline. The description does add example slugs, but it diverges from the schema: the description offers 'esports-world-cup-2026' while the schema says 'ewc-2026', and it claims game supports only 'dota2' while the enum lists four values — a mild inconsistency rather than added clarity.

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 names the exact resource and scope: pro tournament stats for TI/EWC with most-picked, most-banned and win rates per hero. It also distinguishes itself from sibling prediction tools by stating the data is 'real recorded results... not calibrated probabilities', which separates it from predict_winrate and get_model_track_record.

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 concrete triggering questions ('most picked / banned / contested at TI', 'who won', 'group standings'), which is clear usage context. It stops short of naming alternatives explicitly (e.g. get_ban_rates or get_tier_list for non-tournament data), so there is no explicit when-not to use it.

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 the safety profile (readOnlyHint, destructiveHint=false), yet the description adds a genuinely non-obvious backend trait: unrecognised hero names are SILENTLY DROPPED, so callers must normalise first. It also discloses the failure mode (error with `did_you_mean` candidates) and the two distinct return shapes, which annotations cannot convey.

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

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

Purpose and the critical silent-drop warning are front-loaded before the mechanics, and the empty-query mode is called out early in caps. The trailing 'Args:' section duplicates the schema and the 'Returns' section could be trimmed slightly, but there is little true waste.

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

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

For a 3-param lookup with no output schema, the description covers the missing pieces: both return shapes, the error/`did_you_mean` path, the supported game values, and the downstream contract with the prediction tools. An agent has everything needed to call it correctly on the first attempt.

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

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

Schema description coverage is 100% and the schema already documents the empty-string roster behaviour and the game values, so the 'Args:' block largely restates structured data. The description adds only mild framing value (that the query is 'as the user typed it'), so the 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?

States a specific verb and resource ('Normalise a hero name/alias/shortName to its canonical identity') and explicitly adds a second mode ('or list the whole roster'). The description makes clear this is a preprocessing/identity-resolution tool, distinct from the prediction siblings like predict_winrate or recommend_pick.

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

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

Gives an explicit when-to-use rule ('turn messy user input ... into the exact key batru.gg expects before calling the prediction tools') and an explicit alternative path ('Not sure which heroes exist? Call it with an EMPTY query'). The ordering constraint relative to sibling tools is spelled out, not inferred.

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 annotations, it discloses model provenance, calibration behavior, hero-name normalization, empty-draft behavior, and the need to report returned probabilities verbatim. It also tells the agent to surface citation/source_url, which is meaningful behavioral context for presenting 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 front-loaded with purpose and then organized by game, which suits the complexity. The Args section partly duplicates the input schema and omits context, so it is not maximally tight, but it remains readable and purposeful.

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 complex four-game prediction tool with no output schema, the description is complete enough: it covers input requirements, game-specific semantics, return values, and citation behavior. An agent has the information needed to call it correctly and present results 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 already 100%, but the description adds useful cross-parameter semantics: Dota allows partial drafts, Deadlock and Marvel Rivals require full 6v6, and LoL requires full 5v5 rosters in role order. It does not explain the required context parameter, 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 clearly states that this tool predicts calibrated draft win probability and names the supported games. It also distinguishes its scope from siblings by directing partial-draft Deadlock/Marvel Rivals users to recommend_pick instead.

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 per-game usage rules, including when full rosters are required and when my_side is ignored, and it names recommend_pick as the alternative for partial drafts in two games. It does not address other close siblings such as predict_winrate_batch or analyze_draft, so the routing guidance is strong but not exhaustive.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered; the description adds substantive context beyond that: the batch runs as a single server-side model invoke, results are calibrated and sorted best-first, deltas are relative to the draft without the candidate, and the agent is instructed to report results verbatim and surface the citation/source_url. That is real operational detail an agent needs.

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?

Strongly front-loaded: the core purpose and the sibling comparison come first, then args, then return shape and the citation instruction. Slightly padded by restating schema-derived details (default 'radiant', 'Only dota2 today' appearing twice) and by a reference to citation/source_url fields that aren't in the documented return shape.

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?

No output schema exists, but the description fills that gap by spelling out the return object ({baseline_win_rate_pct, candidates:[{hero, shortName, win_rate_pct, delta_pp}]}) and its best-first sorting. Combined with explicit candidate limits and the dota2-only constraint, an agent has everything needed to invoke and interpret the tool.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including the required context parameter that the description omits from its Args list. The ranges quoted in the description (0-4, 0-5, 1-150, radiant default, dota2-only) largely restate the schema descriptions rather than adding new semantics, so the 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?

States a specific verb and resource: score many candidate next-picks for a Dota 2 draft in one call, returning calibrated win rate plus delta. It explicitly distinguishes itself from the sibling predict_winrate by contrasting single vs. batch invocation, so an agent can choose between them without opening either schema.

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

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

Gives explicit routing guidance: 'Use this instead of looping predict_winrate over candidates' names the alternative and the condition that selects this tool. It also states an exclusion ('Currently dota2-only') and a capacity limit ('up to 150 candidates fits in one call'), covering when the batch approach is and isn't viable.

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, open-world, and non-destructive behavior. The description adds substantial context beyond annotations: model differences by game, empirical-vs-calibrated caveat, Dota-only my_side, Dota's fixed top 3, limit behavior elsewhere, and instructions to report win rates verbatim and show the citation/source_url.

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?

Front-loaded with purpose and structured with per-game semantics plus Args. It is appropriately sized for a complex multi-game tool, though the Args list repeats schema-covered details and slightly reduces concision.

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 six parameters, no output schema, and cross-game behavior, the description provides enough detail about return values, model limitations, and required user-facing citation behavior for an agent to call 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 100%, so the baseline is 3, but the description adds meaningful semantics: game-specific scoring, my_side applies only to Dota, limit applies only to non-Dota games, and Dota always returns top 3. Some parameter details duplicate the schema, but the added per-game meaning is useful.

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 action and resource: recommending best heroes to pick next against a draft, across four named games. It also distinguishes per-game scoring behavior and returns, so an agent can tell what the tool does without opening the schema.

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?

Explains that Dota 2 uses the calibrated draft model while Deadlock, Marvel Rivals, and LoL use empirical pair data, and says to verify full rosters with predict_winrate. It does not explicitly compare against analyze_draft or other sibling draft tools, so the when-to-use guidance is clear but not exhaustive.

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 safety (readOnlyHint true, destructiveHint false, openWorldHint true), and the description adds real value beyond them: data provenance (computed from 140M+ matches by a production pipeline, 'measured numbers, not model guesses') and the exact return shape plus the fetch handoff. It does not mention result-count caps, ranking/scoring behavior, or data freshness, which are the remaining behavioral unknowns for a search endpoint.

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?

Front-loaded with the core action and scope, then examples, then a return-value contract — a sensible order. The 'Args: query' block largely restates the schema's own parameter documentation, and the 'measured numbers, not model guesses' line is promotional, so a few sentences don't fully earn their place, but nothing is confusing or 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?

No output schema exists, and the description compensates by specifying the return shape ({results: [{id, title, url}]}) and how to continue to fetch — the key information for a search tool. The notable omission is the mandatory `context` parameter, which an agent reading only prose would not know it must supply, though the schema documents it thoroughly.

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

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

Schema description coverage is 100%, so baseline would be 3; the description earns an extra point by giving four concrete natural-language query examples ('who counters axe dota', 'marvel rivals mantis duo') that demonstrate the expected phrasing style, which the schema does not convey. The required `context` analytics parameter is not mentioned at all in the description, leaving that gap to 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?

States a specific verb and resource ('Search batru.gg's live competitive datasets') and enumerates the game domains it covers, so the agent knows exactly what corpus is being queried. It also names the follow-up tool ('Pass a result's `id` to `fetch`'), which distinguishes it as a discovery layer. However, the listed content types (hero counters, tier lists, ban rates) overlap directly with structured siblings like get_counters, get_ban_rates and get_tier_list without stating the difference.

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

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

Gives concrete triggering contexts — hero counters, synergies/duos, patch tier lists, ban rates, pro tournament results, model ledger — which is a clear 'when to use'. The chaining instruction to fetch by `id` clarifies its place in the workflow. It stops short of naming when NOT to use it versus the specialized get_* siblings that return the same class of data in structured form.

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