poe2-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![poe2-mcp-server MCP server](https://glama.ai/mcp/servers/sergeyklay/poe2-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/sergeyklay/poe2-mcp-server)

Score Badge

Copy to your README.md:

[![poe2-mcp-server MCP server](https://glama.ai/mcp/servers/sergeyklay/poe2-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/sergeyklay/poe2-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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