Skip to main content
Glama

Everloot: WoW Forever data

Fetch one document (ChatGPT connector contract)

fetch
Read-onlyIdempotent

Returns one knowledge record in full, by the string id a search result gave: title, the full text in the source's words, the URL to cite, and metadata with the source, licence and date. It is the ChatGPT connector counterpart of get_entity, which gives only an excerpt. Use it after search, or with a search_knowledge id as a string. Give field, a JSON pointer such as /questIds, to read one value of the record's data: text then holds that value as JSON, and an array comes in pages of up to 48 rows with nextOffset for the next page. A long array in a whole record is cut at 48 rows. The text block is the same JSON as a string.

Input Schema

NameRequiredDescriptionDefault
idYesAn id from a search result.
fieldNoA JSON pointer into the record's data, such as /criteria or /reagents/0. Without it, the whole record.
limitNoRows per answer, default and at most 48.
offsetNoRow to start at when the field is an array; default 0. Use nextOffset from the last answer.

Output Schema

NameRequiredDescriptionDefault
idYesThe record id as a string.
urlYesWhere the record is read, as in search.
keysNoPresent when field was given and not found: the keys of the deepest object the pointer reached. Empty when the record has no structured data.
textYesThe whole record, in the source's words.
fieldNoPresent when field was given and found.
titleYesThe record's name.
metadataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / field
      Added value: +{
      +  "description": "A JSON pointer into the record's data, such as /criteria or /reagents/0. Without it, the whole record.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Rows per answer, default and at most 48.",
      +  "maximum": 48,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Row to start at when the field is an array; default 0. Use nextOffset from the last answer.",
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedOutput schema / properties / field
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Present when field was given and found.",
      +  "properties": {
      +    "nextOffset": {
      +      "description": "Present when more rows remain: pass it as offset.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "pointer": {
      +      "type": "string"
      +    },
      +    "value": {
      +      "description": "The value at the pointer. An array is one page of up to 48 rows."
      +    }
      +  },
      +  "required": [
      +    "pointer",
      +    "value"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / keys
      Added value: +{
      +  "description": "Present when field was given and not found: the keys of the deepest object the pointer reached. Empty when the record has no structured data.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / metadata / properties / confirmed
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Present when player uploads confirm this game-file entry (3 or more installs agree). asOf is the date the rollup was current.",
      +  "properties": {
      +    "asOf": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "asOf"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / properties / metadata / properties / kind / enum
      Previous value: -[
      -  "item",
      -  "npc",
      -  "object",
      -  "quest",
      -  "zone",
      -  "spell",
      -  "lore_page",
      -  "creator",
      -  "realm"
      -]New value: +[
      +  "item",
      +  "npc",
      +  "object",
      +  "quest",
      +  "zone",
      +  "spell",
      +  "lore_page",
      +  "creator",
      +  "realm",
      +  "achievement",
      +  "faction",
      +  "title",
      +  "quest_chain",
      +  "mount",
      +  "legacy_perk",
      +  "race",
      +  "instance",
      +  "build"
      +]
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description productively adds behavior beyond them: long arrays are truncated at 48 rows, arrays are returned in pages with a nextOffset cursor, and the field pointer changes the shape of the returned text. The remaining gap is error/not-found behavior and what happens when the id is malformed or exceeds maxLength.

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?

It is a single dense paragraph with the core purpose front-loaded and no filler sentences. However, the pagination rule is stated twice ("pages of up to 48 rows with nextOffset" and "A long array in a whole record is cut at 48 rows"), and the final sentence "The text block is the same JSON as a string" is terse enough to be ambiguous on first read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With rich annotations and an output schema, the description need not explain return structure, and it correctly focuses on the id-source contract, field projection, and pagination. Minor gaps remain around failure modes and how the field projection interacts with limit/offset for non-array values, but nothing essential for a correct call is missing.

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 description coverage is 100%, so the schema already documents all four parameters, which sets the baseline at 3. The description adds some meaning beyond it, notably that a field pointer returns the value as JSON in text and that arrays paginate via nextOffset, but it does not clarify limit/offset interaction in more depth than the schema's own descriptions.

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 specific verb plus resource and scope: "Returns one knowledge record in full, by the string id a search result gave," then enumerates the returned parts (title, full text, URL, metadata). It explicitly distinguishes itself from get_entity ("which gives only an excerpt") and ties its input to search results, so an agent can tell it apart from siblings 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 Guidelines4/5

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

It gives concrete invocation guidance: "Use it after search, or with a search_knowledge id as a string," naming the two upstream tools that produce valid ids. It also names the excerpt-only alternative get_entity. It stops short of stating when not to use it (e.g. versus the page-specific siblings like quest_page or npc_page), so it is clear but not fully exclusionary.

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.