Skip to main content
Glama

Everloot: WoW Forever data

Game object page

object_page
Read-onlyIdempotent

Returns one game object's page (a chest, herb, ore vein or fishing pool) by its entry id: the items players looted from it, each with observed loot windows, windows with the item and distinct install reports, and where players saw it on the minimap. A frequency is public after 3 install reports; a public object with nothing in its windows reads as a measured zero. The name shows once 3 installs agree on it. Use it for gathering nodes and containers; use npc_page for creatures, and item_page for every source of one item. Reads Everloot's public player data when connected. Missing or unavailable data is reported explicitly.

Input Schema

NameRequiredDescriptionDefault
objectIdYesThe object's entry id, from a world_map_near treasure, as in /database/objects/1731.

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. Changed1 schema field changed
    • changedInput schema / properties / objectId / description
      Previous value: -"The object's entry id, as in /database/objects/1731."New value: +"The object's entry id, from a world_map_near treasure, as in /database/objects/1731."
  2. Changed2 schema fields changed
    • addedOutput schema / properties / page / properties / pendingLoot
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Loot windows reported but not yet in the rates. Absent when there are none.",
      +  "properties": {
      +    "reporters": {
      +      "description": "Distinct reporters behind those windows.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "windows": {
      +      "description": "Reported loot windows not yet in the rates.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "windows",
      +    "reporters"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / page / properties / pins
      Added value: +{
      +  "description": "Where players saw the object on the minimap, at its own position; a pin needs 3 installs at one spot. Absent when there is none.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "mapId": {
      +        "maximum": 9007199254740991,
      +        "minimum": -9007199254740991,
      +        "type": "integer"
      +      },
      +      "reporters": {
      +        "maximum": 9007199254740991,
      +        "minimum": -9007199254740991,
      +        "type": "integer"
      +      },
      +      "x": {
      +        "type": "number"
      +      },
      +      "y": {
      +        "type": "number"
      +      }
      +    },
      +    "required": [
      +      "mapId",
      +      "x",
      +      "y",
      +      "reporters"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  3. Changed2 schema fields changed
    • addedOutput schema / properties / page / properties / name
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / page / required
      Previous value: -[
      -  "objectId",
      -  "drops",
      -  "zero",
      -  "queued"
      -]New value: +[
      +  "objectId",
      +  "name",
      +  "drops",
      +  "zero",
      +  "queued"
      +]
  4. 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"
      +}
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, closed-world safety, but the description adds substantive behavior the annotations cannot convey: the 3-install-report publication threshold, that an empty public object reads as a measured zero, that names appear only after 3 agreeing installs, the data source (Everloot public player data), and explicit reporting of missing/unavailable data.

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-loaded with the return contract, then thresholds, then routing — a sensible order with no filler. The opening sentence is dense and carries several clauses, which slightly reduces scannability but nothing is wasted.

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?

The tool returns a rich composite payload, and an output schema exists so return shape needn't be restated. The description still supplies the interpretive rules (thresholds, measured-zero semantics, name agreement) plus data provenance and missing-data behavior, leaving no material gap for correct invocation.

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 the single parameter is fully documented in the schema, including a concrete path example (/database/objects/1731). The description only echoes 'entry id', adding no format or sourcing detail beyond the schema, so the baseline 3 applies.

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 resource — 'Returns one game object's page ... by its entry id' — and enumerates the concrete object types (chest, herb, ore vein, fishing pool) so an agent knows the domain without opening the schema. It also names the two siblings it is not (npc_page, item_page).

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?

Explicit routing: 'Use it for gathering nodes and containers; use npc_page for creatures, and item_page for every source of one item.' That covers both when-to-use and when-to-use-a-different-tool, which is rare and valuable.

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.