The poe2-mcp-server gives LLMs real-time access to Path of Exile 2 game data — economy, wiki, datamined content, builds, and local game data — using only public APIs with no authentication required.
Economy Data
poe2_currency_prices — Current exchange rates for all currencies in a league (chaos-equivalent values, trade volumes)
poe2_currency_check — Look up a specific currency's value by partial name (e.g., "divine", "exalted")
poe2_item_price — Market prices across exchange categories (Currency, Fragments, Essences, Runes, Idols, Breach, Delirium, etc.)
poe2_exchange_top — Top N most valuable items in a given exchange category
Game Knowledge
poe2_wiki_search — Search the PoE2 community wiki for mechanics, skills, items, and monsters
poe2_wiki_page — Retrieve full content of a specific wiki article
poe2_db_lookup — Datamined game data (gems, mods, passives, items) from poe2db.tw; supports multiple languages (e.g., lang="ru", lang="fr")
Build & Meta Analysis
poe2_meta_builds — Ladder class/ascendancy distribution with popularity percentages and trend indicators
poe2_pob_decode — Decode builds from pobb.in or poe.ninja links
poe2_pob_compare — Compare two builds and highlight differences
poe2_pob_local_builds — List locally saved Path of Building 2 builds
Local Game Data & Items
poe2_log_summary — Parse local game client logs for zone, session, and event history
poe2_parse_item — Parse in-game item clipboard text, detect language, and enrich with mod tiers, base stats, open crafting slots, and unique item pricing
The server can be configured with custom game installation paths, Path of Building directories, and default leagues (e.g., "Standard" or "Dawn of the Hunt").
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-server How much is a Divine Orb worth in the current league?"
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.
A Model Context Protocol (MCP) server that gives LLMs real-time access to Path of Exile 2 game data: currency exchange rates, item prices, wiki content, datamined game information, and ladder meta-build statistics.
All data is sourced from public APIs only. No API keys, no GGG OAuth registration, no accounts required.
Tool | Description | Source |
| Current exchange rates for all currencies | |
| Look up a specific currency by name | |
| Price check items across exchange and unique categories | |
| Most valuable items by exchange category | |
| Search the PoE 2 community wiki | |
| Retrieve full wiki article content | |
| Datamined game data: gems, mods, items, translations | |
| Ladder class distribution with percentages and trends | |
| Parse local game logs: zones, sessions, player events | Local logs |
| Decode builds from pobb.in, poe.ninja, or local files | |
| List saved PoB2 builds from local filesystem | Local PoB2 |
| Compare two builds to identify gear/skill differences | |
| Parse item clipboard text with enrichment (mod tiers, base stats, unique prices) |
Related MCP server: Path of Exile 2 Build Optimizer MCP
Node.js ≥ 22
npm
git clone https://github.com/sergeyklay/poe2-mcp-server.git
cd poe2-mcp-server
npm install
npm run buildAdd to your claude_desktop_config.json:
{
"mcpServers": {
"poe2": {
"command": "node",
"args": ["/absolute/path/to/poe2-mcp-server/dist/index.js"]
}
}
}Windows users: Use double backslashes or forward slashes in the path:
"args": ["C:\\absolute\\path\\to\\poe2-mcp-server\\dist\\index.js"]To open the config file quickly, press
Win + Rand run:notepad %APPDATA%\Claude\claude_desktop_config.json
Config file locations:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Restart Claude Desktop after editing the config.
If PoE2 is installed in a non-standard location (e.g., a different drive), add the --poe2-path argument:
{
"mcpServers": {
"poe2": {
"command": "node",
"args": [
"C:\\path\\to\\poe2-mcp-server\\dist\\index.js",
"--poe2-path",
"D:\\Games\\Path of Exile 2"
]
}
}
}To specify a custom PoB2 builds directory (for poe2_pob_* tools), add --pob2-path:
"args": [
"C:\\path\\to\\poe2-mcp-server\\dist\\index.js",
"--pob2-path",
"D:\\PoB\\Builds"
]Override the default league used by all price/economy tools via --league:
"args": [
"C:\\path\\to\\poe2-mcp-server\\dist\\index.js",
"--league",
"Standard"
]When not specified, defaults to the current challenge league (Dawn of the Hunt). The AI agent can still pass any league name per-request — this only changes the fallback.
claude mcp add poe2 node /absolute/path/to/poe2-mcp-server/dist/index.jsWith custom game path:
claude mcp add poe2 node /path/to/poe2-mcp-server/dist/index.js --poe2-path "/path/to/Path of Exile 2"With custom league:
claude mcp add poe2 node /path/to/poe2-mcp-server/dist/index.js --league "Standard"npx @modelcontextprotocol/inspector node dist/index.jsOnce connected, try asking:
"How much is an Exalted Orb worth right now?"
"What are the top 10 most valuable items in the Currency exchange?"
"Show me my play session history"
"Which classes are most popular on the ladder this league?"
"Look up Essence Drain on poe2db"
"Decode this build: pobb.in/abc123"
"Analyze poe.ninja/poe2/pob/19f0c"
"Compare my local build to this guide"
"What's the French name for Chaos Bolt?" → uses poe2_db_lookup with lang="fr"
"Parse this item I just found: [paste Ctrl+C text]"
User:
I just found this, is it any good?
Item Class: Body Armours
Rarity: Rare
Empyrean Shelter
Vaal Regalia
--------
Quality: +20% (augmented)
--------
Energy Shield: 286 (augmented)
--------
Requirements:
Level: 68
Int: 194
--------
Sockets: S S
--------
Item Level: 74
--------
+42 to maximum Life (implicit)
--------
78% increased Energy Shield (rune)
--------
+92 to maximum Energy Shield
+38% to Lightning Resistance
+24% to Cold Resistance
14% increased Stun and Block RecoveryClaude:
This is a strong ES chest for mid-mapping. Here's the breakdown:
- 286 Energy Shield at +20% quality with a rune boosting ES by 78% — that's solid.
- +92 flat ES on top of the base makes this a high-ES piece for its tier.
- Dual resistances (38% lightning + 24% cold) cover a big chunk of your res needs.
- +42 max life implicit gives hybrid survivability.
For a level 68 Vaal Regalia at item level 74, this is a keeper. The main upgrade path would
be finding one with higher flat ES or a third resistance, but that's an endgame min-max concern.
Use it now — it'll carry you through T5+ maps comfortably.User:
I'm stuck on this quest boss... keeps killing me. Is this normal?Claude:
Looking at your logs — you're in the Trial of Chaos (zone level 38) and you've died twice to the
boss already. This is the quest version with Chimeral Inscribed Ultimatum: 4 rooms, boss in room 4.
Yes, this is normal and happens to many players! Here's why:
The boss in room 4 is one of three random encounters: Uxmal (Chimera), Chetza (Bird with blood
attacks), or Bahlak (Three-headed bird with lightning). All of them hit hard, especially against
energy shield builds.
The key thing to know: your quest key doesn't drop on death. It returns to you, so you can retry
as many times as you need.
Tips to get through:
1. ...
2. ...
...This system prompt can be used with any MCP-compatible agent (Claude Desktop, Claude Projects, etc.) to create a PoE2 coach that automatically uses the MCP tools.
# Path of Exile 2 Coach
## Role
You are a knowledgeable Path of Exile 2 coach. You explain complex game systems in clear terms
without being condescending. Communicate in the user's language.
## Tool Usage Protocol
You have access to a PoE 2 MCP server with tools for: game logs, wiki, datamined game database
(poe2db), currency prices, item prices, item clipboard parsing with enrichment (mod tiers, base
stats, unique pricing), build decoding/comparison, and meta build stats. These tools are your
PRIMARY data source for everything PoE 2 related.
For EVERY user message about gameplay, follow this sequence BEFORE responding:
1. **Read player logs** (`poe2_log_summary`) to get current zone, level, deaths, session context
2. **Use MCP tools** (wiki, database, currency, items, builds) for any game knowledge needed
3. **Fall back to web search** ONLY if MCP tools didn't have the answer
4. **Respond** to the user with all context already gathered
## Gather Context, Don't Ask
NEVER ask the user for information you can obtain from tools:
- "What level are you?" → read the logs
- "What zone are you in?" → read the logs
- "How many times did you die?" → read the logs
- "What does skill X do?" → use `poe2_wiki_search` or `poe2_db_lookup`
- "How much does Y cost?" → use `poe2_currency_check` or `poe2_item_price`
- "What builds are popular?" → use `poe2_meta_builds`
- "Is this item good?" → use `poe2_parse_item` with `enrich=true`, read the mod tier table
- "What build should I follow?" → use `poe2_pob_decode` to decode a guide build
Only ask the user for things no tool can provide: personal preferences, build goals.
If logs are unavailable or the game is not running, state this briefly and proceed with available
information.
## Item Evaluation (poe2_parse_item)
When a user pastes item text (Ctrl+C from game), ALWAYS call `poe2_parse_item` with `enrich=true`.
The enrichment section contains:
- **Base type stats** — base ES/Armour/Evasion from datamined data (RePoE)
- **Mod tier table** — each explicit mod with Tier (T1/8 = best of 8 tiers), value range,
prefix/suffix classification, and best tier available at the item's ilvl
- **Open slots** — how many prefix/suffix slots remain for crafting
- **Unique pricing** — chaos value from poe2scout.com (when available)
Use this data to give specific verdicts:
- "Your +50 ES is T1/8 (range 40–55) — that's the best tier, excellent roll"
- "Your 12% cast speed is T2/4 — decent but T1 starts at 13%"
- "You have 2 open prefixes — you can craft flat life or another damage mod"
## Build Comparison (poe2*pob*\*)
When a user shares a pobb.in or poe.ninja/poe2/pob link:
1. Use `poe2_pob_decode` to decode the build
2. If comparing to another build, use `poe2_pob_compare`
3. Use `poe2_pob_local_builds` to list the user's saved builds
## Localization Support
If the player uses a non-English game client:
1. Use `poe2_db_lookup` with the appropriate `lang` parameter (ru, de, fr, jp, kr, cn, tw, etc.)
2. When discussing game terms, provide both the localized name and English name on first mention
3. NEVER guess translations — always verify via the database
4. `poe2_parse_item` auto-detects language and enrichment resolves English base type names
## Examples
### User pastes an item
**User:** "Is this any good? [paste item text]"
**Correct behavior:**
1. Call `poe2_parse_item(text=..., enrich=true)` → get mod tiers, base stats
2. Read the tier table: identify which mods are T1/T2 (great) vs T5+ (mediocre)
3. Check open prefix/suffix slots for crafting potential
4. If unique, note the price from enrichment
5. Give a clear verdict: keep/sell/craft, with specific reasoning from tier data
**Wrong:** Eyeball the numbers without looking up tier data.
### User asks for help without context
**User:** "What should I do next?"
**Correct behavior:**
1. Call `poe2_log_summary` → determine current zone and level
2. Look up relevant game mechanics via `poe2_db_lookup` or `poe2_wiki_search`
3. Respond with specific, actionable steps based on actual player state
**Wrong:** Ask "What zone are you in?" when logs have this information.
### User asks about game mechanics
**User:** "What is Contagion?"
**Correct behavior:**
1. Look up Contagion via `poe2_db_lookup` for exact mechanics
2. If player uses localized client, also fetch the translated name
3. Explain with both names so player can match it in their game
**Wrong:** Guess at mechanics without looking up current data.
### User asks about economy
**User:** "Is this item valuable?"
**Correct behavior:**
1. If user pasted item text, use `poe2_parse_item(enrich=true)` — price is in enrichment
2. Otherwise use `poe2_item_price` to check current market value
3. Use `poe2_currency_check` for currency conversions if needed
4. Give a clear verdict with current prices
**Wrong:** Give outdated price estimates from training data.
## Response Guidelines
- Keep responses focused and actionable
- For item evaluations: lead with the verdict, then cite specific tier data
- For "what do I do?" questions: numbered steps, priority order
- Always end guidance with the single most important next actionDefault league: Dawn of the Hunt. Configurable via --league CLI argument or by editing FALLBACK_LEAGUE in src/constants.ts. The AI agent can override per-request.
League | Name (case-sensitive) |
Softcore Trade |
|
Hardcore |
|
Previous leagues |
|
Permanent SC |
|
Permanent HC |
|
poe2-mcp-server/
├── src/
│ ├── index.ts # Entry point: server init, stdio transport
│ ├── constants.ts # Shared project constants
│ ├── services/
│ │ ├── api.ts # Barrel re-export for all service modules
│ │ ├── http.ts # HTTP client, RateLimiter, User-Agent
│ │ ├── ninja.ts # poe.ninja exchange & build APIs
│ │ ├── poe2scout.ts # poe2scout.com unique item pricing API
│ │ ├── poe2db.ts # poe2db.tw HTML parsing & translation cache
│ │ ├── wiki.ts # poe2wiki.net MediaWiki API
│ │ ├── strings.ts # 11-language keyword mappings for item parsing
│ │ ├── logfile.ts # Client.txt log parsing
│ │ ├── pob.ts # Path of Building decode/compare
│ │ └── repoe.ts # RePoE datamined JSON — mod tiers, base item stats
│ └── tools/
│ ├── currency.ts # Currency exchange rate tools
│ ├── items.ts # Exchange & unique item price tools
│ ├── item.ts # Clipboard item parser with enrichment (11 languages)
│ ├── wiki.ts # Wiki search & poe2db lookup
│ ├── builds.ts # Meta build overview
│ ├── logfile.ts # Local logs parser
│ └── pob.ts # Path of Building integration
├── dist/ # Compiled output (npm run build)
├── package.json
├── tsconfig.json
└── README.mdSource | Auth | Rate Limit | Update Frequency |
poe.ninja PoE2 Exchange API | None | ~12 req / 5 min | ~1 hour |
poe.ninja PoE2 Build Index API | None | ~12 req / 5 min | ~1 hour |
poe2scout.com Unique Item API | None | ~10 req / min | ~1 hour |
poe2wiki.net MediaWiki API | None | Standard MW limits | Community-driven |
RePoE Datamined JSON | None | ~5 req / min | Each patch |
None | ~15 req / min | Each patch | |
pobb.in PoB paste service | None | ~10 req / min | On-demand |
poe.ninja PoB paste hosting | None | ~12 req / 5 min | On-demand |
Local | None | N/A (local file) | Real-time |
Local PoB2 Builds directory | None | N/A (local file) | Real-time |
Built-in rate limiters ensure all API limits are respected automatically.
npm run dev # Watch mode: recompiles on file changes
npm run build # One-time build
npm start # Run the server (stdio)Create a file in src/tools/
Export a register*Tools(server: McpServer) function
Import and call it in src/index.ts
Rebuild: npm run build
MIT
This product isn't affiliated with or endorsed by Grinding Gear Games in any way.
Path of Exile is a registered trademark of Grinding Gear Games. All game content and materials are trademarks and copyrights of their respective owners.
Look up the current value of a specific currency in Path of Exile 2.
Searches by partial name match (case-insensitive) against currency ids and reference item names.
Args:
name (string): Currency name or partial name, e.g. "exalted", "divine", "regal"
league (string): League name (default: "Fate of the Vaal")
Returns: Matched currency with its chaos-equivalent value and trade volume.
Examples:
"How much is a Divine Orb?" → name="divine"
"Price of Regal Orb" → name="regal"
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Currency name or partial match | |
| league | No | PoE2 league name, e.g. "Fate of the Vaal" or "Standard" | Fate of the Vaal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies partial name matching (case-insensitive), mentions searching against both currency ids and reference item names, and indicates the return includes chaos-equivalent value and trade volume. This enhances understanding of how the tool behaves operationally.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by key behavioral details, then parameter explanations with examples. Every sentence adds value without redundancy, and the examples are directly relevant to tool usage.
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 moderate complexity (2 parameters, no output schema), the description is mostly complete. It covers purpose, usage context, behavioral traits, and parameter examples. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of 'matched currency' data), though the mention of 'chaos-equivalent value and trade volume' provides some guidance.
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 description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal extra semantics: it provides examples for the 'name' parameter (e.g., 'exalted', 'divine', 'regal') and mentions the default league. However, this doesn't significantly enhance meaning beyond what's in the schema descriptions, warranting the baseline score of 3.
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's purpose: 'Look up the current value of a specific currency in Path of Exile 2.' This is a specific verb ('look up') + resource ('currency value') combination. It distinguishes from siblings like poe2_item_price (for items) and poe2_currency_prices (likely broader currency listings).
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 provides clear context for when to use this tool: for checking currency values with partial name matching. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., when to use poe2_currency_prices instead). The examples help illustrate appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current currency exchange rates for Path of Exile 2 from poe.ninja.
Returns prices of all currencies with chaos-equivalent values computed from exchange rates. Data refreshes approximately every hour on poe.ninja.
Args:
league (string): League name (default: "Fate of the Vaal")
Returns: List of currencies with their exchange values and trade volumes.
Examples:
"How much is an Exalted Orb worth?" → call with default league
"Currency prices in Standard" → call with league="Standard"
| Name | Required | Description | Default |
|---|---|---|---|
| league | No | PoE2 league name, e.g. "Fate of the Vaal" or "Standard" | Fate of the Vaal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive traits, but the description adds valuable behavioral context beyond this: it specifies the data source (poe.ninja), refresh rate (approximately every hour), and that it returns a list with exchange values and trade volumes. This enhances understanding without contradicting annotations.
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 well-structured and front-loaded, starting with the core purpose, followed by details on returns, data refresh, args, and examples. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 low complexity (1 parameter, 100% schema coverage, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage, and behavioral context adequately. A minor gap is the lack of explicit output structure details, but with annotations indicating safety and idempotency, this is acceptable.
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 description coverage is 100%, with the parameter 'league' fully documented in the schema (including default and examples). The description adds minimal value beyond the schema, only restating the default in the example and implying usage for different leagues. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose with specific verbs ('Get current currency exchange rates') and resources ('Path of Exile 2 from poe.ninja'), distinguishing it from siblings like poe2_item_price (specific items) or poe2_exchange_top (top exchanges). It explicitly mentions chaos-equivalent values and trade volumes, which are unique to this currency-focused 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 provides clear context for when to use this tool (e.g., for currency exchange rates, with examples like 'How much is an Exalted Orb worth?'), but it does not explicitly state when not to use it or name alternatives among siblings. The examples imply usage for currency queries, but no direct comparison to tools like poe2_item_price is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up detailed game data from poe2db.tw — items, gems, mods, passives.
poe2db.tw contains datamined information directly from game files, including exact stat values, gem scaling, mod tiers, and more.
Also useful for finding Russian translations of game terms: use lang="ru" to get Russian page.
IMPORTANT: Skills, passives, and ascendancy nodes with ranks use Roman numerals in poe2db, not Arabic. Convert rank numbers: 1→I, 2→II, 3→III, 4→IV, 5→V. Always include the rank suffix if the user mentions a specific rank.
Args:
term (string): English name of an item, gem, mod, etc. Use underscores for spaces, e.g. "Essence_Drain", "Chaos_Bolt". For ranked skills/passives, append Roman numeral: "Urgent_Totems_II", "War_Cry_III".
lang ("us" | "fr"): Language — "us" for English (default), "fr" for French, etc.
Returns: Raw page content from poe2db (HTML stripped to text, truncated at 6000 chars).
Examples:
Gem details: term="Essence_Drain"
Passive rank 2: term="Urgent_Totems_II" (NOT "Urgent_Totems_2" or "Urgent_Totems")
Ascendancy node rank 3: term="War_Cry_III"
Russian name: term="Chaos_Bolt", lang="ru"
Unique item: term="Atziri's_Rule"
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Search term with underscores for spaces. Use Roman numerals for ranks, e.g. "Urgent_Totems_II", "Essence_Drain" | |
| lang | No | Language: us=English, ru=Russian | us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it explains the source (datamined from game files), mentions truncation at 6000 chars, and specifies that returns are 'HTML stripped to text.' This enhances understanding of the tool's behavior without contradicting annotations.
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 well-structured and appropriately sized. It starts with the core purpose, adds important context about the data source, provides usage notes, and includes clear examples. Every sentence serves a purpose, though the Roman numeral explanation is somewhat detailed. It could be slightly more concise but remains highly effective without wasted words.
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 complexity (database lookup with formatting rules) and lack of output schema, the description provides excellent completeness. It explains what data is returned (raw page content, HTML stripped, truncated), covers parameter nuances thoroughly, and includes practical examples. This compensates well for the missing output schema and ensures the agent understands the tool's full 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?
Schema description coverage is 100%, so the baseline would be 3. However, the description adds significant semantic value beyond the schema: it explains the Roman numeral conversion rule for ranks, provides concrete examples of term formatting, clarifies language usage for Russian translations, and warns about common mistakes. This greatly aids correct parameter usage despite the schema already documenting types and constraints.
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's purpose: 'Look up detailed game data from poe2db.tw — items, gems, mods, passives.' It specifies the exact resource (poe2db.tw) and the types of data retrieved, distinguishing it from sibling tools like currency or price checkers. The verb 'look up' is specific and appropriate for a database query operation.
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 provides explicit guidance on when to use this tool vs. alternatives. It states it's for 'detailed game data from poe2db.tw' and mentions specific use cases like finding Russian translations. It also implicitly distinguishes from siblings by focusing on database lookups rather than currency, prices, or wiki content, making it clear this is the tool for raw datamined information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most valuable items in a given exchange category in Path of Exile 2.
Args:
type (string): Exchange category — Currency, Fragments, Essences, SoulCores, Idols, Runes, etc.
limit (number): How many to return (default: 10, max: 30)
league (string): League name (default: "Fate of the Vaal")
Returns: Top N most valuable items sorted by chaos-equivalent value.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Exchange category | |
| limit | No | Number of results | |
| league | No | Fate of the Vaal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, and non-destructive traits. The description adds valuable context beyond annotations by specifying sorting criteria ('sorted by chaos-equivalent value'), return format ('Top N most valuable items'), and default values, though it omits details like rate limits or authentication needs.
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 front-loaded with the core purpose, followed by a structured breakdown of args and returns in bullet points. Every sentence adds value with no redundancy, making it efficient and easy to parse.
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 moderate complexity (3 parameters, no output schema) and rich annotations, the description is largely complete. It covers purpose, parameters, and returns adequately, though it could benefit from more explicit sibling differentiation or error handling details to reach a perfect score.
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 description coverage is 67% (two parameters have descriptions, one lacks). The description compensates by explaining the purpose of 'type' ('Exchange category'), clarifying 'limit' ('How many to return'), and providing default and max values not in the schema, adding meaningful context beyond the structured fields.
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 specific action ('Get the most valuable items') and resource ('in a given exchange category in Path of Exile 2'), distinguishing it from siblings like currency-specific or wiki tools by focusing on top-value items across multiple categories.
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 usage for retrieving top-value items by category but provides no explicit guidance on when to use this tool versus alternatives like poe2_currency_prices or poe2_item_price, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the current market price of an item in Path of Exile 2 from poe.ninja.
Searches by partial name match across exchange categories (Currency, Fragments, Essences, Soul Cores, Idols, Runes, etc.).
Args:
name (string): Item name or partial name, e.g. "divine", "essence", "rune"
type (string): Exchange category to search. If omitted, searches all categories.
league (string): League name (default: "Fate of the Vaal")
Returns: Matching items with chaos-equivalent values and trade volumes.
Examples:
"How much is a Divine Orb?" → name="divine", type="Currency"
"Price of essences" → name="essence", type="Essences"
"Find rune prices" → name="rune", type="Runes"
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Item name or partial match | |
| type | No | Exchange category to search. If omitted, searches all categories. | |
| league | No | PoE2 league name | Fate of the Vaal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond this: it specifies the data source ('poe.ninja'), mentions partial name matching, and notes that it returns 'chaos-equivalent values and trade volumes.' This enriches the agent's understanding without contradicting annotations.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by details on search behavior, parameters, returns, and examples. Every sentence adds value without redundancy, making it efficient for an agent to parse.
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 moderate complexity (3 parameters, no output schema), the description is mostly complete. It covers purpose, usage, parameters, and returns. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of 'matching items'), though the mention of 'chaos-equivalent values and trade volumes' provides some insight.
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 description coverage is 100%, providing full parameter documentation. The description adds minimal extra semantics: it clarifies that 'name' supports partial matches and lists example categories, but this mostly repeats schema info. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose: 'Look up the current market price of an item in Path of Exile 2 from poe.ninja.' It specifies the verb ('look up'), resource ('market price of an item'), and source ('poe.ninja'), distinguishing it from sibling tools like 'poe2_currency_check' or 'poe2_wiki_search' which likely serve different functions.
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 provides clear context for usage: 'Searches by partial name match across exchange categories...' and includes examples that illustrate when to use specific parameters. However, it does not explicitly state when not to use this tool or name alternatives among siblings, such as 'poe2_currency_prices' for currency-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get class distribution statistics for Path of Exile 2 from poe.ninja.
Shows the most popular classes with their percentage share and trend direction among indexed ladder characters.
Args:
league (string): League name (default: "Fate of the Vaal")
class_name (string): Optional — filter by class, e.g. "Witch", "Lich", "Sorceress"
Returns: Class distribution with percentages and trend indicators.
Examples:
"What's the current meta?" → call with defaults
"Most popular Witch builds?" → class_name="Witch"
| Name | Required | Description | Default |
|---|---|---|---|
| league | No | PoE2 league name | Fate of the Vaal |
| class_name | No | Filter by class name, e.g. Witch, Lich, Warrior, Sorceress |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive traits, so the description adds value by specifying the data source (poe.ninja) and the type of statistics (percentage share, trend direction), but doesn't detail behavioral aspects like rate limits, authentication needs, or data freshness.
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 well-structured and front-loaded with the core purpose, followed by concise sections for arguments, returns, and examples. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 low complexity, rich annotations, and full schema coverage, the description is mostly complete. However, the lack of an output schema means it should ideally detail return values more explicitly, though it mentions 'percentages and trend indicators' which provides some 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 100% schema description coverage, the schema fully documents the two parameters. The description adds minimal semantics by mentioning filtering examples and default usage, but doesn't provide additional meaning beyond what the schema already specifies, such as valid league names or class options.
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 specific action ('Get class distribution statistics') and resource ('Path of Exile 2 from poe.ninja'), distinguishing it from sibling tools like currency or item tools by focusing on class meta data rather than economic or wiki information.
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 provides explicit guidance on when to use the tool with examples ('What's the current meta?' and 'Most popular Witch builds?'), including when to apply the optional filter parameter, though it doesn't explicitly state when not to use it versus alternatives like sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a specific wiki page from poe2wiki.net.
Use poe2_wiki_search first to find the exact page title, then use this to read the full content.
Args:
title (string): Exact wiki page title (from search results)
Returns: Full wikitext content of the page (may be long — truncated at 8000 chars).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Exact wiki page title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, open-world, idempotent, and non-destructive traits, but the description adds valuable context: it warns that returns 'may be long — truncated at 8000 chars,' which is a behavioral detail not captured in annotations. No contradiction with annotations exists.
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 front-loaded with the core purpose, followed by usage guidelines and parameter/return details in a structured format. Every sentence adds value—no wasted words—and it's appropriately sized for the tool's 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?
Given the tool's simplicity (1 parameter, high schema coverage, annotations covering safety and behavior), the description is complete: it clarifies purpose, usage workflow, parameter semantics, and output behavior (truncation). No output schema exists, but the description adequately explains returns.
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 description coverage is 100%, with the parameter 'title' documented as 'Exact wiki page title.' The description adds minimal value beyond this, restating 'Exact wiki page title (from search results)' without providing additional syntax or format details. Baseline 3 is appropriate given high schema 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 verb 'Get' and resource 'full content of a specific wiki page from poe2wiki.net', distinguishing it from sibling tools like poe2_wiki_search (which searches) and others that handle currency, builds, or items. It specifies the exact source and content type, making the purpose unambiguous.
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 states 'Use poe2_wiki_search first to find the exact page title, then use this to read the full content,' providing clear when-to-use guidance and naming the alternative tool. This helps the agent understand the workflow and avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Path of Exile 2 community wiki (poe2wiki.net) for game mechanics, items, skills, and other information.
Args:
query (string): Search term — skill name, mechanic, item, monster, etc.
Returns: Up to 5 matching wiki articles with titles and snippets.
Examples:
"How does Contagion spread?" → query="Contagion"
"Energy Shield mechanics" → query="Energy Shield"
"Lich ascendancy" → query="Lich ascendancy"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for the wiki |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide: it specifies the source (poe2wiki.net), the return format (up to 5 matching articles with titles and snippets), and provides concrete examples of query types. While annotations cover safety and idempotency, the description adds practical usage information that helps the agent understand what to expect from the tool's behavior.
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 well-structured and appropriately sized. It starts with the core purpose, then provides the Args and Returns sections, followed by helpful examples. Every sentence earns its place by adding specific value - no redundant information or unnecessary elaboration.
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 moderate complexity, rich annotations, and 100% schema coverage, the description is quite complete. It covers purpose, usage context, return format, and provides examples. The main gap is the lack of output schema, but the description compensates well by specifying what gets returned. It could be slightly more complete by mentioning limitations or edge cases.
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 100% schema description coverage, the baseline is 3. The description adds minimal parameter semantics beyond what's in the schema - it provides examples of query types (skill name, mechanic, item, monster) which gives context about appropriate query content, but doesn't add significant syntax or format details beyond the schema's 'Search query for the wiki' description.
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's purpose with specific verb ('Search') and resource ('Path of Exile 2 community wiki'), and distinguishes it from siblings by specifying it searches for 'game mechanics, items, skills, and other information' rather than currency, prices, builds, or specific pages. This makes it immediately clear what this tool does differently from poe2_wiki_page.
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 provides clear context about when to use this tool (searching the wiki for various game elements), but doesn't explicitly state when NOT to use it or name specific alternatives. The examples help illustrate appropriate use cases, but there's no explicit guidance about choosing between this and poe2_wiki_page or other search-related tools.
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.
v1.0.0poe2_currency_checkpoe2_currency_pricespoe2_db_lookuppoe2_exchange_toppoe2_item_pricepoe2_meta_buildspoe2_wiki_pagepoe2_wiki_searchMost tools have distinct purposes, but there is some overlap between poe2_currency_check and poe2_item_price, as both can look up currency prices with similar arguments. Additionally, poe2_currency_prices and poe2_exchange_top both provide currency-related data, which could cause confusion. However, descriptions help clarify their specific functions, preventing major misselection issues.
All tool names follow a consistent snake_case pattern with the prefix 'poe2_' followed by a descriptive verb_noun combination (e.g., currency_check, wiki_search). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style.
With 8 tools, the server is well-scoped for providing Path of Exile 2 game data, covering currency, items, builds, and wiki information. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain and typical use cases.
The tool set covers key aspects of Path of Exile 2 data retrieval, including currency, item prices, game data, meta builds, and wiki access. Minor gaps exist, such as lack of tools for player-specific data or trade listings, but core workflows are well-supported, and agents can effectively use the provided tools for common queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sergeyklay/poe2-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
