Everloot: WoW Forever data

Profession leveling path

profession_path

Read-onlyIdempotent

Returns a leveling path for one Forever profession between two skill levels, built from Everloot uploads: the steps, the reagents summed and their cost. A step exists only after 3 installs agree: on a reported recipe, or on the recipe colours that make it orange (a guaranteed skill-up), starting at the trainer's required rank when 3 installs agree on one, else at the lowest rank seen orange. A price exists only after 3 price uploads agree. A skill range no agreed recipe covers is left as a gap, never invented. Use it for how to level a profession from one skill to another; use recipe_thresholds for where single recipes change colour, and market_value for what a reagent costs today. Reads Everloot's public player data when connected. Missing or unavailable data is reported explicitly.

Input Schema

Name	Required	Description
`toSkill`	Yes	Skill to stop at, 1 to 500, above fromSkill.
`fromSkill`	No	Skill the character has now, 1 to 500, default 1.
`profession`	Yes	Profession name, such as Alchemy.

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

Previous value: -"Skill the character has now."New value: +"Skill the character has now, 1 to 500, default 1."

changedInput schema / properties / toSkill / description

Previous value: -"Skill to stop at. Must be above fromSkill."New value: +"Skill to stop at, 1 to 500, above fromSkill."

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.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, but the description adds real behavioral context the annotations cannot: the 3-install/3-price agreement threshold, the fallback rule for starting rank, that uncovered ranges are left as gaps rather than invented, and that Everloot public player data is read when connected. This is well beyond structured fields, though it does not mention pagination or result size.

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?

Purpose is front-loaded and every sentence carries information, but the middle section is a dense run-on chain of agreement rules that takes effort to parse. Slightly tighter phrasing of the consensus rules would improve scannability without losing content.

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?

An output schema exists, so return shape need not be explained, yet the description still summarizes the three outputs and explains the provenance and gap behavior. For a read-only analytical tool with three simple parameters, nothing an agent needs to call it correctly 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% and each parameter already carries range and default documentation, so the schema does the heavy lifting. The description only restates the two-skill-level framing and adds no format or edge-case detail (e.g. what happens when fromSkill equals toSkill).

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?

Names a specific verb and resource ('Returns a leveling path for one Forever profession between two skill levels') and states the payload: steps, summed reagents, and cost. It also explicitly distinguishes itself from recipe_thresholds and market_value, so an agent can route without opening any 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 direct when-to-use ('how to level a profession from one skill to another') plus two named alternatives with the exact condition that selects each. Nothing about tool selection is left to inference.

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.