request_match_parse

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

No annotations are provided, so the description carries the full burden. It discloses the waiting behavior (default 45s, blocks), cost implication (counts as 10 API calls), and the outcome (unparsed vs parsed). It also clarifies the 'unfinished' status handling, giving the agent critical behavioral expectations beyond the schema.

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?

Three sentences: first states the core action and wait, second explains the value and next step, third covers cost and failure handling. Every sentence is informative and there's no filler. Slightly dense but still well-structured and front-loaded with the primary purpose.

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 having no output schema, the description covers what the agent needs: how to invoke, what to expect (waiting), cost, and follow-up actions. It also mentions the default wait and timeout tip. For a tool with only two parameters and no nested objects, this is complete.

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%: both match_id and wait_seconds have descriptions that explain their meaning. The description adds context about the default and timeout constraint but doesn't add new semantic depth beyond the schema. 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 states a specific action ('Submit a match for full replay parsing') and resource ('a match'), and differentiates from siblings by noting 'Unparsed matches lack teamfights/graphs/ward logs' and directing to get_match for the deep view. It clearly distinguishes this from get_parse_job_status and other match-related 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 explains when to use this tool (when a match is unparsed and needs parsing), what to do after completion (call get_match with include.teamfights), and the fallback behavior if unfinished (retry later or poll with get_parse_job_status). This is comprehensive usage guidance with alternatives named.

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