TalentAnvil

get_character

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.

Input Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it declares the default sections, the ~20k token budget and the truncated_sections escape hatch, the exact shape of talents (active loadout only, loadout code, per-talent fields), the compact equipment layout, and that raids/dungeons are current-expansion only. These are behavioral traits no structured field conveys, with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and defaults are front-loaded and nearly every clause earns its place given 14 parameters and 20 sections. The single dense paragraph makes it hard to scan, and a bulleted per-section layout would have been tighter, keeping it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with no output schema, the description covers return shape for the high-value sections (talents, equipment, M+, achievements) and explains the truncation contract. An agent has everything needed to call it and interpret the response without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already high (86%), but the description still adds operative meaning: include_inactive_loadouts yields other specs' loadout codes, achievements_limit/offset page achievement_category and tracking has_more, and achievement_category accepts a name-or-id with ambiguity resolution. This goes beyond the schema descriptions for the most interaction-heavy params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Look up a live World of Warcraft character from Blizzard's armory") and enumerates the returnable sections, so the agent instantly knows its scope. It also names the sibling it hands off to ("pass it to decode_build") and every raw talent payload is distinguished from the build generators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description routes the agent through the tool's own sub-flows well: defaults are stated, achievement_category vs achievement_ids vs achievement_statistics are distinguished, and raid_expansions/dungeon_expansions are given for non-current content. It stops short of an explicit when-not-to-use rule against siblings like get_talents or generate_build, which would be needed for a 5.

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

All TalentAnvil tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?