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

Annotations already declare readOnlyHint and openWorldHint, but the description adds behavior the annotations cannot: the default status set ('finished and defwin together'), page size cap of 100, and paging contract via total and has_more. It stops short of stating ordering guarantees or whether upcoming matches are included by default, and does not repeat the safety profile, which is appropriate.

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 verb and resource, then filter enumeration, then the sibling routing in a final clause. It is dense but each sentence carries useful content; the enumeration of enum values is arguably redundant with a 100%-covered schema and could be trimmed.

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 an output schema exists, the description need not explain return values, yet it still names the match payload (teams, scores, winner, best-of, tournament, maps, AI prediction) and the paging fields, which helps an agent plan multi-page retrieval. Filters, defaults, and routing to the sibling statistics tool are all covered, leaving nothing an agent needs in order to call it correctly.

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

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

Schema description coverage is 100%, so the schema already explains game, from/to, status, tier, sort, offset and limit, including defaults and the inclusive-day semantics. The description restates the same filter families ('inclusive from/to day range', 'limit up to 100') without adding format or edge-case guidance, so baseline 3 applies.

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

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

States a specific verb and resource ('Returns BO3.gg esports match history for one game') plus the axes of variation (paging and filters). It also implicitly separates itself from single-match tools by scoping to 'one game' with list-style paging, so an agent can distinguish it from bo3_match or bo3_match_players without opening any 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?

Explicitly routes to a named alternative: 'use bo3_match_players for one match's player statistics,' and gives two positive use cases (results over a period, tournament tier). It does not mention other plausible siblings such as bo3_match, bo3_team_recent_matches or bo3_tournaments, so routing 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.