Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WoW Armory MCP Server look up character Thrall on realm Draenor"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to World of Warcraft Armory data and functionality.
This MCP server enables AI assistants to interact with World of Warcraft character information through Blizzard's Armory website, providing tools for character lookups and reputation tracking.
Related MCP server: wow-mcp
Python 3.8 or higher
uv package manager
Git
Clone the repository:
git clone <repository-url>
cd wow-armory-mcpSet up virtual environment:
uv venvInstall dependencies:
uv pip install -r pyproject.tomlNote: The command installs dependencies from
pyproject.tomlrather than a traditionalrequirements.txtfile.
To use this MCP server with Claude Desktop, add the following configuration to your Claude Desktop settings:
Location of config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Configuration:
{
"mcpServers": {
"wow-armory": {
"command": "uv",
"args": [
"--directory",
"/path/to/your/wow-armory-mcp",
"run",
"server.py"
]
}
}
}Important: Replace
/path/to/your/wow-armory-mcpwith the actual absolute path to your cloned repository.
If your server requires API credentials or configuration, create a .env file in the project root:
# Add any required environment variables here
# Example:
# WOW_API_KEY=your_api_key_hereOnce configured, restart Claude Desktop. The WoW Armory server will automatically start when Claude needs to access WoW-related information.
The server provides tools for interacting with WoW Armory data:
Character Information - Get detailed character information including level, class, race, and gear
Character Reputation - Retrieve character reputation standings with various factions
For development and testing:
# Activate the virtual environment
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Run the server
python server.pywow-armory-mcp/
├── server.py # Main MCP server implementation
├── pyproject.toml # Project dependencies and metadata
├── .env # Environment variables (create this)
├── README.md # This file
└── src/ # Source code directory
├── __init__.py
├── armory/ # Armory API client
├── tools/ # MCP tool implementations
└── utils/ # Utility functions"Command not found: uv"
Install uv following the official documentation
"Permission denied" errors
Ensure the path in your Claude Desktop config uses forward slashes, even on Windows
Verify the absolute path is correct
API authentication failures
Verify any required API credentials are properly configured
Check your .env file if authentication is required
Server won't start
Verify all dependencies are installed: uv pip list
Check the server logs for specific error messages
Enable debug logging by setting the environment variable:
export MCP_LOG_LEVEL=debugFork the repository
Create a feature branch: git checkout -b feature-name
Make your changes and add tests
Commit your changes: git commit -am 'Add some feature'
Push to the branch: git push origin feature-name
Submit a pull request
MIT License
Copyright (c) 2025 Daniel Franklin
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
For issues and questions:
Open an issue on GitHub
Check the MCP documentation
Review Blizzard's Armory website documentation
Initial release
Basic character and guild lookup functionality
Integration with Claude Desktop
Retrieves the World of Warcraft character page from Blizzard's Armory website. The LLM can then interpret this page to answer questions about the character.
| Name | Required | Description | Default |
|---|---|---|---|
| realm | Yes | The realm (server) where the character resides. E.g., 'akama' | |
| character_name | Yes | The name of the character to retrieve information for. E.g., 'bob' |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It communicates the main behavior—retrieving a web page—and indicates the output is page content rather than structured data, but it does not disclose potential concerns like page size, parsing difficulty, external site availability, rate limits, or error behavior.
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 description is two concise sentences: the first states the action, the second states the purpose. Both sentences earn their place and the key information is front-loaded.
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 two-parameter retrieval tool with an output schema, the description names the resource, the returned artifact, and the intended downstream use. It could add sibling guidance or behavioral caveats, but nothing critical is missing 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?
The schema already documents both parameters with examples and has 100% description coverage, so the baseline is 3. The description adds no additional parameter-level detail or format constraints.
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 clearly states it retrieves the World of Warcraft character page from Blizzard's Armory, which is a specific verb and resource. It does not explicitly call out the sibling tool get_character_reputation, so differentiation relies on the phrase 'character page' rather than a direct contrast.
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 second sentence provides a clear intended use: the LLM can interpret the returned page to answer questions about the character. It gives context but does not mention when to use get_character_reputation instead, so explicit when-not/alternative guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the World of Warcraft character reputation page from Blizzard's Armory website. The LLM can then interpret this page to answer questions about the character.
| Name | Required | Description | Default |
|---|---|---|---|
| realm | Yes | The realm (server) where the character resides. E.g., 'akama' | |
| character_name | Yes | The name of the character to retrieve information for. E.g., 'bob' |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the tool fetches a webpage from an external site, but provides no information about possible errors, rate limits, authentication, page format, or how the output is structured. This is minimal disclosure for the agent to predict runtime behavior.
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, both earning their place. The action and resource are front-loaded, and the second sentence clarifies how the output should be consumed. There is no filler, redundancy, or irrelevant detail.
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 is simple (2-param read operation) and an output schema exists, so the description need not explain return values. It is adequate for basic invocation, but it lacks any mention of when to prefer this over get_character_info or what to expect if the page is unavailable, making it slightly incomplete for robust agent decision-making.
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%, so the baseline is 3. The description adds no new meaning beyond the schema's clear definitions of 'realm' and 'character_name'. It correctly names 'character' but does not elaborate on parameter syntax or edge cases beyond what the schema already provides.
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 clearly states a specific verb ('Retrieves') and resource ('World of Warcraft character reputation page from Blizzard's Armory website'). It accurately differentiates the tool from the sibling get_character_info by limiting scope to reputation, so an agent can tell them apart without opening schemas.
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 description implies usage ('The LLM can then interpret this page to answer questions about the character'), giving context that this tool is for reputation-related questions. However, it does not explicitly mention when not to use it or compare it to the sibling get_character_info, leaving the selection logic partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clear, distinct purposes: one retrieves general character info and the other reputation. While both fetch pages from the Armory, their descriptions make the difference obvious, so an agent is unlikely to confuse them.
Both tool names follow an identical verb_noun pattern: get_character_info and get_character_reputation. The naming is perfectly consistent and predictable.
With only 2 tools, the server feels very thin for a World of Warcraft Armory domain, which typically offers character, guild, achievement, mount, and item data. The count is far below what would be expected for the apparent scope.
The server covers only basic character info and reputation, leaving major aspects like achievements, mounts, gear, and guilds unaddressed. Agents would face significant gaps when answering common WoW character questions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
Wynncraft MMO player + guild + leaderboard + item DB lookups.
Roblox public profile + friends + badges + games + groups lookups.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DouganRedhammer/WoWArmoryMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server