ARAM Mayhem

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral detail - 'when published' implies unpublished augments may return no data - but says nothing about return shape, error behavior, or localization fallback.

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?

Two compact sentences with no padding; the returned-attribute list is front-loaded and the input-form note follows. Slightly list-heavy phrasing rather than prose, but nothing is wasted.

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?

No output schema exists, and the description at least enumerates the returned fields, which helps. However, with two parameters at 0% schema coverage and no explanation of 'locale' or of what happens for unpublished augments, the definition is only minimally sufficient for correct invocation.

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 0% for 2 parameters, so the description must compensate. It does clarify that the 'augment' parameter accepts either a localized name or an id, which is real added value, but the 'locale' parameter is never explained despite localization being the theme of the sentence.

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 specific resource (augment) and enumerates the returned attributes: description, rarity, availability and statistics. It's a clear lookup/retrieval purpose, though it is phrased as a noun list rather than a verb+resource statement, and it does not explicitly contrast itself with siblings like get_champion_build or get_tier_list.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. The only usage hint is 'Accepts localized names or ids', which addresses input form rather than selection context.

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two real behavioral facts — the builds are 'measured' (empirical, not theoretical) and identifier formats are flexible across locales — but says nothing about data freshness, sample size, or returned structure.

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?

Two sentences, zero filler, with the payload description front-loaded ahead of the input-format note. Every clause earns its place.

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 two-parameter read tool whose annotations cover the safety profile, the definition is minimally adequate. However, with no output schema and no annotation detail on returns, the agent gets no sense of response shape, and the locale parameter is entirely unexplained — a clear gap rather than a fatal one.

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 0%, so the description must carry the load. It usefully characterizes the required 'champion' parameter as accepting ids, names and aliases across all site locales, which is genuinely beyond the bare 'string' in the schema. It says nothing about the 'locale' parameter's accepted values or its 'en' default, leaving one of two parameters undocumented.

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+resource: it returns 'measured item builds and skill orders' for a champion, which is more concrete than a generic 'get data' claim. It is reasonably distinguishable from get_tier_list and get_top_combos, though it never explicitly contrasts itself with them, so it stops short of 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?

There is no when-to-use guidance and no named alternative. The only contextual cue is 'for a champion', which tells the agent the input shape but not when this tool beats get_top_combos or get_tier_list, both of which plausibly overlap.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so safety is covered. The description adds two genuine behavioral facts beyond the annotations: the newest-patch default and the English fallback when a translation is missing. It does not cover ordering details, pagination, or error behavior for unknown patches.

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?

A single compact sentence chain with no waste; the default ordering is front-loaded and the format hint follows immediately. The leading 'Site' qualifier is the only mildly ambiguous element.

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, two-optional-parameter lookup with no output schema, the description covers the essentials: what it returns, the default selection, the accepted patch format, and the localization caveat. It is thin on return shape and invalid-input handling, but annotations and the low complexity limit how much more is needed.

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 0%, so the description must carry the load and it does partially: it gives the accepted patch string formats ('26.20' or '26-20'), confirms newest is the default when 'patch' is omitted, and explains the consequence of an unavailable translation for 'locale'. Neither parameter is named directly, so the mapping is inferential rather than explicit.

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 resource ('Site patch notes') and implies a listing ordered newest-first, but never supplies a verb such as 'retrieve' or 'list'. An agent can guess the intent, yet the phrasing is closer to a fragment than a stated purpose. Siblings are different resources entirely, so no sibling differentiation is needed or provided.

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?

'Newest by default' hints that this is the right tool for the latest notes and that the patch argument is optional, but there is no explicit when-to-use, no when-not-to-use, and no alternative named. The agent must infer that omitting 'patch' yields the current patch.

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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds no behavioral context at all — not what the link set contains, not whether locale changes the result, not the return shape.

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?

It is a single short fragment, so there is no bloat, but it is under-specified rather than economical — the brevity costs meaning, and it is not front-loaded with a usable action statement.

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 simple read-only link tool with no output schema, the description should at least say what links are returned and how locale affects them. As written, an agent cannot confidently predict the response or when this tool is the right choice.

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?

