This MCP server provides a comprehensive suite of tools for analyzing Path of Exile 2 builds, exploring the passive skill tree, generating crafting advice, and retrieving game mechanics and wiki information.
Build Loading: Import builds from Path of Building export codes, pobb.in links, poe.ninja community builds, or your own characters.
Character Stats: Retrieve computed stats including life, mana, energy shield, DPS, resistances, and movement speed.
Passives & Tree: List allocated passive nodes (keystones, notables, masteries), search the full passive tree with optional class region filtering (Druid, Huntress, Mercenary, Monk, Sorceress, Warrior), find reachable unallocated nodes within a given distance, and compute shortest paths to target nodes.
Items & Skills: View equipped items with mods, rarity, and item level, plus skill socket groups, active skills, and gem links.
Crafting Advisor: Get affix pools for item bases, build-aware advice for adding stats to items, crafting method rankings by risk, and analysis of how well equipped items fit the build.
Mechanics & Wiki: Access curated explanations of core PoE2 systems (defenses, ailments, spirit, gems) with PoE1 pitfall notes, plus live wiki lookups for items, skills, and mechanics.
Vendor Regex: Generate build-aware vendor search regexes within a 50-character budget.
Meta Overview: Browse ascendancy popularity and top community builds from poe.ninja.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@poe2-mcp load my build from pobbin.in/abc123 and show me my life and resistances"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Path of Exile 2 build analysis. Load a build from a Path of Building export code and interrogate it with natural language via any MCP-compatible client (Claude Desktop, Claude Code, etc.).
Decodes PoB export codes (the long base64 string from File → Share → Copy code) or pobb.in share links
Exposes stats, passives, items, and skills as MCP tools
Searches the full PoE2 passive skill tree, including nodes not yet allocated
Filters tree searches to a specific class region using a Voronoi partition — so search_tree("life", classes=["Monk"]) returns only nodes in the Monk area rather than all 4,700 nodes in the tree
Related MCP server: pob2-mcp
Requires Python 3.11+ and uv.
git clone https://github.com/deepwa7er/poe2-mcp.git
cd poe2-mcp
uv syncAdd this to your claude_desktop_config.json:
{
"mcpServers": {
"poe2": {
"command": "uv",
"args": ["--directory", "/path/to/poe2-mcp", "run", "poe2-mcp"]
}
}
}claude mcp add poe2 -- uv --directory /path/to/poe2-mcp run poe2-mcpTool | Description |
| Load a PoB export code or |
| Character stats — life, mana, DPS, resistances, etc. |
| Allocated passive nodes with names and stat descriptions |
| Equipped items and their mods |
| Skill socket groups and gem links |
| Keyword search within allocated passives |
| Keyword search across the full passive tree |
| Unallocated nodes reachable within N steps from the current build |
| Inspect a single tree node and its directly connected neighbors |
| Shortest sequence of nodes to allocate to reach a target node, with point cost |
| Passive/ascendancy point usage summary for the loaded build |
| Defensive sanity checks — uncapped/negative resistances, health pool |
| The affix pool that can roll on a base — prefix/suffix, tiers, item level, spawn weight |
| Build-aware advice for adding a stat to an item — open slots, tiers, risk-rated methods |
| How well equipped items fit the build — per-mod tier & roll quality, relevance, next-item criteria |
| Durable model of a PoE2 game system (ailments, defenses, spirit, gems, …) — corrects PoE1 assumptions |
| Build-aware vendor-search regex for one slot, packed under a 50-char budget |
| Current build meta (ascendancy popularity) for a league, from poe.ninja |
| Top community builds on the poe.ninja ladder |
| Load a poe.ninja ladder build by account + character name |
| Your own characters from poe.ninja (any league) |
| Load one of your own characters by name — no PoB export needed |
| Live unique/base item lookup from the community wiki (current patch) |
| Live active-skill lookup from the community wiki |
| Live wiki page text for a mechanic — verify/refresh |
| Resolve a name to community-wiki page titles |
search_tree and get_reachable_nodes accept a classes parameter that restricts results to nodes in the specified class territories. This dramatically reduces noise when exploring the tree.
Valid class names: Druid, Huntress, Mercenary, Monk, Sorceress, Warrior
search_tree("life", classes=["Monk"])
search_tree("lightning", classes=["Monk", "Sorceress"])
get_reachable_nodes(max_distance=5, classes=["Monk"])The partition is computed at startup via a simultaneous multi-source BFS from all six class starting nodes. Each node is assigned to whichever class start is fewest steps away in the tree graph.
get_meta_overview, list_top_builds, and load_community_build surface what the
PoE2 ladder is playing, sourced from poe.ninja. A
typical flow:
get_meta_overview() → which ascendancies are popular now
list_top_builds(limit=20) → the top ladder builds + headline stats
load_community_build(account="…", name="…") → pull one in; then analyze it like any buildOnce a community build is loaded, every analysis tool (get_stats, get_passives,
analyze_defenses, path_to_node, …) works on it.
Skip the Path of Building export/paste entirely for your own builds:
list_my_characters() → all your characters (name, class, level, league)
load_my_character("MyChar") → load one straight in for analysisSet the POE2_ACCOUNT environment variable to your account (Name#1234) so you don't
pass it every time, e.g. in the MCP server config:
{
"mcpServers": {
"poe2": {
"command": "uv",
"args": ["--directory", "/path/to/poe2-mcp", "run", "poe2-mcp"],
"env": { "POE2_ACCOUNT": "YourName#1234" }
}
}
}Your PoE profile must be public. poe.ninja can only load characters it has indexed on the current ladder; for Standard/SSF/fresh alts it lists them but asks you to export from PoB for that one.
These tools use poe.ninja's public but undocumented API, so it may change without notice. Responses are cached briefly to stay fast and to be a polite client.
The export shows an item's rolled mods but not the pool behind them. list_mods_for_base
and craft_advisor add that: which affixes can roll on a base (prefix/suffix, tiers, item
level, weight), and — for an equipped item — whether a target stat can be added, which slots
are free, and the lowest-risk way to do it. PoE2 crafting is largely additive and random, so
the open-slot question is the whole point.
list_mods_for_base("Sapphire Ring", keyword="cold resistance") → the cold-res tiers a ring can roll
craft_advisor(target="cold resistance", slot="Gloves") → can I add it to my gloves, and how?
analyze_item_fit() → score every equipped item against the buildanalyze_item_fit reads the same affix pool the other crafting tools use, but in the other
direction: it takes each item's rolled mods and places them back on their tier ladders —
which tier (T1 = best), how good the roll is within that tier, and the best tier the item's
level could already hold — then judges each mod's relevance to the build (its damage types
and delivery come from the active skills; life-vs-energy-shield and resistance gaps from the
computed stats). Weak on-build rolls become next_item_criteria for the slot. It respects
the package rule: an off-build affix is normal, never "remove mod X", and there is no single
fit score.
craft_advisor ranks methods by risk (rune-in-socket, Exalt-to-open-slot with an approximate
hit chance, essence/omen, remove-and-add, replace) and is honest about its limits — slot counts
are inferred by classifying rolled mods, and it never invents essence values that aren't in
the data. Rune/Soul Core options quote the real granted line for the item's slot (e.g. "+14% to
Cold Resistance"), tier-ranked with any conditional "Bonded" bonus. See
docs/crafting-advisor.md for details.
An agent reviewing a build supplies most of its mechanics reasoning from training — and that
training is contaminated with PoE1 assumptions that are wrong in PoE2 (armour blocks only
physical, chaos bypasses energy shield, evasion only dodges attacks, support gems are a scarce
shared pool, gems gain XP, auras reserve mana — all false today). explain_mechanic is the
antidote: a curated, patch-stamped model of each core system, so the agent reasons from how the
game actually behaves instead of reciting PoE1.
explain_mechanic() → the index: headline PoE1 traps + every topic
explain_mechanic("defenses") → how armour/evasion/ES/block/resists really work in PoE2
explain_mechanic("armour") → lenient matching resolves synonyms to the right topicTopics: gems, spirit, spirit-skills, ailments, defenses, resistances,
damage-conversion, crit, charges, attributes, ascendancy, support-scaling. It's
deliberately conceptual — durable rules and the PoE1 traps lead, and exact numbers (which churn
per patch) are flagged as patch-sensitive rather than asserted.
The vendored data and explain_mechanic are durable but patch-stamped and bounded to what's
shipped. lookup_item, lookup_skill, lookup_mechanic, and wiki_search close the gap with
live, current-patch data from the community wiki (poe2wiki.net),
queried through its MediaWiki/Cargo API as structured JSON — no scraping, no extra dependencies.
lookup_item("Headhunter") → a unique's rolled stat ranges and flavour, current patch
lookup_item("Heavy Belt") → a base type's implicit and item class
lookup_skill("Spark") → a skill's base stat lines, infusions, description
lookup_mechanic("Shock") → the wiki's prose on a mechanic — verify explain_mechanic's numbers
wiki_search("energy shield") → resolve a name to wiki page titlesThese are the one part of the server that reaches the network per call (results are cached for an
hour); each returns an {"error": …} dict rather than raising if the wiki is unreachable.
lookup_mechanic is the deliberate complement to explain_mechanic: the latter gives the durable
PoE1-vs-PoE2 corrections offline, the former the live numbers to verify them against.
generate_vendor_regex turns the loaded build into a short alternation regex you can paste into
a vendor's search bar. Uncapped resistances, life, slot intent (movement on boots), and the active
skill's damage-type / speed scaling drive what gets included; the result is packed under a 50-char
budget (the vendor bar limit). Capped resistances are dropped automatically — fix them in-game and
the next call's regex shrinks.
generate_vendor_regex(slot="Gloves") → {"regex": "Life|Fire Dam|tta.*Sp", ...}
generate_vendor_regex(slot="Boots") → {"regex": "Life|Move|Res", ...}
generate_vendor_regex(slot="Boots", include=["minion"]) → forces a key past the slot allowlistEach call also returns what was included, what was dropped (and why), and a per-entry reason so you can see which fragment came from which need.
The passive tree is generated from Path of Building 2's bundled tree data (src/TreeData/<version>/tree.lua in the PoB2 repo) by scripts/build_tree_data.py — GGG publishes no official PoE2 tree JSON, and the community passive-skill-tree-json mirror is PoE1-only. Sourcing from PoB2 keeps the tree version-aligned with the gem database and the recompute engine, which track the same repo. Regenerate the bundled data/poe2_tree.json after a patch with uv run python scripts/build_tree_data.py, or point the TREE_DATA_PATH environment variable at an alternative file.
The affix pool and base types are sourced from the RePoE-fork PoE2 export — static JSON extracted from the client (GGG ships no PoE2 data export, and poe2db has no data API). scripts/build_craft_data.py fetches and slims it to the bundled data/poe2_crafting.json. The pool drifts between patches; regenerate with uv run python scripts/build_craft_data.py, or point CRAFT_DATA_PATH at an alternative file.
Rune and Soul Core grants (which the RePoE export omits) come from PoB2's src/Data/ModRunes.lua, where they're stored per item class already rendered to English. scripts/build_rune_data.py parses it to the bundled data/poe2_runes.json (rune → item class → granted lines, type, rank), which craft_advisor uses to quote real per-slot values. Regenerate with uv run python scripts/build_rune_data.py, or override with RUNE_DATA_PATH.
The gem database (data/poe2_skills.json) is generated from PoB2's src/Data/Skills/*.lua by scripts/build_skill_data.py — the same data PoB uses for its own calculations, so it carries skill tags, Spirit reservation, and each gem's flat/quality stat ids. Override with SKILL_DATA_PATH.
The stat-description map (data/poe2_stat_descriptions.json) turns those raw stat ids into the in-game line a player reads — base_reduce_enemy_fire_resistance_% = 30 becomes "Penetrate 30% Fire Resistance". It's generated by scripts/build_stat_data.py from PoB2's src/Data/StatDescriptions/*.lua, slimmed to the ids the gem database references and split into support/skill wording scopes. get_skill_details and recommend_supports attach the rendered text alongside the raw id/value. It renders single- and multi-stat lines (e.g. "Adds X to Y Damage") with the game's own value transforms — milliseconds→seconds, per-minute→per-second, negate ("30% less"), and the rest (see docs/plain-english-stat-text.md); quality stats render at the 20% cap ("Chain +2 times (at 20% quality)"); only a long tail of internal/no-display stats stays raw. Regenerate with uv run python scripts/build_skill_data.py && uv run python scripts/build_stat_data.py (skills first), or override with STAT_DESC_PATH.
uv sync # install dependencies (including dev)
uv run pytest # run the test suiteReturn all equipped items in the loaded build with their mods.
Each item includes slot, rarity, name, base type, item level, and the list of mod lines exactly as they appear in the game tooltip.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently states the action is returning data and lists the fields included. It implies read-only behavior by saying 'Return all equipped items.' While it doesn't explicitly confirm no side effects, the description is sufficient for a simple retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and each sentence adds value. No unnecessary words, making it highly concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description is complete. It lists the return fields even though the output schema likely defines them, so the description adds context about the tool's purpose without needing further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is effectively 100%. Per rules, 0 parameters yields a baseline of 4, and the description correctly adds no extra parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all equipped items with their mods, listing the specific fields (slot, rarity, name, base type, item level, tooltip mod lines). This distinguishes it from siblings like get_passives, get_skills, etc., which return different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs details about equipped items in the currently loaded build. There is no explicit guidance on alternatives or when not to use, but it's a simple read with no parameters, making usage straightforward. A 4 is appropriate given clarity without explicit alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all allocated passive nodes in the loaded build.
By default only keystones, notables, and masteries are returned — the nodes that meaningfully define the build. Set include_small_nodes=True to also include the generic small passives (+10 str, +5 life, etc.).
If tree data is not loaded, returns the raw node IDs only.
| Name | Required | Description | Default |
|---|---|---|---|
| include_small_nodes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses default filtering and edge case (raw IDs without tree data), though does not detail return format (covered by output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one optional parameter and an output schema, the description covers behavior, default, edge case, and parameter usage adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains the boolean parameter include_small_nodes with examples of what small passives are, adding meaning beyond the schema's default and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns allocated passive nodes, specifies default filter (keystones, notables, masteries), and distinguishes from sibling tools by focusing on passive nodes specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the include_small_nodes parameter and behavior when tree data is missing, but does not explicitly guide when to use this tool over siblings like search_passives or get_reachable_nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all unallocated passive nodes reachable within max_distance steps from the current build.
Distance 1 = adjacent to an allocated node (can be taken with the next point). Distance 2 = one unallocated pathing node away, and so on.
Results are sorted by distance (closest first), then by type (keystones and notables before small nodes). Use this to find what is actually within reach before recommending passive picks.
Use classes to restrict results to one or more class regions, filtering out nodes from unrelated parts of the tree. Valid class names: Druid, Huntress, Mercenary, Monk, Sorceress, Warrior.
Requires both a loaded build and tree data.
| Name | Required | Description | Default |
|---|---|---|---|
| max_distance | No | ||
| include_small_nodes | No | ||
| classes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description thoroughly explains the tool's behavior: returns nodes sorted by distance and type, filtering by class regions. It discloses that it requires a loaded build and tree data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with clear front-loading of the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description sufficiently covers all operational aspects: what it returns, sorting, filtering, prerequisites, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning: max_distance is explained, include_small_nodes is tied to sorting order, and classes lists valid names and purpose. No schema overhead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'all unallocated passive nodes reachable within max_distance steps from the current build.' It explains distance semantics and sorting order, distinctly differentiating it from siblings like search_passives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises to use this tool 'before recommending passive picks' and notes prerequisites. While it doesn't explicitly list when not to use, the context strongly implies its specific use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all skill socket groups in the loaded build.
Each group shows the active skill, its support gems, the slot it occupies, and whether it is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses returned data (groups, gems, slot, enabled) but does not mention error handling (e.g., no build loaded) or that it is a read-only operation. Basic but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with purpose. Every sentence provides value - first states purpose, second details returned fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema available, description need not explain return values in detail. It adequately describes context ('in the loaded build') but omits potential error states like missing build. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0), baseline 4. Description adds meaning about the return structure beyond the empty schema, explaining what each group contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return all skill socket groups in the loaded build' - specific verb and resource. Distinguishes from sibling tools like get_items and get_passives by focusing on skill sockets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage in context of 'loaded build' but no explicit guidance on when to use vs alternatives like search_passives or when not to use. Does not mention prerequisites like requiring a loaded build.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all computed character stats from the loaded build.
These are the values Path of Building calculates: life, mana, energy shield, resistances, DPS for each skill, movement speed, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It does not disclose side effects, rate limits, or behavior when no build is loaded. However, the tool appears to be a straightforward read operation with no destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and supplemented with examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description is complete. It explains what the tool returns and provides examples, fitting well with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds no parameter info, which is acceptable since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns computed character stats from the loaded build, listing examples like life, mana, resistances, and DPS. It uniquely identifies its purpose among siblings, which focus on items, passives, skills, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after loading a build but does not explicitly state when to use it versus alternatives. Sibling tools exist, but no guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a Path of Building export code or pobb.in share link.
Accepts:
A raw PoB export code (the long base64 string from File > Share > Copy code)
A pobb.in URL (e.g. https://pobb.in/AbCdEfGh)
Call this first before using any other tool.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool 'loads' input but does not disclose internal behavior, side effects, state changes, or return format. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy, immediate front-loading of purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema exists), the description covers purpose, accepted inputs, and ordering. Lacks explanation of output or error handling, but output schema likely fills the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides only parameter name and type (string). Description adds critical meaning by specifying that 'code' can be a raw base64 string or a pobb.in URL, fully compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a Path of Building export code or pobb.in link, specifying the verb and resource. It also distinguishes from siblings by positioning itself as a prerequisite ('Call this first before using any other tool').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first before any other, providing clear when-to-use guidance. It also details what inputs are accepted (raw code or URL), eliminating ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the loaded build's allocated passives for nodes matching a keyword.
Searches both node names and stat descriptions (case-insensitive). Requires tree data to be loaded; returns an error message otherwise.
Examples: search_passives("life") → all life-related nodes search_passives("fire") → fire damage nodes search_passives("Acrobatics") → the Acrobatics keystone if allocated
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses search scope (names and stat descriptions, case-insensitive) and error behavior. With no annotations, description carries the burden; it does well without needing to detail return values due to output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: 5 lines, front-loaded with purpose. Every sentence adds value (scope, prerequisite, examples). No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return details not needed. Description covers purpose, prerequisite, scope, case-insensitivity, and examples. Complements siblings like get_passives and search_tree.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' is thoroughly described: it searches both names and stat descriptions, case-insensitive. Examples clarify usage. Schema coverage 0% but description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Search the loaded build's allocated passives for nodes matching a keyword.' It clearly distinguishes from siblings like get_passives which likely returns all passives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite 'Requires tree data to be loaded; returns an error message otherwise.' Provides examples illustrating typical usage. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the full passive skill tree for nodes matching a keyword.
Unlike search_passives, this searches ALL nodes in the tree — not just those allocated in the loaded build. Use this to discover nodes you haven't taken yet.
Each result includes:
allocated: whether the node is already taken in the current build
ascendancy: the ascendancy class that unlocks this node, or "" for generic nodes
distance_from_build: minimum passive points needed to reach this node from the current build (null if no build is loaded or the node is unreachable)
Use classes to restrict results to one or more class regions (Voronoi partition). This eliminates nodes from the opposite side of the tree that are never reachable in practice. Valid class names: Druid, Huntress, Mercenary, Monk, Sorceress, Warrior.
A build does not need to be loaded. Tree data must be present.
Examples: search_tree("life") → all life notables across the full tree search_tree("lightning", classes=["Monk"]) → lightning nodes near the Monk start search_tree("life", classes=["Monk", "Sorceress"]) → life nodes in two regions search_tree("Invoker") → all Invoker ascendancy nodes
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| include_small_nodes | No | ||
| classes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the output fields (allocated, ascendancy, distance_from_build) and their behaviors, notes that a build does not need to be loaded, and explains the effect of the classes parameter. Provides sufficient transparency for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, contrast, return fields, usage guidance, examples. Every sentence adds value, and the length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers purpose, usage, parameters (with one minor gap), prerequisites, and examples. The presence of an output schema reduces the need to describe return format. Complete enough for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The query and classes parameters are well described, but the include_small_nodes parameter is not mentioned in the description despite having no schema description coverage. This omission reduces completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches the full passive skill tree for nodes matching a keyword, and distinguishes from the sibling 'search_passives' tool by noting this searches ALL nodes, not just allocated ones in the current build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with search_passives, explains when to use this tool (discover nodes not yet taken), provides guidance on using the classes parameter to restrict results, and lists valid class names and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_itemsget_passivesget_reachable_nodesget_skillsget_statsload_buildsearch_passivessearch_treeEach tool has a clearly distinct purpose: load_build is foundational, get_items/get_passives/get_skills/get_stats retrieve different build aspects, search_passives/search_tree search different scopes, and get_reachable_nodes finds nearby nodes. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., load_build, get_items, search_tree), making them predictable and easy for an agent to understand.
8 tools is well-scoped for a build analysis server: loading, viewing items/passives/skills/stats, searching, and finding reachable nodes. Not too few or too many.
The tool set covers core build inspection needs comprehensively, but lacks write operations (e.g., modify passives, equip items). For a read-only analysis server, this is nearly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deepwa7er/poe2-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
