poe2-build-planner

Overview Schema Source Related Servers Discussions Admin

Export to the in-game Build Planner

export_build

Write a finished Path of Exile 2 build plan as a .build file into the game's BuildPlanner folder, including passives, skills, supports, and gear priorities; return it for manual saving if missing.

Instructions

Write the finished build as a .build file into Path of Exile 2's BuildPlanner folder, where the game picks it up (passives with the level to take them, skills and supports with level ranges, and gear stat priorities per slot). Ask the player before writing. If the game folder isn't found, the file contents are returned to save manually. Gear slots: Main Hand, Off Hand, Weapon Swap Main Hand, Weapon Swap Off Hand, Helmet, Body Armour, Gloves, Boots, Amulet, Left Ring, Right Ring, Belt.

Input Schema

TableJSON Schema

Name	Required	Description
`gear`	No
`name`	Yes
`class`	Yes	Class or ascendancy name
`write`	No	Write the file (default true). false = just return it
`skills`	Yes
`passives`	Yes
`overwrite`	No	Replace an existing file with the same name that this tool didn't write
`ascendancy`	No
`description`	No
`levelRanges`	No	leveling (default): each passive shows from the level you take it. none: the whole tree at once — use for an end-game file (e.g. "Name - Endgame")
`ascendancyPassives`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.0-betaOct 1, 2026

addedInput schema / properties / levelRanges

Added value: +{
+  "description": "leveling (default): each passive shows from the level you take it. none: the whole tree at once — use for an end-game file (e.g. \"Name - Endgame\")",
+  "enum": [
+    "leveling",
+    "none"
+  ],
+  "type": "string"
+}

First observedv0.5.0Sep 27, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the write target, the required user confirmation, and the fallback behavior when the folder is missing (contents returned to save manually). It omits any note on the write/overwrite distinction or success response shape, keeping it short of a 5.

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 core action before the caveats, and the confirmation rule is stated plainly. The trailing gear-slot enumeration is long but earns its place by defining valid slot values; overall well structured with minor trailing bulk.

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?

For an 11-param, no-annotation, no-output-schema mutation tool, the description covers the essential operational context: what gets written, the confirmation gate, and the folder-missing fallback. It is complete enough to invoke correctly, though return-value and overwrite semantics remain thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 36%, so the description must compensate, and it does: it enumerates valid gear slot strings (constraining an otherwise free-text slot param) and explains that passives/supports carry level ranges and gear carries stat priorities per slot. It leaves write, overwrite, name, class, and ascendancy meaning to 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?

States a specific verb and resource: writes a finished build as a .build file into the game's BuildPlanner folder. Clearly distinguishable from siblings like list_builds, evaluate_build, or create_build_guide, which don't write in-game files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Implies usage via 'finished build' and the confirmation step ('Ask the player before writing'), which tells the agent this is a terminal export action. However, it names no alternative sibling or a when-not-to-use condition, so routing relies on inference.

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

Export to the in-game Build Planner

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools