Skip to main content
Glama
Sign In
PoB PoE2 MCP

PoB PoE2 MCP

by Hecatoncheir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pob_tree_icons

Read-only

Fetches original PNG RGBA icons for up to 32 Path of Exile 2 passive tree nodes by name, helping you render or inspect the current tree with accurate node visuals.

Instructions

Оригинальные иконки узлов текущего дерева в PNG RGBA. Имена берите из pob_get_tree; до 32 за запрос.

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": {
      "icons": "<icons>"
    },
    "name": "pob_tree_icons"
  }
}

Input Schema

NameRequiredDescriptionDefault
iconsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.15.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the PNG RGBA output format and the batch cap of 32, plus the fact that icons are for the *current* tree (state-dependent), but it does not say what happens for unknown names or when no tree is loaded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler: resource and format first, then the input source and the batch limit. Nothing is redundant or buried.

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

Completeness3/5

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

For a single-parameter read tool with no output schema, the agent still lacks the return shape — one image per requested name, a list, or a map — and how multiple icons are delivered. The description covers input sourcing and format but leaves the response structure implicit.

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 coverage is 0%, so the description must carry parameter meaning; it partially does by telling the agent that the 'icons' entries are node names obtained from pob_get_tree. It still does not clarify whether items are node IDs or display names, or what the 512-character item bound represents.

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?

The description names a specific resource (original node icons of the current tree) and its output encoding (PNG RGBA), which separates it from pob_tree_textures and pob_gem_icons. It never states an explicit verb such as 'fetch/return', but the intent is unmistakable.

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 gives an explicit input-source rule: take names from pob_get_tree, which is the key prerequisite for calling this tool correctly. It does not say when to prefer it over pob_tree_textures or pob_render_image, so no exclusions are offered.

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