Everloot: WoW Forever data

Gold ledger for one character

gold_ledger

Read-onlyIdempotent

Returns the peak and current gold of one character and the money events its own upload recorded: income (loot, quests, vendor and auction sales) and spending (flight paths, postage, barber, respecs, auction purchases), each install's ledger kept apart. A category with nothing recorded reads as unrecorded, not zero, and gold from other gameplay is unrecorded. The gap between recorded income and peak gold is shown as unrecorded, never called bought gold or a ban. Use it for one uploaded character's own gold history; it cannot look up a character that never uploaded. Use guild_board for a guild's loot, and market_value for prices. Reads Everloot's public player data when connected. Missing or unavailable data is reported explicitly.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "character": "<character>",
      "realm": "<realm>"
    },
    "name": "gold_ledger"
  }
}

Input Schema

Name	Required	Description	Default
`realm`	Yes	The character's realm, as the game shows it.
`character`	Yes	The character's in-game name.

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 / character / description

Previous value: -"Character name."New value: +"The character's in-game name."

changedInput schema / properties / realm / description

Previous value: -"Realm name."New value: +"The character's realm, as the game shows it."

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?

Beyond the read-only and idempotent annotations, it explains important behavioral constraints: each install's ledger is kept apart, missing categories read as unrecorded rather than zero, other gameplay gold is unrecorded, and the income-to-peak gap is never characterized as bought gold or a ban. It also discloses the Everloot public-data dependency and explicit missing-data reporting.

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 dense but front-loaded with the return value, then proceeds through data caveats, usage boundaries, alternatives, and source limitations. Every sentence carries useful information for interpreting or invoking the tool.

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?

For a read-only lookup with two fully described parameters, rich annotations, and an output schema, the description supplies the remaining semantic context an agent needs. Its account of unrecorded data, per-install separation, and unavailable characters is complete for this tool's complexity.

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?

The schema has 100% description coverage for both required parameters, so character and realm are already documented. The description reinforces that only one character is queried and that ledger data is kept per install, but it adds no syntax or formatting detail beyond the schema.

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 states a specific return: peak and current gold plus recorded income and spending events for one character. It clearly distinguishes the tool from guild_board and market_value, 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 to use this for one uploaded character's own gold history, states that it cannot look up a character that never uploaded, and names the sibling alternatives for guild loot and prices. This covers both when to use it and when to use something else.

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.