Skip to main content
Glama

Everloot: WoW Forever data

Who plays what: population by race, class, faction and level

population
Read-onlyIdempotent

Counts how many characters play each race, class, race and class, faction and level band on WoW: Forever, from the census players turned on in the Everloot addon. Each character counts once. A count shows only when it covers at least 10 characters reported by at least 3 installs from at least 3 addresses, rounded to the nearest 5; a count that could be worked out from the others is hidden too. When census data is available, every answer states its window: active in the last 7 days (default) or since launch; when it is not, the answer says so instead of giving a zero. With no arguments, the overview, most played class first. Use it for how many play a race or class; use class_races for which races can be a class. No names, ever. Missing or unavailable data is reported explicitly.

Input Schema

NameRequiredDescriptionDefault
raceNoA race, such as Gnome, Night Elf or Undead. Without it, every race.
classNoA class, such as Priest. Without it, every class.
windowNoweek (default): active in the last 7 days. launch: seen since launch.week
factionNoAlliance or Horde. Without it, both.

Output Schema

NameRequiredDescriptionDefault
urlNoThe everloot.app page that shows this answer, absolute. Absent when there is no such page or it would be empty.
pageNo
reasonNoWhy nothing was read, when connected is false.
dataAsOfYesThe corpus snapshot time, or null when unrecorded.
connectedYesFalse when no corpus was read; the page is then absent, which is not a measured zero.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / class / description
      Previous value: -"A class, such as Priest."New value: +"A class, such as Priest. Without it, every class."
    • changedInput schema / properties / faction / description
      Previous value: -"Alliance or Horde."New value: +"Alliance or Horde. Without it, both."
    • changedInput schema / properties / race / description
      Previous value: -"A race, such as Gnome, Night Elf or Undead."New value: +"A race, such as Gnome, Night Elf or Undead. Without it, every race."
    • changedInput schema / properties / window / description
      Previous value: -"week: active in the last 7 days. launch: seen since launch."New value: +"week (default): active in the last 7 days. launch: seen since launch."
  2. Changed1 schema field changed
    • addedOutput schema / properties / url
      Added value: +{
      +  "description": "The everloot.app page that shows this answer, absolute. Absent when there is no such page or it would be empty.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses suppression thresholds (10 characters, 3 installs, 3 addresses), rounding to the nearest 5, complementary suppression, and that no character names are ever returned. It also states that when census data is unavailable the answer says so rather than returning zero, which is exactly the kind of quirk an agent must know to interpret results.

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

Conciseness5/5

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

Front-loaded with the counting verb, then disclosure rules, then window semantics, then the sibling routing. Dense but no sentence is filler; even the privacy clauses carry decision-relevant information for interpreting suppressed counts.

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?

An output schema exists, so return-value structure need not be explained. With suppression, rounding, window labelling, missing-data behavior, the no-argument default, and the sibling split all covered, an agent has everything needed to call this correctly and to read its output honestly.

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

Parameters5/5

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

Schema coverage is 100%, so the schema already documents race, class, window, and faction. The description adds meaning on top: it frames the parameters as grouping/scope selectors (each character counts once), clarifies the default overview behaviour with no arguments, and states that every answer reports its window (last 7 days vs. since launch).

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?

"Counts how many characters play each race, class, race and class, faction and level band" states a specific verb plus the exact grouping dimensions, and narrows the domain (WoW: Forever, Everloot addon census). The final line routes the agent to the sibling tool class_races, 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.

Usage Guidelines5/5

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

"Use it for how many play a race or class; use class_races for which races can be a class" gives an explicit when-to-use and a named alternative with the condition that selects it. "With no arguments, the overview, most played class first" further tells the agent the zero-arg case is valid and what it returns.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.