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

Annotations already declare readOnlyHint and openWorldHint, so the burden is lower. The description adds genuine behavioral context beyond them: player data is withheld until OpenDota has parsed the replay, and account IDs, chat, replay salts and raw telemetry are excluded from the response. It does not cover error behavior for invalid/negative IDs, but the availability caveat is the material one.

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?

Single dense paragraph with the core return contract front-loaded, followed by input provenance, availability caveat, exclusions, and a cross-reference. The long field enumeration (hero IDs, K/D/A, last hits, GPM/XPM, net worth, damage) is somewhat redundant given an output schema exists, but it is not padding.

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

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

For a single-ID read tool with full schema coverage, annotations, and an output schema, this covers everything an agent needs: where the ID comes from, that parsing gates player data, and what fields are deliberately absent. Nothing required for a correct call 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 coverage is 100% and the schema already states "Required positive OpenDota match ID copied from ..." including the source tools. The description largely mirrors that text, adding no format or boundary details (e.g., ID ranges, what happens with a non-existent ID). Baseline 3 is appropriate when the schema does the work.

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 a compact summary and parsed player lines for one Dota 2 match") and enumerates the payload contents. It also implicitly distinguishes itself from the ID-producing siblings (opendota_live, opendota_pro_matches, opendota_league_matches, opendota_league_match_ids) by naming them as ID sources rather than alternatives.

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 preconditions: the ID must come from one of four named siblings, must be positive, and hero IDs must be resolved via opendota_heroes. It does not explicitly state when NOT to use it (e.g., for aggregate/team-level data), so it stops short of full exclusion guidance.

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