ExileAPI Plugin Dev MCP

by YunaAUbot

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources and actions, but some pairs like read_game_snapshot vs read_game_snapshot_path or prepare_game_snapshot_capture vs prepare_game_snapshot_path_profile require careful reading of descriptions to avoid misselection. Overall, the boundaries are clear enough for an agent.
Naming Consistency4/5
All tool names follow a verb_noun snake_case pattern, which is consistent in style. However, the verb set is varied (prepare, list, inspect, read, save, refine, find, discover, scaffold), and some verbs like 'prepare' and 'read' repeat across multiple tools, introducing minor ambiguity.
Tool Count4/5
With 19 tools, the server is on the heavier side but still within a reasonable range for a complex domain like ExileAPI plugin development, which involves snapshots, builds, and profiles. The count is not excessive given the breadth of features.
Completeness4/5
The tool set covers core workflows: environment discovery, scaffolding, build/reload status, snapshot inspection (both game and core), path profiles, and example lookup. Minor gaps exist, such as no delete operation for saved path profiles, but the surface is largely complete for read-oriented development support.
Average 3.4/5 across 19 of 19 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool reports information, which implies a read-only, non-destructive operation. However, it does not disclose any potential side effects, access requirements, or whether the tool modifies state. The word 'Report' provides a baseline safety signal but lacks depth.
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 a single, concise sentence that front-loads the action ('Report') and specifies the subject. It contains no filler or redundant information, making it appropriately sized for a tool with a simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, return values need not be described, but the description still leaves gaps. It does not explain the meaning of 'ExileAPI references' or 'source-plugin link', nor does it clarify the role of exileapi_root. For a tool with one parameter and no annotations, the description is too sparse to be fully actionable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter (exileapi_root) with 0% description coverage, and the tool description does not mention this parameter at all. The description fails to explain what exileapi_root is, how it affects the report, or why a user might set it. With no schema descriptions and no compensation from the description, this dimension is severely lacking.
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 clearly states the tool's purpose: it reports local ExileAPI references and the source-plugin link for Build/Reload. The verb 'Report' and the specific resources ('local ExileAPI references', 'source-plugin link') make the function clear, though it doesn't explicitly differentiate from sibling tools like prepare_reload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description implies it's for environment discovery before Build/Reload, but there is no explicit mention of prerequisites, alternatives, or exclusions. Sibling tools like prepare_reload are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'read-only' which implies no mutation, and 'manually captured' hints at a precondition, but it does not explain error behavior, output format, or any side effects. This is minimal compared to what a read tool with no annotations should disclose.
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 a single, concise sentence with no filler or repetition. It clearly states the action and object, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters, no annotations, and many sibling tools, the description is too sparse to be complete. It omits usage scenarios, parameter details, and behavioral expectations, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially explains the 'section' parameter via 'or one shortcut section', but it never mentions 'max_characters' or clarifies the default behavior. Since the schema has no parameter descriptions (0% coverage), the description should compensate, and it fails to fully do so.
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 clearly states the tool reads a manually captured, read-only ExileAPI game snapshot or a shortcut section. It identifies the specific resource and operation, distinguishing it from sibling tools like inspect_game_snapshot or read_game_snapshot_path by emphasizing 'manually captured' and 'read-only', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus the many snapshot-related siblings. It lacks context such as prerequisites, typical use cases, or exclusions, leaving the agent without direction to select it appropriately.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool may 'build' or 'read' an index, hinting at possible side effects (writing/building), and that the table is 'bounded', implying a limit. However, it does not clarify what 'header-only' means, whether building is a persistent side effect, or any permissions needed. This adds some transparency but leaves significant gaps.
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 a single concise sentence with no filler. It front-loads the key action and resource. However, it is so terse that it omits important clarifications, so while it is appropriately brief, it sacrifices clarity at the edges.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema description coverage, and no annotations, the description is not sufficient. It does not explain what 'header-only' implies, how the index is built or read, the semantics of each filter, or how it relates to the many sibling snapshot tools. The existence of an output schema reduces the need to describe return format, but the missing input semantics and side-effect disclosure make this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'matching archive paths' and 'bounded table', which vaguely relate to query, path_prefix, and limit, but it does not explicitly explain each parameter. For example, it's unclear whether 'query' is a substring search, whether path_prefix filters by directory, or how limit bounds the result. The description adds minimal meaning beyond the raw schema field names.
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 specifies a concrete resource ('header-only snapshot index') and action ('Build/read', 'return a bounded table of matching archive paths'). It distinguishes from siblings like read_game_snapshot by focusing on the index and paths, not full snapshot content. The dual verb 'Build/read' is slightly ambiguous but still conveys the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. Sibling tools like find_core_snapshot_paths, read_core_snapshot_member, and list_core_snapshots overlap, but the description gives no explicit when-to-use or when-not-to-use advice. The phrase 'header-only snapshot index' implies a specialized role, but it's not articulated as a decision guide.
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?
With no annotations, the description carries the burden. It discloses a key behavioral trait: the user must still press Capture snapshot in-game, indicating this tool does not perform the capture. However, it does not explain side effects, prerequisites, or other operational details.
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 a single, front-loaded sentence that efficiently conveys the core action and the critical user-step caveat. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and a rich set of sibling tools, the description is incomplete. It does not explain parameter meaning, when to use it, or what the preparation entails. The output schema exists, so return values are covered, but other key context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the three parameters (profile, conditions, custom_sections). The tool description does not compensate for the missing schema documentation, leaving parameter semantics entirely undefined.
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 clearly states a specific action ('Prepare') and resource ('bounded bridge capture profile'), and notes the follow-up in-game action. It distinguishes itself from sibling tools that handle actual capture or path profiles, though 'bounded bridge' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like prepare_reload, prepare_game_snapshot_path_profile, or refine_game_snapshot_capture. It implies it's a preparation step but does not state conditions for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply states a save action without disclosing side effects, such as whether it overwrites existing profiles, validates paths, or requires prior snapshot capture. Since annotations are absent, this leaves behavioral uncertainty.
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?
A single, grammatically complete sentence that is efficiently worded. However, it omits critical operational details, making it more under-specification than ideal conciseness, but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and a vague schema, the description fails to cover usage context, parameter roles, or operational prerequisites. The presence of an output schema does not compensate for the lack of behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'name' or 'paths' parameters. It mentions 'safe target paths' conceptually but not how the parameters map to the profile creation.
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 uses a specific verb ('Save') and resource ('safe target paths from the latest snapshot' as a 'reusable profile for the current ExileCore build'), clearly distinguishing it from sibling tools like listing or inspecting profiles. It is unambiguous about what the tool does.
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?
No explicit guidance on when to use this tool vs alternatives is provided. The phrase 'from the latest snapshot' implies a sequence (after capturing a snapshot), but it doesn't mention related tools such as prepare_game_snapshot_path_profile or list_game_snapshot_path_profiles.
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?
The description discloses that results are bounded and include truncation markers, adding behavioral context beyond the schema. However, with no annotations, it does not explicitly state read-only status, side effects, or the meaning of the query parameter. The verb 'Return' weakly implies read-only.
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 a single, front-loaded sentence with no filler. It efficiently communicates the core action and output contents.
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?
The tool has an output schema, so the return structure is likely defined elsewhere, and the description lists the main columns. However, the absence of parameter semantics and usage guidance leaves notable gaps, particularly around the 'query' parameter, making the description only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. The phrase 'bounded table' only hints at max_entries limiting size, but the 'query' parameter is completely unexplained. The description fails to compensate for the lack of schema documentation.
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 uses a specific verb ('Return') and a clear resource ('bridge snapshot paths, types, list sizes, and truncation markers'), and the phrase 'bounded table' hints at a distinctive behavior. However, it does not explicitly differentiate from sibling tools like list_game_snapshot_path_profiles or read_game_snapshot.
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 this tool is for browsing or inspecting a collection of snapshot paths with metadata, especially when results may need bounding. It does not explicitly state when to use this tool versus alternatives or any exclusions.
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?
Without annotations, the description carries the burden. It discloses that only 'successful' paths are listed and that they are 'remembered locally,' which implies persistence and filtering. However, it does not explain the effect of the query parameter or any other behavioral details like sorting or error handling.
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?
A single sentence, directly front-loaded with the action and scope. No wasted words.
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?
While the description captures the core scope (local, successful, current build), it omits the query parameter behavior and lacks any sibling differentiation. Given the existence of an output schema, return values are not needed, but the lack of parameter guidance and usage context leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'query' with no description (0% schema coverage), and the description does not mention it. The agent is left without any clue about how to use the query parameter, so the description adds no value for parameter semantics.
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 lists 'successful bridge snapshot paths remembered locally for the current ExileCore build,' with a specific verb and resource. It implicitly differentiates from sibling list_game_snapshot_path_profiles by focusing on paths rather than profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus the many sibling tools such as list_game_snapshot_path_profiles, read_game_snapshot_path, or inspect_game_snapshot. There are no usage conditions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'safe' and 'remember it', which hint at validation and a side effect, but does not explain what 'safe' means, what 'remember' entails, or whether the operation is read-only. There is no disclosure of error behavior, permissions, or state changes beyond the vague 'remember' note.
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 a single, front-loaded sentence of 18 words. It states the core action first and wastes no words. Every phrase contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential context: it does not explain what a 'bridge snapshot' is, what 'safe dot path' means, why the path is remembered, or how this tool fits with the many siblings. The default max_characters parameter is also unexplained, leaving the agent underinformed for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not compensate. 'dot path' hints at the 'path' parameter, but 'max_characters' is completely ignored, and the description adds no details about parameter formats, limits, or interactions. With 0% schema coverage, the description fails to clarify the parameters.
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 specifies a clear action ('Read'), a precise subject ('one exact, safe dot path from the latest bridge snapshot'), and an additional behavior ('remember it for this ExileAPI version'). It distinguishes from sibling 'read_game_snapshot' by focusing on a single path rather than the full snapshot.
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 'one exact, safe dot path' wording implies this tool is for targeted reads, but it does not explicitly say when to prefer it over siblings like read_game_snapshot or list_known_game_snapshot_paths, nor does it mention any exclusions or prerequisites. Usage context is present but only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not reveal whether the tool mutates state, requires specific conditions (e.g., an existing snapshot), or what side effects occur. The phrase 'prepare a follow-up capture' hints at an action, but its effects are opaque. This is a significant transparency gap.
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 a single, concise sentence that clearly states the tool's purpose. It is front-loaded and contains no wasted words. It effectively packs two related actions (finding paths and preparing a capture) into a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for a tool with this level of complexity. It does not explain what 'node-limited paths' means, what the 'latest bridge snapshot' refers to, or how the follow-up capture relates to the overall snapshot workflow. Given the sibling tools, there is implied context, but the description alone leaves significant gaps for an agent to make correct invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, max_targets, with 0% description coverage. The tool description does not mention this parameter at all. While the name 'max_targets' and the phrase 'node-limited paths' loosely imply a limit on the number of targets, the description fails to explicitly define the parameter's meaning, default, or allowed values. With low schema coverage, the description should compensate but does not.
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 a specific action: 'Find node-limited paths in the latest bridge snapshot and prepare a deep, targeted follow-up capture.' It uses a specific verb ('find', 'prepare') and resource ('bridge snapshot', 'follow-up capture'), distinguishing it from sibling tools like prepare_game_snapshot_capture (initial preparation) and inspect_game_snapshot (inspection).
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 a workflow (refine after initial capture) but does not explicitly state when to use this tool versus alternatives. It lacks any mention of exclusions or direct comparison to siblings like prepare_game_snapshot_capture. The usage context is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions searching local files and returning a link, but it does not explain how 'relevant' is determined, whether this is a read-only operation, or any limitations. Lacks detail on side effects or return behavior beyond the basic action.
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 a single sentence that directly communicates the tool's core function with no filler. Every word earns its place, and it is appropriately sized for a simple search-and-return tool.
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?
Given the tool's modest complexity and the presence of an output schema (which likely explains return values), the description is partially complete. However, it lacks guidance on parameter usage and when to choose this tool, making it adequate but with clear gaps in invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly references the 'query' parameter with the word 'relevant', but it does not describe the query parameter explicitly nor the max_results parameter at all. The description adds minimal value beyond the schema's parameter names.
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 a specific verb ('find') and resource ('local ExileAPI C# examples'), and also mentions returning a catalogue link. This distinguishes it from the sibling tools, which focus on snapshots, scaffolding, and runtime status.
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 when you need relevant local examples and a catalogue link, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No alternative tools are named, though the sibling list suggests a clear niche.
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?
No annotations are provided, so the description carries the full burden. It discloses the core matching behavior (all include, none exclude) but does not clarify whether the operation is read-only, what 'indexed' implies (e.g., pre-built index), or any side effects. This is a minimal disclosure for a tool that likely has no side effects.
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 a single, concise sentence that front-loads the action and criteria. There is no redundant or extraneous text, making it immediately scannable for an agent.
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?
Having an output schema covers return structure, but the description leaves gaps about parameter usage (snapshot_name, limit) and lacks guidance on when to use the tool. It provides enough for a straightforward filter operation, but the missing parameter semantics and usage context make it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the semantics of include_terms and exclude_terms ('all include terms and none of the excluded terms'). It does not explain snapshot_name (which snapshot to search) or limit (result cap), nor details like case sensitivity or substring matching. The description partially compensates but leaves significant gaps.
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 uses a specific verb ('Return') and resource ('indexed snapshot paths') with clear filtering criteria ('all include terms and none of the excluded terms'). This distinguishes it from sibling tools like list_core_snapshots or inspect_core_snapshot, which focus on listing or inspecting snapshots rather than matching paths.
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 its usage for locating snapshot paths by term matching, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. There is no reference to sibling tools or when-not scenarios.
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?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool can 'wait for simple bridge conditions' and performs a 'deep targeted capture', but it omits details about side effects, permissions, or what 'prepare' concretely does.
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 a single, concise sentence that front-loads the core action and key qualifiers. Every phrase earns its place with no redundancy or filler.
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?
The tool has an output schema which may explain return values, but the description itself is minimal. It covers the essential action and a notable behavior, yet lacks details on condition semantics, prerequisites, and potential side effects, leaving the overall context incomplete for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'name' to the saved path profile and 'conditions' to bridge conditions, but does not explain the structure or semantics of the condition objects, leaving significant ambiguity.
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 prepares a 'deep targeted capture' from a 'saved path profile', which is a specific verb and resource. It distinguishes from siblings like prepare_game_snapshot_capture by explicitly mentioning the path profile source and the optional bridge condition waiting.
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 the tool is used when you have a saved path profile and want a deep capture, optionally with conditions. However, it provides no explicit guidance on when to use this tool versus alternatives like prepare_game_snapshot_capture.
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?
With no annotations, the description carries the burden. It discloses that reads are bounded (via max_bytes), require an exact indexed regular-file path (not directories or fuzzy paths). However, it does not describe error behavior, what happens if the path is missing, or whether offset is supported. The output schema presumably covers return format, but other behavioral details are absent.
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 a single, tightly packed sentence with no fluff. It front-loads the primary action and then specifies the key constraints, making it immediately understandable.
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 simplicity, the description covers the essential input context: exact path, regular-file constraint, and bounded read. The presence of an output schema reduces the need to describe return values. However, it could benefit from a brief mention of how this relates to sibling tools (e.g., inspect_core_snapshot for metadata) to help with tool selection, so it is not perfect.
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 compensate. It adds meaning by relating 'bounded byte range' to max_bytes, 'path' to an exact indexed regular-file path, and 'ExileAPI snapshot' to snapshot_name. However, it does not explain path format, max_bytes limits, or the fact that max_bytes has a default, leaving gaps in full parameter understanding.
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 clearly states the action (Read), the target (a bounded byte range), and the specific resource (an exact, indexed regular-file path in an ExileAPI snapshot). It differentiates from sibling tools by emphasizing 'core snapshot' and 'regular-file path', though it does not explicitly name alternatives.
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?
Usage is implied: this tool is for reading file content from a core snapshot when you know the exact path and want only a bounded range. But there is no explicit guidance about when to use this versus sibling tools like inspect_core_snapshot or read_game_snapshot, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it creates a local Git repo and symlink, which are meaningful side effects, but it does not mention reversible vs. irreversible changes, path conventions, prerequisites, permissions, or error behavior. This is insufficient for a mutation-style tool.
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 a single declarative sentence with no filler. The action and target are front-loaded, making it instantly parseable.
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?
The presence of an output schema covers return values, and the tool is simple. However, for a scaffold/mutation tool with no annotations, the description still lacks critical behavioral context—side effects, prerequisites, and parameter semantics—making it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain 'plugin_name' or 'description' beyond their self-explanatory names. It adds no guidance on format, uniqueness, or how these parameters relate to the scaffolding operation.
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 uses a specific verb ('Create') and identifies two concrete artifacts ('local Git repository', 'ExileAPI source symlink') plus the target category ('new source-only plugin'). This clearly differentiates it from the sibling read/snapshot tools.
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 phrase 'for a new source-only plugin' gives clear context for when this tool applies. It does not explicitly name alternative tools or exclusion conditions, but the target use case is unambiguous among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Check' which suggests a read-only operation, but it does not disclose side effects, error behavior, or what 'ready' entails. The tool name 'prepare_reload' could imply mutation, but the description clarifies it's a check, yet still lacks explicit behavioral disclosure.
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 a single, clear sentence with no filler. It is front-loaded with the action ('Check') and resource, making it highly concise and well-structured.
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?
The tool is simple with no parameters and likely an output schema, but the description does not elaborate on what 'ready' means or when to invoke this tool relative to other plugin/reload-related tools. It is minimally complete for a no-arg check but leaves the usage context ambiguous.
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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0 params is 4, and the description adds no unnecessary parameter information.
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 states a specific verb ('Check') and a specific resource ('linked ExileAPI source plugin') with a clear condition ('ready for an in-game Build/Reload'). This clearly distinguishes it from sibling tools focused on snapshots, profiles, and captures.
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 before an in-game Build/Reload, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Sibling tools like read_last_build_errors or read_runtime_status could be related, but no cross-references are given.
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?
With no annotations available, the description carries the full burden. It explicitly says 'Read', implying a non-mutating operation, and 'bounded' suggests a line limit. However, it does not disclose what happens when the file has fewer lines, or what the exact output format is, leaving some behavioral ambiguity.
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 a single, front-loaded sentence that conveys the action, resource, and context without any filler or redundancy.
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?
Given the simple one-parameter tool with an output schema, the description provides the basic purpose and use case. However, it omits an explicit explanation of the max_lines parameter and the nature of the 'bounded portion', leaving minor gaps for a new agent.
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?
The schema has 0% description coverage and no parameter descriptions. The description's use of 'bounded portion' hints at the max_lines parameter, but it does not explicitly name it or explain how it affects the result, requiring the agent to infer the connection.
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 'Read' and the resource 'ExileAPI's Errors.txt', with a specific temporal context 'after an in-game build'. This distinguishes it from the snapshot-related sibling tools, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after an in-game build' provides a clear trigger for when to use this tool, which serves as a usage context. However, it does not explicitly mention alternatives or when not to use, so it lacks exclusion phrasing.
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?
No annotations are provided, so the description must carry the transparency burden. It clearly indicates a read-only operation ('List') and scopes to the current build, but does not disclose return format, sorting, or potential edge cases. For a simple list tool, this is adequate but not rich.
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 a single, front-loaded sentence with no wasted words. It states the action, the object, and the scope in a direct manner.
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?
The tool is simple, has zero parameters, and an output schema exists, so the description is nearly complete. It tells the agent what is listed and from where. The only minor gap is not mentioning how profiles relate to sibling tools, but this is not essential for a read-only list operation.
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?
The tool has zero parameters, so the schema coverage is 100% by default. Per rubric, a zero-parameter tool receives a baseline of 4. The description adds context about what is being listed, which is sufficient.
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 uses a specific verb 'List' with a clear resource 'reusable target-path profiles' and scope 'current ExileCore build'. It distinguishes from sibling tools like list_known_game_snapshot_paths by focusing on profiles rather than raw paths.
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 (when you want to see saved profiles) but provides no explicit guidance on when to use this tool versus alternatives such as save_game_snapshot_path_profile or list_known_game_snapshot_paths. No exclusions or alternative recommendations are given.
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?
No annotations are provided, so the description carries the burden. It does disclose the read-only nature and the file's origin, but it doesn't describe edge cases like a missing file or what the status contains. This is adequate but not rich.
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 one concise sentence that delivers the key information without waste.
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 simple parameterless read operation, the description covers the core behavior. An output schema exists to explain the return value, so it doesn't need to detail the status content, but it could mention what happens if the bridge is not enabled.
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?
The tool has zero parameters, and the schema is empty, so there is nothing to explain. The baseline for zero parameters is 4.
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 uses a specific verb ('Read') and identifies a precise resource ('the read-only status file written by the enabled ExileAPI bridge after Build/Reload'). This clearly distinguishes it from sibling tools that read game snapshots or build errors.
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 the tool is for checking status after a Build/Reload, but it doesn't explicitly state when to use this vs alternatives like read_last_build_errors. There is no guidance on exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden. It discloses one key behavioral trait—that listing does not read the files' contents—which is useful. However, it doesn't mention other behavioral aspects like side effects, read-only guarantees, or performance beyond the implicit avoidance of heavy reads.
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 entire description is one concise sentence that is front-loaded with the action and resource, then adds a valuable caveat. Every word earns its place.
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 has no parameters and an output schema is present, the description is complete for this simple list operation. It clearly explains what is listed and the key property of not reading large contents, leaving no significant gaps.
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?
The tool has zero parameters, so the empty schema is complete. Per the guidelines, 0 params receives a baseline of 4; the description has nothing to add on parameter meaning.
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 uses a specific verb ('List') and a clear resource ('ExileAPI's .exapisnap files'), and it adds a distinguishing detail ('without reading their multi-gigabyte contents') that separates it from sibling tools that inspect or read snapshot contents.
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 phrase 'without reading their multi-gigabyte contents' clearly signals this is the lightweight option for enumerating snapshots, providing context on when to choose it over read/inspect tools. It stops short of explicitly naming alternatives or stating when not to use it, so it doesn't reach a 5.
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:

[![ExileApiPluginDev MCP server](https://glama.ai/mcp/servers/YunaAUbot/ExileApiPluginDev/badges/card.svg)](https://glama.ai/mcp/servers/YunaAUbot/ExileApiPluginDev)

Score Badge

Copy to your README.md:

[![ExileApiPluginDev MCP server](https://glama.ai/mcp/servers/YunaAUbot/ExileApiPluginDev/badges/score.svg)](https://glama.ai/mcp/servers/YunaAUbot/ExileApiPluginDev)

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/YunaAUbot/ExileApiPluginDev'

If you have feedback or need assistance with the MCP directory API, please join our Discord server