WoW talent builds for every class and spec: valid, importable loadout strings plus popular builds.
Scored across 8 tools
Each tool has a clearly distinct role in the talent/build workflow: fetching characters, specs, talents, spells, popular builds, decoding, generating, and comparing builds. The closest overlap is between popular_builds and compare_character, but compare_character is explicitly a character-vs-meta comparison while popular_builds retrieves aggregate builds. Selection should be unambiguous.
Seven of eight tools follow a consistent snake_case verb_noun pattern such as get_character, get_talents, decode_build, and compare_character. The only deviation is popular_builds, which is noun-only rather than a verb-led name like get_popular_builds. This is a minor inconsistency but still readable.
Eight tools is well-scoped for a WoW talent/build analysis server, with each tool covering a distinct stage of the workflow. There is no obvious bloat, and the set is neither too thin nor too large.
The surface covers the core lifecycle well: list specs, inspect talents/spells, fetch characters, retrieve popular builds, generate/decode loadouts, and compare a character against the meta. A minor gap is the lack of tools to enumerate available content, bosses, or dungeons for popular_builds and compare_character inputs, which may force the agent to rely on outside knowledge.
Compare a live character's active talent loadout with the most popular build for their spec (Warcraft Logs raid kills and the Mythic+ leaderboards, current raid tier). By default it compares against the spec's overall build (All Dungeons or All Bosses, the best-sampled first); pass content_name and/or difficulty to pick a dungeon or boss. Returns both loadout strings and hero trees, plus the differences: talents only the character has, talents only the popular build has, and rank and choice differences.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Character name. | |
| realm | Yes | Realm name or slug, e.g. "Area 52" or "area-52". | |
| region | No | us | |
| difficulty | No | ||
| content_name | No | Boss or dungeon name (partial match ok), or "All Bosses" / "All Dungeons". Omit for the overall build. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only and open-world, so safety is covered. The description adds useful context beyond annotations: data sources (Warcraft Logs raid kills, Mythic+ leaderboards), current raid tier scope, and the default sampling preference (best-sampled first).
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 dense but front-loaded sentences: comparison target first, then default/override mechanics, then return shape. Slightly packed but every clause carries 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 still describes return values (both loadout strings, hero trees, and the specific diff categories). Complete enough for an agent to call and interpret results, though the exact response shape is only described, not structured.
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 60%, and the description compensates by clarifying content_name behavior (omit for overall build, boss/dungeon or 'All' options) and difficulty's role in selecting the comparison target. Doesn't explain region semantics, but that's minor given its enum and default.
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 (compare) and precise resources (live character's talent loadout vs. popular spec build), and names the data sources. An agent can distinguish this from popular_builds (which returns builds without comparison) and get_character (which doesn't compare).
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?
Explains defaults clearly (overall spec build, All Dungeons/All Bosses) and instructs how to narrow scope via content_name/difficulty. Doesn't explicitly contrast against sibling tools like generate_build or popular_builds, but the when-to-use context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a loadout string into its class/spec and the selected talents, each with its rank and max_ranks.
| Name | Required | Description | Default |
|---|---|---|---|
| loadout_string | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful output detail (class/spec and talents with rank/max_ranks), but does not disclose failure behavior for invalid or malformed loadout strings.
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, front-loaded sentence that states the action and the returned data with no filler. Every clause contributes meaning.
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?
The description covers the decoded output reasonably well for a tool with no output schema, but it omits input format details and error behavior. For a decoder, knowing what a valid loadout string looks like is important context that 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 description coverage is 0%, so the description must compensate for the single parameter. It only repeats the phrase 'loadout string' without explaining the expected format or syntax, adding little beyond the parameter name.
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 ('Decode') and resource ('loadout string') and specifies the decoded outputs (class/spec, selected talents with rank and max_ranks). It is clear, though it does not explicitly differentiate itself from siblings like get_talents or generate_build.
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 guidance on when to use this tool versus alternatives such as get_talents or generate_build. Usage is only implied by the presence of a loadout string parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a valid, importable loadout string for a class/spec. Provide talents to include (by name or id), an optional hero tree, and priority talents to fill remaining points. The solver enforces prerequisites, gates, and budgets.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| class | Yes | ||
| include | No | ||
| hero_tree | No | ||
| priorities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description is consistent with a non-mutating generator. Beyond the annotations it discloses real behavior: the solver enforces prerequisites, gates, and budgets, so the agent knows constraints are resolved rather than blindly assembled. It stops short of saying what happens on unresolvable talent names or conflicts.
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, front-loaded with the product, then parameters, then solver behavior. No filler and nothing important buried.
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 correctly states the return value is an importable loadout string. For a 5-param generator with only readOnly annotations, the remaining gap is edge-case behavior (invalid names, unsatisfiable budgets), which is noticeable but not blocking.
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 0%, so the description carries the parameter burden and largely does: it explains include (talents to include, accepted 'by name or id'), hero_tree (optional), and priorities (fills remaining points). Only class and spec are left as bare names, which is close to self-evident.
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 product: 'Produce a valid, importable loadout string for a class/spec.' That is clearly distinct from decode_build (the inverse) and popular_builds, though it never names a sibling to route against 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?
Says how to call it ('Provide talents to include... an optional hero tree, and priority talents') but gives no when-to-use framing, no prerequisites, and no indication of when to prefer decode_build or popular_builds instead. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a live World of Warcraft character from Blizzard's armory: profile summary (class, spec, level, item level, guild, faction) plus the sections you ask for — gear, talents, stats, M+, raid and dungeon progress, professions, PvP, achievements, collections, and more. Defaults to equipment, talents, stats, mythic_plus. Talents return only the active spec's active loadout: hero tree, the importable talent_loadout_code (pass it to decode_build), and each talent as {node_id, talent_id, name, rank}; set include_inactive_loadouts for every other saved loadout's code. Equipment is compact: equipped item level, then per item slot, name, item level, track (name_description), stats, gems, enchants, spell/proc text, set and bonus_list; set bonuses sit once in equipped_item_sets. mythic_plus returns the current season's rating and the best run per dungeon. raids and dungeons cover the current expansion only, newest release first and Mythic → Raid Finder; use raid_expansions / dungeon_expansions for others. achievements returns a summary (total points, completed count, recent completions, per-category progress); use achievement_category (paged with achievements_limit / achievements_offset) to list completions in one category, or achievement_ids to check specific achievements with criteria progress. achievement_statistics lists its categories; use statistics_category for the values. pets is name/species/level/quality; completed_quests is quest ids. Results are kept under ~20k tokens: anything left out to fit is listed in truncated_sections with the request that fetches it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Character name. | |
| realm | Yes | Realm name or slug, e.g. "Area 52" or "area-52". | |
| region | No | us | |
| sections | No | ||
| achievement_ids | No | With the achievements section: completion status and date for each id, plus criteria progress for incomplete ones. | |
| raid_expansions | No | Raid progress to include: "current" (default, the newest expansion), "all", or a list of journal expansion ids. | current |
| achievements_limit | No | Page size for achievement_category. | |
| dungeon_expansions | No | Dungeon progress to include: "current" (default, the newest expansion), "all", or a list of journal expansion ids. | current |
| achievements_offset | No | Skip this many completions in achievement_category (page on has_more). | |
| statistics_category | No | With the achievement_statistics section: return the statistics in this category (name or id). | |
| achievement_category | No | With the achievements section: list completed achievements (id, name, completed date, points) in this category and its subcategories, newest first. A category name (e.g. "Midnight Raid") or id; an ambiguous name returns the matching ids. | |
| include_cosmetic_slots | No | Also include the shirt and tabard slots in equipment. | |
| include_inactive_loadouts | No | Also list every other saved loadout (all specs) as spec + talent_loadout_code. | |
| include_mythic_plus_seasons | No | Also list the ids of every M+ season the character has played. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely supplemental behavior — live armory fetch, ~20k token budget, and the truncated_sections contract listing what was dropped and how to fetch it. It also discloses that talents return only the active spec's active loadout unless include_inactive_loadouts is set, and that raids/dungeons cover the current expansion newest-first, Mythic → Raid Finder.
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 purpose and defaults are front-loaded, and the dense clauses each carry information relevant to a 14-parameter tool. It is one undivided block, though, with section-by-section behavior compressed into run-on clauses that reward re-reading rather than skimming.
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 large, no-output-schema read tool the description covers the return shapes section by section (gear, talents, M+, raids/dungeons, achievements, pets, quests) plus the truncation fallback, which is exactly what an agent needs before choosing sections. Nothing material about invoking it correctly is left unstated.
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 high (86%), so the baseline is 3; the description still adds real meaning beyond the schema, such as the per-item equipment shape (name, item level, track, stats, gems, enchants, bonus_list, set bonuses once in equipped_item_sets) and the {node_id, talent_id, name, rank} talent shape. Some parameter restatement (limit/offset paging, category selectors) duplicates what the schema already says, keeping it below a 5.
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?
Opens with a specific verb and resource plus data source ("Look up a live World of Warcraft character from Blizzard's armory") and enumerates exactly what is returned. It distinguishes itself from siblings by routing talent_loadout_code to decode_build, so an agent can tell it apart from get_talents and compare_character without opening the 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 concrete usage rules: default sections are equipment/talents/stats/mythic_plus, use achievement_category vs achievement_ids for different achievement needs, raid_expansions/dungeon_expansions for older content, statistics_category for stat values. It never states when to prefer a sibling like get_talents or compare_character, so it stops short of a full when/when-not/alternatives treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Blizzard details for a spell — name and full effect description — by spell id (from get_talents) or by name. Data is refreshed daily, so it reflects the live patch rather than stale training data.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| spell_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description usefully adds that data is refreshed daily rather than stale training data. However, with both parameters optional it never says which key wins if both are given, nor what happens if neither is — a real behavioral ambiguity for a lookup 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?
Two tight sentences: the core action and lookup keys are front-loaded, and the freshness note follows as a single supporting clause. No restatement of the tool name, no 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?
For a simple, read-only two-parameter lookup with annotations covering safety and no output schema, the description covers purpose, inputs, and data recency. Only the edge-case behavior (both keys present, no key present, unknown spell) is left unstated.
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 does add meaning by tying spell_id to get_talents and presenting name as an alternative key. It does not clarify precedence, requiredness (both are optional per schema), or accepted name formats such as casing or partial names.
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?
Specific verb and resource ('Get ... details for a spell') plus the exact payload ('name and full effect description') and both lookup keys. It also routes the agent to get_talents as the source of spell ids, which distinguishes it from that sibling 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?
It states the two ways to call it (by id sourced from get_talents, or by name) and reassures the agent that results track the live patch. It stops short of saying what happens when both keys are supplied or when a lookup fails, so there are no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the selectable talents for a class/spec (id, name, effect description, spell id, sub-tree, hero tree, choices). Call this before generate_build so you know the talent names and what each one does. Use get_spell for the full, freshest detail on any spell id.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: it lists the returned fields (including sub-tree, hero tree, choices) and the phrase "freshest detail" on get_spell implicitly signals this tool's data may be cached or less current — a useful behavioral trait. It stops short of stating pagination, size of result, or data provenance, so not a 5.
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, front-loaded with purpose, then the field list, then the dependency/alternative. Every sentence changes how an agent would act and none is redundant.
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, enumerating the returned fields is the right compensating move, and the downstream dependency on generate_build is stated. The one gap is that it never says how to discover valid class/spec values, despite a list_specs sibling existing — for a 2-required-param tool with zero schema documentation, that is the missing piece.
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 both required parameters, so the description carries the full burden — and it only implies them via the phrase "for a class/spec". It gives no format or casing guidance (e.g., 'Druid' vs 'druid', whether spec alone is acceptable), and does not point at list_specs as the way to obtain valid combinations, which is the most likely failure mode for this call.
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 ("List the selectable talents for a class/spec") and enumerates the returned fields, so the agent knows exactly what comes back. It also separates itself from generate_build (downstream consumer) and get_spell (detail lookup), so it is distinguishable from siblings without opening a 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?
Explicit sequencing guidance ("Call this before generate_build") plus an explicit alternative for a different need ("Use get_spell for the full, freshest detail on any spell id"). Both the when and the when-not are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every class/spec available, with the slugs used by the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered structurally. The description adds a meaningful behavioral trait beyond that: it returns the *complete* set ("every"), so an agent knows not to expect pagination or partial results.
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 sentence with zero filler, front-loaded on the verb and resource, with the most agent-relevant detail (slugs for other tools) placed where it will be read first.
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 zero-parameter, read-only lookup with no output schema, the description supplies enough: what is enumerated and what identifier form comes back. It stops short of describing the entry shape (e.g. whether specs are nested under classes), which would have closed the last 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?
The tool takes no parameters, so per the baseline this is a 4. The description correctly implies the call is unconditional and requires no filtering input.
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 ("List every class/spec available") and adds the payload detail that matters — the slugs other tools consume. It is clearly distinguishable from the action-oriented siblings (generate_build, compare_character, decode_build), though it never names 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?
The clause "with the slugs used by the other tools" gives clear context for when to call it: as a discovery step before any tool that takes a class/spec identifier. There are no explicit exclusions or named alternatives, but for a zero-argument enumeration tool no real alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the importable loadout that players actually ran to kill a raid boss (or clear an M+ dungeon), aggregated from Warcraft Logs and the M+ leaderboards, for a class/spec. Pass a boss/dungeon name, or a general all-round build for the whole content: "All Bosses" for a raid (set difficulty to normal/heroic/mythic), or "All Dungeons" for M+ (set difficulty to "mythic_plus"). Returns the modal build string, sample size, and per-choice pick frequencies.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| class | Yes | ||
| difficulty | No | ||
| content_name | Yes | Boss or dungeon name (partial match ok). Use "All Bosses" for the overall raid build, or "All Dungeons" for the overall M+ build. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful behavioral context: it discloses the data sources (Warcraft Logs, M+ leaderboards) and specifies return values (modal build string, sample size, per-choice pick frequencies), which are not captured by annotations.
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, front-loaded with purpose, then usage instructions, then return values. No wasted words; every sentence adds necessary 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?
The tool has 4 parameters (3 required), low schema coverage, and no output schema. The description adequately covers purpose, content_name/difficulty usage, and return values, but lacks detail on class/spec formats and when difficulty is optional versus required. For an agent to call it correctly, more parameter semantics would be helpful.
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 only 25% (only content_name has a description), so the description must compensate. It does explain content_name usage ("All Bosses", "All Dungeons") and clarifies difficulty values for general builds. However, it does not explain the expected format for class and spec parameters, leaving a gap.
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 (Get), resource (importable loadout), and scope (players actually ran to kill a raid boss or clear an M+ dungeon), with data sources (Warcraft Logs, M+ leaderboards). Distinguishes from siblings like generate_build (AI-generated) and decode_build (decoding) by emphasizing real-world aggregated data.
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?
Provides clear guidance on how to use the content_name and difficulty parameters for different content types, but does not mention when to use this tool versus alternatives such as generate_build or get_talents. Usage is implied by the described use case rather than explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_character1 field changedInput schema / properties / region / enumPrevious value: -[
- "us",
- "eu",
- "kr",
- "tw",
- "cn"
-]New value: +[
+ "us",
+ "eu",
+ "kr",
+ "tw"
+]get_character1 field changedInput schema / properties / region / enumPrevious value: -[
- "us",
- "eu",
- "kr",
- "tw",
- "cn"
-]New value: +[
+ "us",
+ "eu",
+ "kr",
+ "tw"
+]compare_characterdecode_buildgenerate_buildget_characterget_spellget_talentslist_specspopular_buildsWoW: Forever lore and player-observed drops, vendors, quests, professions and talents, with sources.
ARAM Mayhem builds, tiers, augments, combos and patch notes with canonical page citations.
League of Legends ranked ladders, cutoffs, player profiles, live games, champion stats and builds.
Recruiter-grade boolean/x-ray search strings from a 20-year sourcing playbook.
Add one secure layer between your agents and this server.