Everloot: WoW Forever data

Owned versus missing in a collection

collection_gap

Read-onlyIdempotent

Returns what one install still misses in one collection, against what that install uploaded as owned, grouped by source. A list row is public after 3 installs agree on the collection, the source and the item; owned is what that install uploaded. Not a Blizzard profile read and not a copied catalog. Use it for which items of a collection a player is missing; use completion_progress for achievements, reputations and titles. When that install never uploaded the collection, the answer says owned is unknown, not empty. Reads Everloot's public player data when connected. Missing or unavailable data is reported explicitly.

Input Schema

Name	Required	Description	Default
`collection`	Yes	Collection name, any case, such as Mounts.
`ownerInstallId`	Yes	The player's own install id, whose owned upload to compare.

Output Schema

Name	Required	Description
`url`	No	The everloot.app page that shows this answer, absolute. Absent when there is no such page or it would be empty.
`page`	No
`reason`	No	Why nothing was read, when connected is false.
`dataAsOf`	Yes	The corpus snapshot time, or null when unrecorded.
`connected`	Yes	False when no corpus was read; the page is then absent, which is not a measured zero.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

changedInput schema / properties / collection / description

Previous value: -"Collection name, such as Mounts."New value: +"Collection name, any case, such as Mounts."

changedInput schema / properties / ownerInstallId / description

Previous value: -"Install id whose owned upload to compare."New value: +"The player's own install id, whose owned upload to compare."

Changed1 schema field changedOct 20, 2026

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"
+}

First observedOct 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, closed-world safety. The description adds valuable provenance behavior: data becomes public after 3 installs agree, 'owned is unknown, not empty' when no upload exists, and missing data is reported explicitly. These are behavioral traits beyond what annotations capture.

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?

The description is front-loaded and each sentence earns its place: purpose, data provenance, disambiguation from other tools, usage guidance, edge case, data source, and error handling. There is no redundant wording or filler.

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 values. It covers the tool's behavior, data-source caveats, and edge-case failure modes, which is complete for a two-parameter collection comparison.

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%, so the schema already documents both parameters with clear descriptions. The description reinforces that 'owned' refers to what the ownerInstallId uploaded, but adds no new syntax, format, or constraint beyond what the schema provides. Baseline 3 is appropriate.

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?

The description opens with a precise verb and resource: 'Returns what one install still misses in one collection, against what that install uploaded as owned, grouped by source.' It explicitly distinguishes itself from sibling completion_progress and disclaims being a Blizzard profile or copied catalog, so an agent can identify its purpose 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?

It explicitly says 'Use it for which items of a collection a player is missing; use completion_progress for achievements, reputations and titles,' giving both a positive use case and a named alternative. No inference is left to the agent.

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

All Everloot: WoW Forever data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.