Skip to main content
Glama

Everloot: WoW Forever data

Achievement, reputation, title and quest progress

completion_progress
Read-onlyIdempotent

Shows what one install's characters have finished and what is closest to done: achievements with the largest share of criteria or progress met, reputations nearest the next standing, titles known, and quests finished in a chain. A list entry is public after 3 players (installs uploading from different addresses) report it identically. Progress shows only when that install uploaded it with the collection sharing choice and a verified grant; without it the answer says so. Not a Blizzard profile read and not a copied catalog. Use it for what a player is closest to finishing; use collection_gap for missing collection items, and guild_board for a guild's kills. Reads Everloot's public player data when connected. Missing or unavailable data is reported explicitly.

Input Schema

NameRequiredDescriptionDefault
characterKeyNoOne character's 8-digit key from the upload, when the install has several. Without it, every character.
ownerInstallIdYesThe player's own install id, whose completion upload to read.

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. Changed2 schema fields changed
    • changedInput schema / properties / characterKey / description
      Previous value: -"One character's 8-digit key from the upload, when the install has several."New value: +"One character's 8-digit key from the upload, when the install has several. Without it, every character."
    • changedInput schema / properties / ownerInstallId / description
      Previous value: -"Install id whose completion upload to read."New value: +"The player's own install id, whose completion upload to read."
  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

A4.6/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations by disclosing the trust model (an entry is public after 3 installs on different addresses report it identically), the privacy gate (requires the collection sharing choice plus a verified grant), and the degraded answer when that gate fails. It also names the upstream source (Everloot public player data) and states that missing data is reported explicitly rather than silently omitted.

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?

Front-loads the output content before the trust, privacy, and exclusion sentences, and each sentence carries distinct information. It is on the dense side with several long clauses, but little is genuinely redundant.

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?

With an output schema present, the description need not explain return shape, and it covers the remaining gaps an agent would need: privacy precondition, degraded-state behavior, data source availability, and error reporting. Nothing essential for a correct call is left implicit.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are documented there, so the schema carries the parameter burden. The description adds only an implied scoping statement ('one install's characters'); it never mentions ownerInstallId or the optional per-character key and its fallback behavior.

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 a concrete set of resources: achievements with the most criteria met, reputations nearest the next standing, titles known, and quests finished in a chain, all scoped to one install's characters. It explicitly negates two confusable readings ('Not a Blizzard profile read and not a copied catalog'), so an agent can place it without opening the 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?

Gives a positive routing rule ('Use it for what a player is closest to finishing') plus two named alternatives with their distinct conditions: collection_gap for missing collection items and guild_board for a guild's kills. Those are the two siblings an agent would most plausibly pick instead.

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.