There is one parameter (locale, default 'en') with 0% schema description coverage, so the description needs to compensate and does not. It never mentions locale, its accepted values, or what changing it does.

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 two concrete resources ('ARAM Mayhem pages' and the 'MCP setup guide'), which hints this returns canonical links, but it is a noun fragment with no verb stating what the tool actually does with them. It is distinguishable from siblings like get_champion_build or get_patch_notes only by inference.

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?

No indication of when to call this tool, what locale is for, or how it relates to alternatives such as get_patch_notes or search. The agent must guess the triggering scenario entirely.

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, non-destructive), so they carry little weight here. The description adds genuinely new behavior: results are paginated in site rank order, which tells the agent that offset windows are stable and ordered by rank rather than by name or id.

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 short sentences, zero filler, with the payload description front-loaded and the caveat about role immediately after. Nothing could be removed without losing information.

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 must carry the return-value burden, and it does so only at a high level (tiers plus win/pick rates). Combined with 0% schema coverage on five parameters, an agent can call it but still does not know the shape of tier values or the record structure.

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 0% across five parameters, so the description must compensate. It does resolve the most error-prone one — role takes champion class tags (Fighter, Tank, Mage) rather than lane positions, which matches the enum and prevents a likely misuse. tier, limit, offset, and locale remain unexplained, though limit/offset/locale are largely self-evident from defaults and bounds.

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 concrete resource and payload: champion tiers plus public win/pick rates, which is specific enough to separate it from get_champion_build or get_top_combos. It stops short of explicitly naming how it differs from those siblings, so it lands just below the top.

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?

There is no statement of when to choose this tool over get_champion_build, get_top_combos, or search, and no prerequisites or exclusions. The only guidance-like sentence concerns how to interpret the role filter, which is parameter clarification rather than usage routing.

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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful provenance context - the data is editorial curation, not measured performance - which helps an agent calibrate trust. It says nothing about pagination, locale behavior, or result size, so it stays at an adequate 3.

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?

Two tight sentences with no filler, and the core purpose is front-loaded before the caveat. It is well-sized for the tool's simplicity, though the second sentence is doing double duty as both a scope statement and the only guidance offered.

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 tool with no output schema, three fully undocumented parameters, and no annotation-level detail on return shape, the description leaves the agent without filter semantics or result expectations. The provenance caveat is valuable but does not fill the parameter and output gaps.

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 0% across three parameters (limit, locale, champion), and the description adds no meaning for any of them - it does not explain what 'champion' filters on, how 'locale' affects results, or how 'limit' interacts with editorial ordering. With such a low coverage rate the description was expected to compensate and does not.

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 a specific resource (curated public combos) and a specific ordering principle (editorial tier), and it clarifies what 'top' does NOT mean by ruling out measured win rates and vote rankings. That contrast implicitly separates it from data-driven siblings like get_tier_list, though no sibling is named explicitly.

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?

The line 'These are suggestions, not measured win rates or vote rankings' implies when to reach for this tool (qualitative editorial picks rather than statistical rankings), but there is no explicit when-to-use statement, no prerequisites, and no named alternative. Usage must be inferred from the caveat.

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds the cross-locale search scope, which is modest added context, but it does not clarify result count, ranking, or how the stated all-locale search interacts with the locale parameter.

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?

A single compact sentence with the resource scope front-loaded and no filler. It is appropriately sized, though the ambiguity it introduces about locales slightly undercuts its efficiency.

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 simple annotated read tool with no output schema, the description is minimally viable but thin: with 0% parameter documentation it should at least explain limit behavior and the locale default. Nothing an agent needs to avoid a wrong call is stated, but nothing critical is missing either.

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 0%, so the description carries the full burden and does almost none of it: query semantics, the limit default/max of 10/30, and the locale default of "en" are all left unexplained. The phrase "across all site locales" even muddies what the locale parameter does.

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 ("Search") and the exact resource set (champion and augment names, aliases, augment descriptions), plus a scope qualifier. It is clearly a discovery/lookup tool, distinguishable in kind from the get_* siblings, though it never names an alternative to sharpen the boundary.

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?

No when-to-use guidance, no prerequisites, and no mention of the sibling getters it naturally feeds into (e.g., find a name here, then call get_augment or get_champion_build). Usage must be inferred entirely from the verb.

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