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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context: scope is limited to 'most recent finished' matches, the opponent filter is optional, and it instructs citing Liquipedia. It omits anything on limits beyond the schema's max of 3 or the return shape, so a 3 is fair.

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?

Content is front-loaded: what is returned comes first, the opponent option next, usage cues and the citation note last. Three sentences, each carrying information, with no filler. Slightly dense enumeration of fields, but nothing that should be cut.

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 must convey return contents, and it does so thoroughly (scores, overtime, length, kills, maps, MVPs, champion picks). Combined with annotations covering the read-only profile, an agent has enough to call it correctly; only a brief note on the 1-3 match limit would fully close the gap.

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 all four parameters (team, wiki, limit, opponent) are already documented in the schema. The description reinforces the optional-opponent filtering intent but adds no syntax or format detail beyond what the schema provides. 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 resource and the exact granularity returned: game-level details (scores, overtime, length, kills, maps, MVPs, champion picks) for a team's most recent finished matches. This clearly distinguishes it from outcome-level siblings like get_results and get_matches_between by content depth. It stops short of naming those siblings explicitly, so it falls just under 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?

It gives concrete usage context via example follow-up questions ('was it close?', 'who played which champion?') and notes the optional opponent filter, which helps an agent decide when to reach for this over summary tools. There is no explicit when-not guidance or named alternative, so it is clear context without exclusions.

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?

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses the finished-vs-'not played yet' return semantics, top-tier filtering and how include_minor_types changes it, the whole-day handling for unannounced times, the 50-match cap with a cutoff notice, and the citation requirement. This is unusually rich 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?

Front-loads the core purpose (time range, wikis, count) before moving to filtering and edge-case rules, so the most important information comes first. The later sentences are dense and somewhat run-on, but each carries distinct, non-redundant rules.

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 shape (score/winner for finished, 'not played yet' otherwise, per-stage summaries, 50-match cutoff notice). Combined with its handling of the 31-day and unannounced-time constraints, an agent has everything needed 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 coverage is 100%, so the baseline is 3, but the description adds interaction meaning the schema lacks: it explains that max_tier and include_minor_types only take effect 'without a team' and how the tier filter interacts with minor event types. It stops short of covering wikis/team syntax 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?

States a specific verb and resource ('all matches between two UTC timestamps ... for one or more wikis') and adds scope constraints (max 31 days, chronological order). It clearly reads as a time-range list tool, but it never names its closest siblings (get_upcoming, get_results) to sharply delimit itself from them.

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 usage framing ('what's on this weekend', 'what happened yesterday') and states the default filtering behavior when no team is supplied, which helps an agent decide when this tool fits. However, it offers no explicit when-to-use-this-vs-alternative guidance against get_upcoming or get_results.

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 cover the safety profile (readOnly, idempotent, openWorld), and the description goes well beyond them: it discloses the default top-tier-only filtering, the conditional enrichment of champion picks and MVPs when 3 or fewer matches return, and two output-handling rules (read each line independently, do not invent totals). That is rich behavioral context for a read tool.

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?

Content is front-loaded: what returns first, then filter behavior, then the conditional detail, then output rules. Six sentences is on the long side but each carries distinct information; the closing citation/anti-totals instructions are publisher requirements rather than 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?

With no output schema, the description carries the return-format burden and does so: line-by-line results, series score, winner, per-game scores, plus the low-count enrichment case. Filters, defaults, and the required wiki argument are all covered, so an agent has everything needed to call and interpret 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 baseline is 3. The description adds value the schema fields do not: it explains the interaction rules — that max_tier and include_minor_types are inert unless no team/tournament filter is supplied, and that team and tournament combine as an AND/OR filter set rather than independent switches.

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 ('finished matches') and immediately enumerates the payload: series score, winner by name, and every game's score. This content profile distinguishes it from get_upcoming (future matches) and get_match_details (single-match depth) 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?

Gives clear operating context: filter by team and/or exact tournament name, and without either filter only top-tier matches return. It does not name when to prefer get_match_details or get_matches_between instead, so an agent must infer the boundary from the payload description rather than being routed explicitly.

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 (readOnly, idempotent, openWorld), but the description adds real behavioral context: team lookups resolve the current phase and name a scheduled next phase, tournament lookups return all groups of the newest stage, and a 'Not started yet' table has no leader. The row-level contents are also disclosed. Remaining gap is any note on result size or ambiguity when multiple phases match.

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 preferred path is front-loaded in the first sentence after the resource statement, and each following sentence adds distinct information (alternate mode, row fields, edge case, citation). It is dense but has no filler; only slightly long.

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: it enumerates row fields and handles the degenerate 'Not started yet' case, plus both input modes. An agent has everything needed to call and interpret the result.

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, and the description earns above that by explaining the semantic relationship between team and tournament (two mutually alternative entry points) and the practical advantage of each, information the schema descriptions do not convey.

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 the exact resource ('League, group or Swiss standings') and immediately explains the two retrieval modes, which maps cleanly onto the two optional parameters. It is clearly distinct from siblings like get_results and get_upcoming, though it opens with a noun phrase rather than an explicit verb.

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 states a preference ('Preferred: pass the team'), explains why that path is preferable (finds the phase the team is currently playing in, works when you only know 'Worlds' or 'LCK'), and gives the explicit alternative condition ('Alternatively pass the exact tournament name'). The when-to-use decision is fully 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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds real output conventions: times in UTC, 'TBA' when only the day is known, exclusion of TBD pairings, and the attribution requirement. These are useful behaviors beyond structured fields, though return shape beyond date/time is not detailed.

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 scope and output order, then layered with filter behavior and caveats in a single dense paragraph. Every sentence carries information, though the tier/qualifier clause is slightly compressed and requires a second read.

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 6-param, no-output-schema read tool, the description covers ordering, time format, filter defaults, score-handling, and TBD exclusion, which is everything an agent needs to call and interpret it correctly. Remaining details (list size) live in the schema's limit parameter.

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 team, tournament, max_tier, and include_minor_types fully, including the tier semantics and the 'only used without team/tournament' coupling. The description's parameter content largely restates that; it elaborates the default tier behavior but adds little the schema does not already provide.

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?

Names a specific verb and resource ('Scheduled matches from now on, soonest first') and immediately separates itself from the results siblings by stating 'These matches have no result yet: never present them with a score.' An agent can tell it apart from get_results 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 context for when to apply filters ('Filter by team and/or exact tournament') and what the default behavior is without them ('only top-tier matches'). It stops short of explicitly naming alternatives (e.g. use get_results for finished games) or stating exclusions, so it is strong but not fully routing-aware.

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