MCP server for World of Warcraft addon development: 20 tools giving Claude, Cursor and any MCP client the in-game Lua API, Blizzard's shipped UI source, CVars, FileDataIDs and texture atlases, plus Lua linting, TOC/XML validation and addon scaffolding. Retail, Classic, Classic Era and WoW Forever.
Hated WoW MCP demonstrates strong tool design with consistently well-named, well-described, and properly schematized tools. All 18 tools are explicitly registered with complete Zod schemas, descriptive titles, and tool annotations. Naming follows verb_noun conventions (wow_api_search, wow_lua_lint, wow_addon_scaffold). Descriptions are detailed and contextual, explaining WHEN and WHY to call each tool. Input schemas use Zod type definitions with descriptions for every parameter. However, output schemas are NOT formally documented in the visible code, only inline text rendering. Error handling provides recovery guidance but could be more systematic. One destructive tool (wow_addon_scaffold) lacks explicit confirmation/dry-run pattern. Overall, this is a well-engineered specialist toolkit that exceeds typical community MCP servers.
Generate a complete, working addon skeleton: .toc manifests for the chosen clients, an event-dispatch Core.lua with SavedVariables handling and a slash command, and optionally an XML frame template with its Lua mixin and a Settings-API options panel. Use this to start a new addon rather than writing boilerplate by hand. By default it only returns the files. With `write` it saves them into the addon folder, and it refuses if any of the files already exist unless `overwrite` is also set.
Check whether a function, event or type exists in each game client (retail, Classic progression, Classic Era, WoW Forever). Use this before writing code that has to run on more than one flavor, or to explain why something works on Classic but not retail.
Search the events an addon can register with frame:RegisterEvent, and show each event's payload arguments in order. Use this whenever writing an OnEvent handler, so the argument list matches what the client sends.
Search World of Warcraft's in-game Lua API — the functions an addon can call from inside the client. Covers namespaced functions (C_Item.GetItemInfo), legacy globals (UnitHealth), and widget methods (Frame:SetPoint). Results include full argument and return signatures. Use this before writing any addon code that calls the game.
Output schemas not formally documented. Tools render results as plain text via custom renderFunction/renderTable/renderEvent helpers. No explicit structured output type definitions exposed to LLM context. While text output is readable, it prevents downstream tool chaining and makes it harder for LLMs to extract structured data for follow-up operations.
wow_addon_scaffold is marked DESTRUCTIVE (file write/overwrite capability) but lacks confirmation or dry-run pattern. The tool accepts 'write' and 'overwrite' flags but does not implement a confirmation step before destructive file operations. An agent could overwrite an existing addon's files if overwrite=true without user confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Report which API index, UI source and game data sets this server has, when each was synced, and how large it is. Use this to confirm the data is present and current before relying on other tools.
Search the Enum.*, Constants.* and structure tables the in-game API uses — for example Enum.ItemQuality or the AuraData structure returned by C_UnitAuras. Searching for a member name finds the table that contains it.
Search the named texture atlas elements the UI uses with SetAtlas, the modern way to reference Blizzard art, since an atlas name carries its own size and coordinates. Returns dimensions, the sheet FileDataID and the exact SetAtlas call. Prefer atlases over raw texture paths for UI art. Atlases differ between clients, so name the flavor you are writing for: an atlas that exists on retail may not exist on WoW Forever or Classic.
Find the game's console variables — the settings behind SetCVar/GetCVar. Covers every CVar the client registers, and for the ones Blizzard's own UI touches, shows how it reads them, where, and what the options screen calls them. Use this before writing SetCVar, or to discover which CVar controls a piece of game behaviour.
Report which game data sets are synced — the file/FileDataID index and the texture atlas index — with counts and sync dates, and what to run for any that are missing. Use this when a game data lookup returns nothing.
Find game art and asset files by name, and get the FileDataID and texture path an addon needs to reference them. Covers every interface texture and icon (and models and maps when the full index is synced). A numeric query is treated as a FileDataID and resolved back to its path. Use this whenever writing SetTexture, SetNormalTexture or SetModel.
Search the game's icon textures by name and return the path and FileDataID for each. Icons follow a naming convention (spell_fire_*, inv_sword_*, ability_warrior_*), so searching by theme works well. Use this to pick an icon for a button, an addon compartment entry, or a .toc IconTexture.
Analyse addon Lua for problems specific to World of Warcraft: APIs that were removed or moved into a namespace in the target client, unknown events, taint (calling protected functions, overwriting Blizzard globals, touching secure frames in combat), and performance traps. Run this on any addon Lua before shipping it, and whenever porting between clients.
Validate a .toc manifest: interface version against the target client, flavor suffix consistency, unrecognised directives the client silently drops, SavedVariables names, and files listed but missing (or present but unlisted). Run this whenever an addon fails to load or shows as out of date.
Regex-search the full Lua and XML source of the 348 Blizzard addons that ship with the client. This is the ground truth for how the game itself does something — event handling, secure frames, data providers, layout. Use it when the API reference tells you what a function is but not how it is meant to be used.
Search the mixin tables Blizzard's UI uses — reusable method sets attached to frames via the XML mixin attribute or CreateFromMixins. Searching a method name finds the mixin that defines it. Use this to reuse Blizzard's behaviour or to understand what a template's methods do.
Read a Lua or XML file from Blizzard's shipped interface source, by the path that wow_ui_grep or wow_ui_template_search reported. Use this to see a full implementation in context rather than a single matching line.
Search the virtual XML templates that ship with the game — the frames an addon can inherit by name to get Blizzard's own look and behaviour (buttons, scroll lists, panels, tooltips). Shows the inheritance chain, attached mixins and where each is defined. Use this instead of writing frame art from scratch.
Validate WoW interface XML against Blizzard's own UI.xsd: unknown or misspelled elements and attributes, invalid nesting, bad enum values, and structural mistakes like a virtual frame with no name. Run this on every XML file an addon loads — the client silently ignores what it does not understand, so these mistakes are otherwise invisible.
Error handling is implicit and text-based. When searches return no results, tools return plain text messages like 'No API function matching...' without machine-readable error codes or recovery hints. LLMs must parse text to determine whether to retry, call an alternative tool, or inform the user. No structured error category (retryable, user-fixable, fatal).
Parameter 'limit' on multiple tools has no description ('limit':{'type':'integer','minimum':1,'maximum':100,'description':null}). While the constraint is clear from the schema, the description field is null, missing context about pagination behavior or why a limit is needed.