Skip to main content
Glama
cornndawwg

poe2-build-planner

by cornndawwg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Plan passive tree

plan_passive_tree
Read-only

Connects a class start to chosen passives, calculates the level each point can be taken, and paths ascendancy nodes for a Path of Exile 2 build plan.

Instructions

Connect the class start to the chosen passives and say the character level each point can be taken at. By default targets are reached in the order given (priority order); order: "cheapest" takes the nearest first instead. Among equally short routes it prefers small passives matching terms and avoids avoid (e.g. terms ["spell", "fire"] picks Spell Damage smalls over Life Regeneration ones); to force a route, list small passives as targets too (find_passives with kinds ["small"] and near gives their keys). Notables passed on the way to another target are flagged (onTheWay). Passives gated behind an ascendancy node (e.g. Oracle-only passives need The Unseen Path) are only used when that node is in ascendancyPassives, and are flagged with the trial that unlocks them. Also paths the ascendancy nodes (8 points, 2 per trial). Pass passives by key, id or exact name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
avoidNoAvoid small passives matching these on equally short routes
classYesClass or ascendancy name
orderNoDefault priority: targets in the order given
termsNoPrefer small passives matching these on equally short routes
passivesYesMain-tree targets in priority order
ascendancyNo
targetLevelNoLevel to budget for (default 90)
ascendancyPassivesNoIn the order they'll be taken (2 per trial)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.0-beta
    • addedInput schema / properties / ascendancyPassives / description
      Added value: +"In the order they'll be taken (2 per trial)"
    • addedInput schema / properties / avoid
      Added value: +{
+  "description": "Avoid small passives matching these on equally short routes",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / order
      Added value: +{
+  "description": "Default priority: targets in the order given",
+  "enum": [
+    "priority",
+    "cheapest"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / terms
      Added value: +{
+  "description": "Prefer small passives matching these on equally short routes",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv0.5.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only supply readOnlyHint, so the description carries the behavioral burden and does so richly: tie-breaking rules for terms/avoid, onTheWay flagging of notables, ascendancy gating requiring the unlocking node to be present and flagged with the trial, and the extra 8 ascendancy points (2 per trial). This is significantly more than the readOnly annotation conveys.

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?

The core action is front-loaded before the conditional details about tie-breaking and ascendancy gating. It is a dense single paragraph with some nested parentheticals, but every sentence adds actionable rules rather than filler.

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 8 parameters, no output schema, and only a readOnly annotation, the description covers the important behaviors: ordering, tie-breaking, ascendancy gating, and the level annotation it returns. The main remaining gap is the exact shape of the returned route/level data, though it hints at it.

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 already 88%, so the baseline is 3, and the description adds real meaning on top: it defines the semantics of order, terms, avoid, ascendancyPassives ordering (2 per trial), and the targetLevel budget ('default 90'). It also notes passives can be passed by key, id, or exact name, which the schema does not spell out.

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 and resource: it connects the class start to chosen passives and reports the character level at which each point can be taken. It is clearly distinguishable from sibling tools like find_passives, which it names as the way to look up small-passive keys.

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 explains the default ordering ('priority order') versus the 'cheapest' alternative, and explicitly tells the agent how to force a route by listing small passives as targets, including the find_passives call needed to get their keys. It stops short of stating when to prefer this tool over optimize_build or check_build among siblings.

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

Deploy Server

Other Tools