Live game events

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is largely covered. The description adds real value by stating the prerequisite (active match on port 2999) and the incremental cursor behavior via afterId, which the annotations do not convey. A 4 reflects that it adds behavior beyond annotations without fully covering failure modes (e.g., what happens if no match is running).

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?

Four sentences, each carrying distinct information: purpose, usage, alternative, behavior, prerequisite. It is front-loaded with the core purpose. Slightly long but no sentence is filler, so it earns its size.

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, single-parameter tool whose annotations already cover safety, the description supplies the missing runtime prerequisite and cursor semantics. No output schema exists, but the description implies a list of events without detailing shape; that omission keeps it from 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% and there is one optional parameter with a clear schema description. The description mentions 'Supports incremental cursor via afterId', which reinforces the schema but adds no syntax, format, or edge-case detail beyond it. Baseline 3 is appropriate when the schema already documents the 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 states a specific verb ('Retrieve') and resource ('in-game events'), and enumerates the event types (kills, objectives, turrets, aces). It distinguishes from the sibling lol_game_all, which is named as the broader alternative. It does not, however, differentiate from other lol_game_* siblings like lol_game_stats or lol_game_player as clearly as a 5 would require.

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 states when to use ('track recent in-match actions or feed an event timeline') and names an alternative ('For full match state including player inventories, use lol_game_all instead'). It does not state when NOT to use it or contrast with lol_game_stats, so it stops short of a 5.

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