Skip to main content
Glama
Sign In
Path of Building MCP Server

Path of Building MCP Server

by urbanvcode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

optimize_tree

Optimizes a Path of Building passive tree by removing inefficient nodes and reallocating points toward damage, defense, or balanced goals.

Instructions

Full passive tree optimization - removes inefficient nodes and reallocates to better options

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "build_name": "<build_name>",
      "goal": "<goal>"
    },
    "name": "optimize_tree"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalYesPrimary optimization goal: 'damage', 'defense', 'balanced'
build_nameYesBuild to optimize
max_pointsNoNumber of passive points to optimize; caps how many recommended allocations are returned (default: 10)
constraintsNoOptional constraints: { minLife, minES, protectedNodes: string[] }. protectedNodes are excluded from recommendations; minLife/minES are evaluated against current stats and reported (suggestions are not stat-recalculated).
max_iterationsNoMaximum optimization iterations (accepted for forward compatibility; not used by the current analyzer)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and leaves key questions open: does 'removes inefficient nodes and reallocates' mutate the saved build or only produce recommendations, and under what conditions? The parameter schema hints at read-only recommendations ('caps how many recommended allocations are returned'), but the description alone suggests a write operation, so an agent can't settle cost and risk from it. No permissions, side effects, or output behavior are disclosed.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity reflects thin coverage rather than disciplined compression.

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

Completeness2/5

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

This is a complex tool: five parameters, a nested constraints object, no annotations, and no output schema to explain results. For that complexity the description is far too thin—it never says whether the tree is modified, what the response contains, or when this should be preferred over the analysis siblings.

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%, including the nested constraints object and the note that max_iterations is currently unused, so the schema already does the heavy lifting. The description adds no meaning about goal values, point budgeting, or how constraints affect results beyond what the schema states; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full passive tree optimization') plus the mechanism ('removes inefficient nodes and reallocates'), which separates it from analysis siblings like analyze_build and from optimize_skill_links. It stops short of naming which sibling to use instead, but the operation itself is unambiguous.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as analyze_build (for diagnosis) or compare_trees (for evaluating results). The word 'Full' faintly implies this is the comprehensive optimizer, but an agent must infer that on its own.

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