Path of Building MCP Server

Overview Schema Source Related Servers Discussions Admin

find_affix_tiers

Look up every tier of a prefix or suffix affix with item levels, value ranges, and valid base tags to price modifiers before pricing an item.

Instructions

Look up every tier of a rollable affix in Path of Building's ModExplicit table (ModItem on older installs): prefix or suffix, minimum item level, the value range per entry, and the base tags it can roll on. Displays affix names and item levels without inventing T1/T2 labels from filtered result order. Use it to price an affix before pricing an item, since a top-tier rare suffix often replaces a costly unique built around the same stat. LIMITS: slot filtering uses PoB's base tags, not slot names. Body armour bases carry str_armour / dex_armour / int_armour and their hybrids; influenced variants add a suffix like _elder or _shaper; a plain 'armour' tag exists too and does not cover the attribute-specific ones. Pass several tags when unsure. Mods whose spawn weights are all zero are excluded unless include_unobtainable is set.

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": {
      "search": "<search>"
    },
    "name": "find_affix_tiers"
  }
}

Input Schema

Name	Required	Description
`search`	Yes	Stat wording, affix name, group or mod tag (e.g. 'Chaos Resistance', 'of Bameth', 'ChaosResistance').
`slot_tags`	No	PoB base tags the mod must be able to roll on, matched exactly, any one of them. Examples: 'ring', 'amulet', 'belt', 'int_armour', 'body_armour', 'bow'.
`affix_type`	No	Restrict to prefixes or suffixes.
`max_results`	No	Maximum affix groups to return (default 10).
`max_item_level`	No	Drop tiers the item level cannot reach.
`include_unobtainable`	No	Include mods with no non-zero spawn weight. They exist in the data but nothing can roll them. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 13, 2026

TDQS

A4/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 disclosure burden and does substantial work: it states that zero-spawn-weight mods are excluded unless include_unobtainable is set, that T1/T2 labels are not invented from filtered result order, and how base-tag matching behaves including influenced variants. Remaining gaps are ordering of results and any cost/latency profile, but the filtering semantics an agent actually needs 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?

Purpose is front-loaded, and the LIMITS block is dense with genuinely useful caveats rather than filler. It runs long and the pricing rationale sentence is slightly elaborative, but every section carries information an agent would otherwise guess wrong.

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 a 6-parameter, annotation-free tool with no output schema, the description covers what is returned, how filtering and exclusion work, and the main pitfall of tag naming. The only omissions are result ordering and how max_results interacts with grouping, which are minor relative to what is covered.

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 100%, so a baseline of 3 applies, and the description earns more by explaining the non-obvious semantics of slot_tags: attribute/hybrid armour tags, '_elder'/'_shaper' influenced suffixes, and the caveat that a plain 'armour' tag does not cover attribute-specific ones. That is genuine meaning beyond the schema's example list.

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 opens with a concrete verb+resource pair ('Look up every tier of a rollable affix') and names the exact data source (ModExplicit / ModItem), then enumerates what each result contains: prefix/suffix, minimum item level, value range per entry, and base tags. That is far more specific than the title alone, though no sibling tool (e.g. list_craftable_mods, classify_item_affixes) is named to draw an explicit boundary.

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 a clear use case ('use it to price an affix before pricing an item, since a top-tier rare suffix often replaces a costly unique') and a LIMITS block that explains when slot filtering will mislead and to pass several tags when unsure. It stops short of naming an alternative tool for the cases this one doesn't fit.

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