This MCP server exposes the WoWAudit guild-management API as structured, read-only-by-default tools for MCP clients.
Team & roster: get team identity, current period/season, list tracked characters with class/role/rank.
Activity & attendance: list historical roster activity by period, get per-character history and gear, view weekly roster summary, and query attendance by instance/encounter/date.
Raids & signups: list upcoming/past raids, get detailed raid signups, schedules, comments, and encounter plans.
Wishlists & loot: list all character wishlists, fetch a single character's wishlist, view compact wishlist item tables, find demand for a specific item, and get loot history by season.
Applications (optional): when explicitly enabled, list and view player applications.
Writes (optional): with writes enabled and policy set, the server can add/update characters, create/update raids, and upload wishlists; destructive actions require confirmation.
Safety features: enforces read-only access by default, uses only documented API routes, never exposes the API key, and limits response sizes with caching.
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., "@wowaudit-mcp-server show me the guild roster"
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.
MCP server for the documented WoWAudit API. It exposes guild roster, raid planning, attendance, weekly activity, wishlists, loot history, and applications as structured tools for Raid Lens and other MCP clients.
The server uses stdio and @modelcontextprotocol/server 2.x. It serves the current MCP protocol and retains the SDK's legacy 2025-era initialize handshake for older clients. Every result includes native structuredContent plus the same JSON as a text block for clients that do not consume structured results.
Node.js 20 or newer.
A WoWAudit team API key. A team administrator can copy it from the team's Settings > Team > API key field, or open https://wowaudit.com/api and select the team. WoWAudit does not currently expose a scoped read-only Public API key; this server enforces read-only access locally by default.
Related MCP server: wow-mcp
npm installCreate .env from .env.example, then set:
WOWAUDIT_API_KEY=your-team-api-keyBuild the server:
npm run buildThe API key is loaded lazily, so the MCP process can start and list tools without a configured key. API calls return a structured configuration error until the key is available.
Use the compiled entry point from an MCP client:
{
"mcpServers": {
"wowaudit": {
"command": "node",
"args": [
"C:\\programming\\typescript\\wowaudit-mcp-server\\dist\\index.js"
]
}
}
}The server resolves .env relative to its installed location, not the MCP client's working directory. Credentials may instead be supplied through the client's env configuration.
Integrators that must preserve the API key's exact UTF-8 bytes can pass it through a dedicated inherited file descriptor instead of an environment variable. Inherit a readable descriptor as FD 3 and set only WOWAUDIT_API_KEY_FD=3. The descriptor contents must be non-empty valid UTF-8 and are read once, cached in memory for the MCP process lifetime, and reused without trimming or newline removal. Do not also set a non-empty WOWAUDIT_API_KEY.
A WoWAudit team API key can access the team's entire environment. The server applies these safeguards:
The key is sent only as an Authorization: Bearer header. It is never put in a URL, result, or error.
Only documented /v1/ routes are available. There is no arbitrary HTTP tool.
Write tools are not advertised or callable unless WOWAUDIT_ENABLE_WRITES=true. The HTTP client independently blocks mutation requests while disabled. Set WOWAUDIT_WRITE_POLICY=raidlens-create-update-v1 to limit enabled mutations to character tracking and updates, raid creation and updates, and wishlist uploads.
Destructive delete tools additionally require confirm: true on each call.
Application tools are disabled unless WOWAUDIT_ENABLE_APPLICATIONS=true because applications may contain identities, questionnaire answers, and uploaded-file URLs.
Tool annotations identify read-only, idempotent, and destructive operations to modern MCP clients.
Responses are limited to 2 MiB by default. Adjust WOWAUDIT_MAX_RESPONSE_BYTES only when necessary.
Successful GET responses use a child-local weighted LRU with 64 entries, 16 MiB total retained bytes, 4 MiB per entry, and at most 16 distinct upstream loads in flight. Values above the cache entry limit but within WOWAUDIT_MAX_RESPONSE_BYTES are returned uncached.
Cache keys contain only the HTTP method, API pathname, and sorted representation query. Credentials and the fixed base URL are excluded. Returned values are cloned, and failed or malformed responses are never retained.
Endpoint TTLs range from 15 seconds for raid detail to 10 minutes for team identity. Reads strictly refetch after expiry; stale data is not returned when revalidation fails.
Writes invalidate affected team, period, character, historical, attendance, wishlist, raid, and loot generations before HTTP dispatch. This also prevents a read started before a write from repopulating stale data after the write begins.
Enabling application tools does not provide channel authorization. A Discord integration must enforce officer-only access before exposing those tools. Similarly, a multi-guild bot must bind its trusted Discord guild ID to the correct WoWAudit credential outside model-controlled tool arguments.
Variable | Default | Purpose |
| required unless FD is used | Team API key, preserved without trimming |
| unset | Inherited API key descriptor, 1 to 1024 |
|
| API origin |
|
| Header and body timeout, 5,000 to 120,000 ms |
|
| Maximum JSON response, 64 KiB to 10 MiB |
|
| Completed response entry limit |
|
| Completed response retained-byte limit |
|
| Per-response retained-byte limit |
|
| Enable validated wishlist retention experiment |
|
| Permit POST, PUT, and DELETE tools |
| unset | Restrict writes to |
|
| Permit sensitive application tools |
Cache retained bytes include the UTF-8 cache key and serialized JSON value. Application reads use the unknown-GET 30-second TTL when enabled. Mutations, errors, credentials, authorization decisions, MCP results, and projected model output are not cached. refresh: true on RaidLens read tools removes a completed entry before lookup but joins an already active load for the same canonical resource; omitted refresh and refresh: false are equivalent.
WOWAUDIT_WISHLIST_MARKER_VALIDATION must remain false until an operator verifies wishlist_updated_at monotonicity across three authorized non-production wishlist edits. Disabled mode refetches the full wishlist after its normal five-minute TTL. Enabled mode retains a wishlist body for no more than 30 minutes and performs an uncached /v1/team marker probe every 60 seconds. Equal markers extend validation only, while larger, missing, malformed, or decreasing markers force a full refetch. Probe failures return the upstream error rather than stale wishlist data.
Successful protocol results include non-model-visible _meta["raidlens/cache"] telemetry with finite source/outcome labels and numeric duration and byte fields. The same data is not added to structuredContent or the text fallback.
The default configuration exposes 14 non-sensitive GET tools. Setting WOWAUDIT_ENABLE_APPLICATIONS=true adds the two read-only application tools. Setting WOWAUDIT_ENABLE_WRITES=true adds mutation tools; leave it unset for a strictly read-only MCP surface. For RaidLens, also set WOWAUDIT_WRITE_POLICY=raidlens-create-update-v1. This policy exposes the 14 non-sensitive GET tools plus only wowaudit_track_character, wowaudit_update_character, wowaudit_create_raid, wowaudit_update_raid, and wowaudit_upload_wishlist when writes are enabled. All application tools are suppressed regardless of WOWAUDIT_ENABLE_APPLICATIONS, and all other mutations remain absent and uncallable. Unknown non-empty policy values prevent startup. Omitting the policy preserves the existing general write surface for current consumers.
Mutation tools shown below are only registered when WOWAUDIT_ENABLE_WRITES=true and permitted by WOWAUDIT_WRITE_POLICY. Application tools are only registered when WOWAUDIT_ENABLE_APPLICATIONS=true and no policy suppresses them.
Tool | API operation |
|
|
|
|
|
|
|
|
|
|
|
|
Tool | API operation |
|
|
|
|
| compact current-period activity and vault rows |
|
|
Tool | API operation |
|
|
|
|
|
|
|
|
|
|
wowaudit_update_raid supports status and schedule changes, encounter enable/disable lists, signup statuses, comments, role/class overrides, selected status, and encounter-specific selections.
Tool | API operation |
|
|
|
|
| compact item rows from |
| character demand for one item from |
|
|
|
|
|
|
The all-character wishlist and loot endpoints can be large. Prefer character-specific calls for one player. Use wowaudit_list_wishlist_items for a compact paginated guild item table, optionally filtered by slot, and wowaudit_find_wishlisted_item to find demand for one item by item ID or name.
Tool | API operation |
|
|
|
|
|
|
|
|
Applications are separately gated by WOWAUDIT_ENABLE_APPLICATIONS=true. Mutating them also requires WOWAUDIT_ENABLE_WRITES=true. The raidlens-create-update-v1 policy suppresses every application tool regardless of these flags.
Successful tools, including wowaudit_get_team, return the canonical { data, meta } envelope consumed by RaidLens:
{
"data": {
"teamId": "42",
"teamDisplayName": "RaidLens Team"
},
"meta": {
"endpoint": "/v1/team",
"method": "GET"
}
}wowaudit_get_team validates the upstream numeric id and name, converts the ID to a string, and returns only teamId (1 to 128 characters) and teamDisplayName (1 to 200 characters). Other upstream team fields are not exposed.
Collection tools accepting limit additionally report totalItems, returnedItems, and truncated. The limit is applied after WoWAudit responds because the public API does not document server-side pagination.
Errors return isError: true, structured { "error": "..." }, and a text fallback. Upstream errors also include kind, HTTP status, and retryAfterSeconds when available.
The HTTP response limit is enforced while reading decoded body chunks under the same deadline used for response headers. Non-JSON error responses retain the HTTP status and only a bounded, credential-redacted plain-text detail. Retry-After delta seconds and future HTTP dates are exposed as a delay capped at one hour.
npm run dev
npm testTests compile the server, verify both modern and legacy protocol negotiation, inspect all tool schemas and annotations, exercise security gates, and test the HTTP client without using a real API key.
For a small live read-only check:
npm run test:liveThe live smoke test calls team, period, roster, and raid-list endpoints. It never invokes application or write tools.
The public documentation defines no pagination or rate-limit contract.
The documentation primarily supplies response examples rather than strict reusable schemas, so payload fields may evolve.
The embedded documentation contains a development-looking server URL. This project uses the confirmed production origin https://api.wowaudit.com by default.
WoWAudit accepts an API key in a query parameter, but this server deliberately uses only the authorization header to reduce credential leakage.
MIT, copyright WoWAudit MCP Server contributors.
Get attendance statistics, optionally scoped by instance, encounter, and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum top-level collection entries returned after WoWAudit responds. The upstream API does not document pagination. | |
| endDate | No | ||
| instance | No | ||
| encounter | No | Encounter name or ID. WoWAudit ignores it without instance. | |
| startDate | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations clearly declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the tool's safety profile is well-covered. The description adds useful context about optional scoping but does not explain what 'attendance statistics' entail (e.g., format, counts, per-character). Since annotations already communicate the most critical behavioral traits, the description's added value is moderate but nontrivial.
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 a single, front-loaded sentence that efficiently conveys the tool's purpose and optional filters. Every word adds value; there is no redundancy or filler. This is an excellent example of conciseness.
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?
Given the tool has 5 parameters (most optional), an output schema, and rich annotations, the description is somewhat minimal. It covers the core scoping options but does not explain what the attendance statistics contain or how to interpret the response. While the output schema may provide structure, the description could be more informative. This is adequate but not complete.
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 40%, meaning most parameters lack descriptions. The description mentions scoping by instance, encounter, and date range, which maps to the instance, encounter, startDate, and endDate parameters. However, the limit parameter's description is already in the schema (cadence 100%), so the description adds no further meaning. The encounter parameter's dependency on instance is covered in the schema description. Overall, the description only partially compensates for the low schema coverage.
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 that the tool retrieves attendance statistics, with optional scoping by instance, encounter, and date range. This makes the purpose clear and specific, distinguishing it from sibling tools that focus on teams, periods, characters, historical data, raids, wishlists, or loot history. A score of 5 is not given because the description does not explicitly contrast with siblings, though the domain is unique enough.
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 indicates when to use optional filters (instance, encounter, date range) but does not provide explicit guidance on when to use this tool versus alternatives, such as wowaudit_list_historical_data or wowaudit_get_character_history. No exclusions or prerequisites are mentioned. This is a minimal viable score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one character's activity history and best known gear by equipment slot.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | WoWAudit character ID. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the tool returns activity history and gear by equipment slot, which is useful output context but does not disclose additional behavioral traits like rate limits, authentication needs, or data retention. Neutral and non-contradictory.
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 a single, front-loaded sentence that packs essential information. Every word is necessary; no filler or redundancy. Ideal for quick agent scanning.
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?
Given the output schema exists (so return values are already documented), the annotations cover safety, and the tool has only one well-described parameter, the description is sufficiently complete. No major gaps are present for an agent to invoke it correctly.
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% (the 'id' parameter has a clear description). The description reinforces that the tool operates on a single character, but does not add new meaning beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 the action ('Get') and the resource ('one character's activity history and best known gear by equipment slot'). It is specific and distinguishes from sibling tools like wowaudit_get_loot_history or wowaudit_get_character_wishlist by focusing on overall history and gear per slot. No ambiguity.
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 provides no explicit guidance on when to use this tool versus alternatives (e.g., wowaudit_get_loot_history for loot, wowaudit_list_characters for a roster). It implies single-character scope but does not state exclusions or prerequisites. An agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed Droptimizer wishlist data for one character.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | WoWAudit character ID. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds that the data is 'detailed Droptimizer wishlist', but does not explain what 'detailed' means or note any specific behavioral traits (e.g., pagination, data freshness). No contradiction observed.
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?
Single sentence, front-loaded with verb and resource, zero wasted words. Ideal for quick parsing by an agent.
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 tool with one required parameter, full schema coverage, and an output schema defining return shape, the description is nearly complete. Missing a brief clarification of what 'Droptimizer' entails could improve completeness for agents unfamiliar with the domain, but not critical.
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?
Input schema has 100% coverage with a single parameter 'id' described as 'WoWAudit character ID.' The description does not add further meaning beyond this, meeting the baseline for high schema coverage.
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?
Clearly states verb 'Get' and resource 'detailed Droptimizer wishlist data for one character', making the action specific. However, it does not explicitly differentiate from sibling tool wowaudit_list_wishlists, which could also involve wishlist data, missing a nuance that this is per-character.
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 like wowaudit_list_wishlists or wowaudit_get_character_history. With ten sibling tools, the absence of contextual usage instructions leaves the agent to infer the appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get loot awarded during a keystone season, including recipients, award responses, old items, notes, and wishlist values.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum top-level collection entries returned after WoWAudit responds. The upstream API does not document pagination. | |
| seasonId | Yes | Keystone season ID from wowaudit_get_period. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds value by listing the types of data included (recipients, awards, etc.), which is beyond the annotations. However, it does not mention pagination behavior or limits, which are partially covered in the schema description for the limit 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?
The description is a single, clear sentence that efficiently conveys the tool's purpose and key output details. No unnecessary words or repetition. Slightly more detail could be added without harming conciseness, but it's well-structured.
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?
Given the simple nature of the tool (2 params, read-only, output schema exists), the description adequately covers what the tool does and what it returns. The schema and annotations fill in the remaining details. Could mention that seasonId is required, but that is already in the schema.
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?
Both parameters have detailed descriptions in the schema (100% coverage), including the seasonId reference to another tool and the limit behavior with pagination note. The tool description does not add any additional parameter-level information, so baseline 3 is appropriate.
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 the tool retrieves loot awarded during a keystone season, listing specific included fields (recipients, award responses, old items, notes, wishlist values). This distinguishes it from sibling tools like wowaudit_get_character_history (individual character) and wowaudit_list_historical_data (broader history).
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 use when needing loot history for a season, but does not explicitly differentiate from alternatives like wowaudit_get_character_history or wowaudit_list_historical_data. No direct guidance on when to prefer this tool over others.
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 keystone period and WoWAudit season identifiers used by historical and loot tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, providing a strong behavioral baseline. The description adds context by revealing the tool returns identifiers discovered and used by other tools, which justifies the non-destructive, idempotent nature. However, it doesn't describe any additional behavioral traits like whether the season identifiers are stable within a season or change on reset, so the description adds limited value beyond 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?
The description is a single sentence of 16 words that front-loads the action and resource. Every part of the sentence earns its place: it specifies what is retrieved (period and season identifiers) and why ('used by historical and loot tools'). There is no wasted verbiage.
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?
Given that the tool has no parameters, has annotations covering its safety profile, and has an output schema (which is not null), the description need not explain return values. The single sentence adequately addresses the tool's purpose and context. The score would be 5 if it briefly noted that this is a static, reference-data endpoint (e.g., 'returns identifiers that change infrequently').
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 has 0 parameters and the schema description coverage is 100%, so there are no parameters to document. The description adds no parameter information but none is needed. The score reflects that the description provides no misleading or missing parameter details, and the baseline for a zero-parameter tool is high.
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 uses a specific verb ('Get') and clearly identifies the resources ('current Blizzard keystone period and WoWAudit season identifiers'). It also distinguishes its purpose from sibling tools by explicitly stating the returned identifiers are 'used by historical and loot tools', which helps differentiate it from tools like wowaudit_get_team or wowaudit_get_character_history.
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 explicitly states the context of use: these identifiers are consumed by other tools (historical and loot tools). While it doesn't explicitly say when not to use this tool or name alternative tools, the mention of downstream consumers provides clear guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a raid's detailed signups, comments, selections, and enabled encounter plan.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | WoWAudit raid ID. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value by listing the specific data fields returned (signups, comments, selections, enabled encounter plan), which is behavioral context beyond the 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?
The description is a single sentence of 12 words, front-loaded with the verb and resource, and contains no extraneous information. Every word 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?
Given the single parameter, rich annotations, and existence of an output schema, the description sufficiently explains what the tool returns. No additional context (e.g., pagination, limits) seems necessary for this simple read operation.
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% (the single parameter 'id' has a description: 'WoWAudit raid ID.'). The description adds no new meaning beyond the schema; it merely implies the parameter is the raid ID. Baseline 3 is appropriate.
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 the verb 'Get' and the resource 'raid', and specifies the details included: signups, comments, selections, and enabled encounter plan. This distinguishes it from sibling tools like wowaudit_get_team or wowaudit_list_raids.
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 for fetching detailed raid information, but does not explicitly contrast with alternative tools or provide when-not-to-use guidance. The agent can infer from resource name and sibling list, but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated WoWAudit team, guild identity, refresh timestamps, raid-day schedule, and wishlist freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows this is a safe read operation. The description adds value by specifying the exact data returned (team, guild identity, refresh timestamps, raid-day schedule, wishlist freshness), which is beyond the annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the key components returned. Every phrase earns its place; there is no wasted text. It is front-loaded with the primary action and resource.
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?
Given the tool's simplicity (no parameters, has an output schema), the description is complete. It covers the main output categories, and since the output schema exists, the agent can infer the exact structure. No additional context 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?
There are no parameters (0), so the input schema is trivially covered at 100%. The description does not need to explain parameters, and the baseline for 0-parameter tools is 4. The description does not add parameter semantics, but that is acceptable since none exist.
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 states the verb 'Get' and the resource 'authenticated WoWAudit team' and lists specific sub-components (guild identity, refresh timestamps, raid-day schedule, wishlist freshness). This clearly distinguishes it from siblings like get_character_history or get_raid, which operate on different entities.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention that this is for team-level configuration versus character or raid data, nor does it specify when not to use it. Given the sibling list, explicit usage context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tracked roster characters with realm, class, role, rank, tracking status, note, and WoWAudit identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum top-level collection entries returned after WoWAudit responds. The upstream API does not document pagination. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds behavioral context by mentioning the data fields and that the upstream API does not document pagination, which is useful for understanding behavior beyond the 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?
Single sentence, no wasted words. Every element (verb, resource, fields) earns its place. Front-loaded with 'List tracked roster characters'.
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?
Given the parameter count is 1, all schema parameters are described, annotations cover safety, and an output schema exists, the description is complete enough. The pagination caveat adds useful context.
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 100% (the single parameter 'limit' is fully described in the schema), so baseline is 3. The description does not add any additional semantics beyond the schema's parameter documentation.
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 uses a specific verb ('List'), identifies the resource ('tracked roster characters'), and enumerates the fields returned (realm, class, role, etc.). This clearly differentiates it from sibling tools like wowaudit_list_raids or wowaudit_get_character_history, which operate on different resources.
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 this is for getting a roster overview, but it does not explicitly state when to use this vs. alternatives like wowaudit_get_team or wowaudit_list_historical_data. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List roster activity for a Blizzard period, including completed dungeons, world quests, and Great Vault options.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum top-level collection entries returned after WoWAudit responds. The upstream API does not document pagination. | |
| period | No | Blizzard period from wowaudit_get_period. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide strong behavioral cues: readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds further value by noting the items listed (dungeons, world quests, Vault), which goes beyond annotations. However, it doesn't mention the lack of pagination or potential response size limits, which would be useful but not required given the annotations already assure safety and idempotence.
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 a single sentence that is clear and to the point. It conveys the key purpose and content without any extraneous words. It 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?
Given the tool has an output schema, the description need not explain return values. With 2 parameters (0 required), strong annotations, and clear purpose, the description is nearly complete. The only minor gap is the lack of mention about pagination or the fact that upstream API does not support it, but the input schema already notes that in the 'limit' description. Overall very sufficient.
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 100%, so the baseline is 3. The description does not add any parameter semantics beyond the schema—it doesn't explain how 'limit' affects the output or how 'period' relates to the Blizzard context. Both parameters are well-documented in the schema already, so no deduction, but no added value either.
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 'List roster activity for a Blizzard period' and lists specific content types (completed dungeons, world quests, Great Vault options), which is specific and actionable. However, it does not distinguish this tool from sibling tools like wowaudit_get_character_history or wowaudit_get_loot_history, which might also list similar data, so it's not 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?
The description implies usage when needing roster activity for a period, but provides no guidance on when not to use it or how it compares to alternatives like wowaudit_get_character_history. There's no explicit context about prerequisites (e.g., needing a valid period from wowaudit_get_period) or limitations (e.g., no pagination support). The annotation 'idempotentHint' suggests safe repeated calls, but this is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming raids, optionally including past raids, with schedule, instance, difficulty, status, and signup counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum top-level collection entries returned after WoWAudit responds. The upstream API does not document pagination. | |
| includePast | No | Include past raids in addition to upcoming raids. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description bears less burden. The description adds context that the output includes schedule, instance, difficulty, status, and signup counts, which is helpful but does not disclose other behavioral traits (e.g., pagination limits, authentication needs, or performance characteristics). No contradiction with 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?
The description is a single sentence of 15 words, front-loaded with the verb 'List', and efficiently conveys the main purpose and key output fields without any filler or repetition.
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?
Given the low complexity (2 optional parameters, output schema exists, annotations comprehensive) the description covers the essential scope (upcoming/past raids, key fields). Some minor gaps exist (default limit, time horizon for 'upcoming'), but overall it is sufficiently complete for a read-only list tool with good schema coverage.
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% (both limit and includePast have descriptions). The tool description adds minimal extra meaning: 'optionally including past raids' maps to includePast, but the schema already covers defaults and constraints. The limit parameter's note about undocumented pagination is in the schema, not the description, so the description does not add value beyond the schema.
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 the tool lists raids with a specific verb ('list') and resource ('raids'), and includes optional past raids and key data fields (schedule, instance, difficulty, status, signup counts). This distinguishes it from siblings like wowaudit_get_raid (single raid) and wowaudit_list_historical_data (historical 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?
The description does not provide any guidance on when to use this tool versus alternatives like wowaudit_get_raid or wowaudit_list_characters. There is no explicit when/when-not context or mention of sibling tools, leaving the agent to infer usage solely from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List character Droptimizer wishlists and item upgrades. Prefer wowaudit_get_character_wishlist when one character is known because this response can be large.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum top-level collection entries returned after WoWAudit responds. The upstream API does not document pagination. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: the response can be large and the limit parameter's pagination caveat. This exceeds what annotations provide.
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: first states the tool's purpose, second provides usage guidance. No wasted words, front-loaded with essential 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 an output schema present, the description need not detail return values. It covers purpose, usage preference, and response size. Could mention that without a limit all wishlists are returned, but this is minor. Overall complete for the tool's complexity.
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 100%, so the input schema fully documents the optional limit parameter (integer, min/max, description about pagination). The description does not add new semantics beyond the schema, warranting the baseline score of 3.
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 lists character Droptimizer wishlists and item upgrades. It also distinguishes from the sibling tool wowaudit_get_character_wishlist by noting that this tool is for broader lists and can produce large responses.
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 explicitly recommends preferring wowaudit_get_character_wishlist when a single character is known because this response can be large. This provides clear guidance on when to use each tool.
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. Dates show when Glama detected each change.
v0.1.0wowaudit_get_attendancewowaudit_get_character_historywowaudit_get_character_wishlistwowaudit_get_loot_historywowaudit_get_periodwowaudit_get_raidwowaudit_get_teamwowaudit_list_characterswowaudit_list_historical_datawowaudit_list_raidswowaudit_list_wishlistsMost tools target distinct resources: team/period/characters/raids/attendance/wishlists/loot. However, wowaudit_list_historical_data and wowaudit_get_loot_history both involve historical activity and loot, which could cause some confusion despite different scopes.
All tools follow a consistent wowaudit_verb_noun pattern (e.g., list_raids, get_raid, get_attendance). The naming is predictable and easy to understand.
With 11 tools, the server covers a focused domain (WoWAudit team management) without unnecessary clutter. Each tool serves a clear purpose and the count feels well-scoped.
The tool set covers team info, roster characters, raids, attendance, wishlists, and loot history. Missing are write operations (e.g., add character, update wishlist) but for a read-only audit tool, the coverage is solid. Minor gap: no direct tool for managing raid signups.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Wynncraft MMO player + guild + leaderboard + item DB lookups.
Manage your RoyalTea game studio: tasks, milestones, team, and royalty data. 77 tools, OAuth 2.1.
Public tools to understand Dynamik, discover datasets, and connect account-scoped capabilities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MangelSpec/wowaudit-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
