A
licenseB
qualityA
maintenanceRead-only MCP server for public Guild Wars 1 sources (wiki, builds, YouTube, Reddit) and optional local install inventory.
14
2
MIT
Guild Wars 1 Build Compiler
Server Details
GW1 build compiler: skill data, template code encode/decode, validation, hero roster. Read-only.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Graphmaxer/gw1-mcp
- GitHub Stars
- 1
- Server Listing
- gw1-mcp
Available Tools
8 toolsdecode_pawned_teamDecode a paw-ned2 team templateARead-onlyIdempotentInspect
Decode a paw-ned2 team build blob (the 'pwnd0001...>...<' format shared on PvXwiki team pages and by the paw-ned2 tool) into its individual builds: player/hero label, description, and each skill bar fully decoded. Whitespace and line wraps in the pasted blob are tolerated. For a single (non-team) build code, use decode_template instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pwnd | Yes | The full pwnd blob, starting with 'pwnd000' |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| builds | Yes | One entry per team slot, in blob order |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructive=false, so the safety profile is covered. The description adds behavioral detail beyond annotations by specifying the output decomposition (individual builds with labels, descriptions, fully decoded skill bars) and the whitespace tolerance. There is no contradiction between description and 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 three focused sentences: purpose and output in the first, input tolerance in the second, and alternative routing in the third. Every sentence carries information and is front-loaded with the core definition. No redundant phrasing exists.
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?
For a one-parameter, read-only decode tool with an output schema and safe annotations, the description covers the input format, the output breakdown, whitespace tolerance, and the sibling distinction. The agent has everything needed to invoke it correctly. The output schema and sibling list supply the remaining integration 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?
Schema description coverage is 100% – the schema already explains the 'pwnd' parameter as 'The full pwnd blob, starting with pwnd000'. The description adds context about the source format ('shared on PvXwiki team pages') and whitespace tolerance, but does not significantly expand the parameter's meaning. Per the high-coverage baseline, 3 is appropriate.
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 and resource: 'Decode a paw-ned2 team build blob' and spells out what the output is ('player/hero label, description, and each skill bar fully decoded'). It explicitly differs from the sibling decode_template by naming the non-team case. There is no ambiguity about what this 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('team build blob') and when not to ('For a single (non-team) build code, use decode_template instead'), naming the alternative. It also states that whitespace and line wraps are tolerated, which is practical input guidance. This is clear when-to-use and when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decode_templateDecode a skill template codeARead-onlyIdempotentInspect
Decode an in-game GW1 skill template code (e.g. "OwpiMypMBg1cxcBAMBdmtIKAA") into professions, attribute allocations and the 8 skills with their stats and descriptions. Whitespace and line wraps in the pasted code are tolerated. This decodes a SINGLE build code; for a multi-hero paw-ned2 team blob, use decode_pawned_team instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The template code string |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| raw | Yes | The raw decoded template (ids, not names) |
| skills | Yes | The 8 bar slots in order |
| primary | Yes | Primary profession name |
| secondary | Yes | Secondary profession name, null for none |
| attributes | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needs to add behavioral context beyond that. It adds useful details: the decoded output contents and the single-code scope, and explicitly warns against passing multi-hero team blobs. This goes beyond the annotations without contradicting them.
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?
Three sentences with zero filler: the first states purpose and outputs, the second adds input tolerance, and the third routes to the correct sibling tool. The most important scoping constraint is placed at the end but is clearly emphasized, and every sentence contributes to correct invocation.
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 presence of an output schema, the description does not need to enumerate return fields. It covers the input format, scope limitations, and output categories, and it references the correct alternative tool for the multi-hero case. This is complete for a single-parameter read-only decoding tool.
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 schema already documents the single 'code' parameter at 100% coverage with a basic description, so the baseline is 3. The tool description adds meaningful value by providing a concrete example, explaining that whitespace/line wraps are tolerated, and clarifying that the code must be a SINGLE build code rather than a multi-hero blob. This materially improves parameter understanding.
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 ('Decode'), a specific resource ('in-game GW1 skill template code'), and enumerates the exact outputs: professions, attribute allocations, and the 8 skills with stats and descriptions. It also distinguishes itself from the sibling tool decode_pawned_team by explicitly limiting scope to a SINGLE build code, so an agent can clearly tell which tool to pick.
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 gives explicit when-to-use guidance: use for a single build code, and use decode_pawned_team for a multi-hero pawned-n2 team blob. It also provides a practical input-handling note that whitespace and line wraps are tolerated, which helps the agent pass user pasted code without pre-cleaning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
encode_templateEncode a build into a template codeARead-onlyIdempotentInspect
Compile a build (professions, attributes, 8 skills by exact English name) into an official in-game template code. The build is validated first; on rule violations the errors are returned instead of a code. Unknown skill names return closest-match suggestions. IMPORTANT: template codes MUST come from this tool — never write or guess a code by hand, hand-written codes are invalid in-game. If unsure, verify any code with decode_template.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| forPvp | No | Set true for a PvP character's bar. PvP versions of split skills are only valid when this is true, and a PvP bar is expected to use them. | |
| skills | Yes | Exactly 8 skill names in bar order. Use null for an empty slot. Names must be exact English skill names. | |
| forHero | No | Set true if this bar is for a hero (PvE-only skills are flagged) | |
| primary | Yes | Primary profession, e.g. "Dervish" | |
| secondary | No | Secondary profession, e.g. "Monk". Omit or "None" for none. | |
| attributes | Yes | Attribute point allocations (template format caps this at 15 entries) | |
| unlockedSkillIds | No | Optional: unlocked skill ids from a GWToolbox account export (/exportaccount). Skills outside this list are flagged as warnings. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| code | No | Official in-game template code (present on success) |
| valid | No | false when the build resolved but is illegal; absent on the other two shapes |
| errors | No | Present (non-empty) when resolution failed or the build is invalid |
| warnings | No | Advisories accompanying a successful code |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: the build is validated first and errors are returned on rule violations, unknown skill names produce closest-match suggestions, and hand-written codes are invalid in-game. This significantly enhances understanding of the tool's error handling and constraints.
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 compact and well-structured: a clear opening sentence defining the core function, a sentence on validation/error behavior, and an IMPORTANT callout about hand-written codes. Every sentence contributes essential information without redundancy.
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 (7 parameters, output schema present), the description covers the essential behavior: input composition, validation, error handling, and relationship to decode_template. It does not need to explain return values since an output schema exists, and it adequately orients the agent on when and how to use the tool.
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 input schema has 100% parameter description coverage, so the baseline is 3. The description reinforces that skills must be exact English names and mentions 'professions, attributes, 8 skills' but adds little beyond the schema's own descriptions. It does not explain parameter formats or constraints beyond what schema already states.
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 function: 'Compile a build (professions, attributes, 8 skills by exact English name) into an official in-game template code.' It uses a specific verb ('compile'), identifies the resource ('template code'), and lists the key inputs. This distinguishes it from sibling tools like decode_template, which is explicitly mentioned as the verification counterpart.
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 usage guidance: template codes MUST come from this tool, never hand-write or guess codes, and if unsure, verify with decode_template. This establishes clear when-to-use and when-not-to-use scenarios, and names the alternative tool for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_heroGet a Guild Wars 1 heroARead-onlyIdempotentInspect
Look up a GW1 hero by name or by id (GWCA HeroID, matching the AccountExport plugin output). Returns profession, campaign and how the hero is unlocked. Remember: heroes can equip any skill unlocked at ACCOUNT level, but NO PvE-only skill at all — including Signet of Capture. validate_build with forHero=true reports each one as an error, not a warning. Use this for one known hero; to browse or filter the roster, use list_heroes instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | GWCA HeroID value | |
| name | No | Hero name, e.g. "Master of Whispers" |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | GWCA HeroID |
| name | Yes | |
| unlock | Yes | How the hero is recruited |
| campaign | Yes | |
| campaignId | Yes | |
| profession | Yes | |
| professionId | Yes |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable behavioral context: hero skill restrictions at account level, the PvE-only skill prohibition including Signet of Capture, and how validate_build reports violations. This goes beyond the annotation baseline and is directly useful for downstream build validation.
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?
Four sentences, each with a distinct job: core lookup, return summary, important domain caveat, and sibling routing. The description is front-loaded with the primary action and avoids redundancy with the schema or annotations.
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?
For a read-only lookup tool with optional parameters, an output schema, and a clear sibling alternative, this description covers everything needed to select and invoke the tool correctly. It explains the identifier source, what data is returned, a critical hero-skill rule, and when to use list_heroes instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented, so the baseline is 3. The description adds extra meaning by clarifying that the id is a GWCA HeroID matching AccountExport plugin output, which helps an agent supply the correct value. It also reinforces the name-or-id duality, though the schema already captures this.
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 and resource: 'Look up a GW1 hero by name or by id.' It also names the distinct identifier format (GWCA HeroID) and explicitly differentiates itself from list_heroes, so an agent can distinguish this tool from its siblings without opening schemas.
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?
Provides explicit routing guidance: 'Use this for one known hero; to browse or filter the roster, use list_heroes instead.' It also warns about validate_build behavior with forHero=true, giving clear context for when this lookup result matters downstream.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillGet a Guild Wars 1 skillARead-onlyIdempotentInspect
Look up a single GW1 skill by exact English name or by template skill id. Returns full stats (energy, activation, recharge, adrenaline, sacrifice), profession, attribute, campaign, elite flag and description. If the name is not found, returns the closest matches so you can correct spelling. Use this when you already know the exact skill; to discover skills by profession, attribute or name fragment, use search_skills instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Template skill id | |
| name | No | Exact skill name, e.g. "Mystic Regeneration". The official French name also resolves ("Sceau de guérison" -> Healing Signet); every other name field on every other tool is English-only. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| type | Yes | Skill type, e.g. Enchantment Spell |
| elite | Yes | |
| energy | Yes | |
| upkeep | Yes | |
| campaign | Yes | |
| overcast | Yes | |
| recharge | Yes | |
| attribute | Yes | |
| sacrifice | Yes | |
| activation | Yes | |
| adrenaline | Yes | |
| isRoleplay | Yes | PvE-only skill: max 3 per player bar, none on heroes |
| profession | Yes | |
| description | Yes | |
| isPvpVersion | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the bar for additional disclosure is lower. The description adds meaningful behavior: it returns full stats and, on no exact match, returns closest matching names. This clarifies failure behavior beyond what the annotations express.
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 compact, logically ordered, and front-loaded with the core action before the return-value and fallback details. Every sentence earns its place, and the sibling-tool pointer is included without bloat.
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?
For a simple read-only lookup tool, the description plus schema and annotations cover purpose, parameter semantics, return contents, failure behavior, and the alternative tool. There is no material gap an agent would need to fill by trial and error.
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 input schema already documents both parameters thoroughly with 100% coverage, so the baseline is 3. The description reinforces the id/name lookup modes but does not add substantial semantic detail beyond the schema, nor does it clarify precedence if both are supplied. It is adequate, not rich.
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 says exactly what the tool does: look up a single GW1 skill by exact English name or template skill id. It lists the fields returned and explicitly contrasts itself with search_skills, making its scope and differences from siblings clear.
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 gives explicit guidance: use this tool when you already know the exact skill, and use search_skills when discovering skills by profession, attribute, or name fragment. It also explains the nearest-match fallback for misspellings, which helps an agent decide whether this tool will still be useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_heroesList Guild Wars 1 heroesARead-onlyIdempotentInspect
List all GW1 heroes, optionally filtered by profession or campaign name. Useful for team-building: shows which professions are coverable by heroes and how each hero is unlocked.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| campaignName | No | Filter by the campaign the hero is recruited in, exact English name: Prophecies, Factions, Nightfall or Eye of the North. | |
| professionName | No | Filter by the hero's profession, exact English name: Warrior, Ranger, Monk, Necromancer, Mesmer, Elementalist, Assassin, Ritualist, Paragon or Dervish. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| heroes | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so safety behavior is established. The description adds useful behavioral context beyond annotations by noting that results show profession coverability and hero unlock methods, which informs the agent about the nature of the returned information.
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 two sentences with no filler. It front-loads the core action and filters, then adds a concise purpose statement. Every sentence contributes useful information.
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?
With full parameter documentation, a rich output schema, and annotations covering the read-only/idempotent behavior, the description covers what the tool does and why it is useful. Nothing critical is missing for correct invocation.
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 both parameters fully documented and exact allowed values listed. The description only restates that optional filtering by profession or campaign is available, adding no significant semantic detail beyond the schema.
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 opens with a specific verb and resource: 'List all GW1 heroes', which clearly identifies the tool's function. It also differentiates from siblings like get_hero (single hero retrieval) and skill-focused tools by emphasizing hero listing with optional filters.
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 states the tool is useful for team-building and explains that it reveals profession coverage and hero unlock status, which implies an appropriate use case. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to decide when this listing tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_skillsSearch Guild Wars 1 skillsARead-onlyIdempotentInspect
Search the full GW1 skill database by profession, attribute, campaign, elite flag or name fragment (valid values are documented per parameter). Returns compact records, at most limit of them alongside a total count of every match — a full page is not the whole result, page with offset. Use get_skill for full details.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| elite | No | If true, return only elite skills; if false, only non-elite; omit for both. | |
| limit | No | Maximum number of records to return (1–200, default 50). Narrow filters if you hit it. | |
| offset | No | Number of records to skip, for paging through results beyond the limit. | |
| campaignName | No | Filter by the campaign a skill was INTRODUCED in: Core, Prophecies, Factions, Nightfall, or Eye of the North. Not a filter on availability — every attribute line spans several campaigns, so combining this with attributeName hides most of the line. Omit it when exploring an attribute. | |
| nameContains | No | Case-insensitive substring match on the ENGLISH skill name, e.g. "heal" matches every skill with 'heal' in its name. A French substring matches nothing — use get_skill for a French name. | |
| attributeName | No | Filter by attribute line, exact English name, e.g. "Blood Magic", "Swordsmanship", "Divine Favor". | |
| professionName | No | Filter by profession: Warrior, Ranger, Monk, Necromancer, Mesmer, Elementalist, Assassin, Ritualist, Paragon, Dervish, or None (common / PvE-only skills that belong to no profession). | |
| includePvpVersions | No | Include separate '(PvP)' skill versions. Default false — most builds want the PvE version only. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total matches before limit/offset are applied |
| skills | Yes | Compact records; use get_skill for full details |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context on top: it returns 'compact records', enforces an upper bound via 'limit', and provides a 'total' count to signal that pagination is needed. This goes beyond the annotations without contradicting them.
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?
Three sentences carry substantial information: search scope, result shape, pagination caveat, and the sibling alternative. The most important facts are front-loaded and there is no filler or redundancy.
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?
With a detailed input schema and an output schema present, the description covers what an agent needs: what is searched, what is returned, how to page, and when to switch to get_skill. Nothing essential is missing for correct invocation.
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 rich per-parameter details (valid values, defaults, range, examples, guidance). The tool description adds very little beyond pointing to the schema ('valid values are documented per parameter') and summarizing filter dimensions. This matches the baseline for 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 opens with a specific verb ('Search'), names the exact resource ('full GW1 skill database'), and enumerates the filter dimensions (profession, attribute, campaign, elite flag, name fragment). It also explicitly distinguishes itself from get_skill by noting that full details belong to that sibling tool.
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 states when to use an alternative ('Use get_skill for full details') and gives concrete paging guidance ('a full page is not the whole result, page with offset'). Schema-level descriptions further add context like 'Narrow filters if you hit it' and 'Omit it when exploring an attribute', making usage conditions very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_buildValidate a build against GW1 rulesARead-onlyIdempotentInspect
Check a build (professions, attributes, 8 skills by exact English name) against Guild Wars 1 rules: one elite max, profession/attribute ownership, primary attributes, duplicates, rank ranges. Returns { valid, errors, warnings } without encoding — use encode_template instead when you also want the template code, since it runs these same rules and refuses on any error.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| forPvp | No | Set true for a PvP character's bar (PvP versions of split skills are only valid then). | |
| skills | Yes | Exactly 8 skill names in bar order. Use null for an empty slot. Names must be exact English skill names. | |
| forHero | No | Set true if this bar is for a hero (PvE-only skills are flagged) | |
| primary | Yes | Primary profession, e.g. "Dervish" | |
| secondary | No | Secondary profession, e.g. "Monk". Omit or "None" for none. | |
| attributes | Yes | Attribute point allocations (template format caps this at 15 entries) | |
| unlockedSkillIds | No | Optional: unlocked skill ids from a GWToolbox account export (/exportaccount). Skills outside this list are flagged as warnings. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | Whether the build is legal in-game |
| errors | Yes | Blocking problems; empty when valid |
| warnings | Yes | Non-blocking advisories |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, and the description adds useful behavioral context: it returns {valid, errors, warnings} and does not encode. It also implies a non-refusing behavior versus encode_template. No contradiction with 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?
Two sentences, front-loaded with the core function, and no wasted words. The second sentence concisely provides the return shape and directs to an alternative tool.
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?
The description covers the validation rules, return structure, and the relationship to a sibling tool. With rich schema and output schema present, nothing critical is missing for an agent to decide and invoke correctly.
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 explains each parameter thoroughly (e.g., exact English names, null for empty slot, rank 0-12). The description adds no new parameter detail beyond naming build components, so baseline 3 applies.
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 opens with a specific verb 'Check' and identifies the exact resource (build against GW1 rules), listing the validation categories. It explicitly distinguishes from the sibling encode_template, making the tool's purpose unmistakable.
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 gives explicit when-to-use ('without encoding') and when-not-to-use guidance by directing to encode_template for template-code needs, noting that encode_template runs the same rules and refuses on errors. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
- Changed
decode_pawned_team6 fields changed- removed
Output schema / properties / builds / items / properties / equipmentCode / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / builds / items / properties / equipmentCode / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / builds / items / properties / inGamePlayerName / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / builds / items / properties / inGamePlayerName / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / builds / items / properties / notes / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / builds / items / properties / notes / typeAdded value: +[ + "string", + "null" +]
- Changed
decode_template6 fields changed- removed
Output schema / properties / secondary / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / secondary / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / skills / items / properties / attribute / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / skills / items / properties / attribute / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / skills / items / properties / name / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / skills / items / properties / name / typeAdded value: +[ + "string", + "null" +]
- Changed
get_hero4 fields changed- removed
Output schema / properties / campaign / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / campaign / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / profession / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / profession / typeAdded value: +[ + "string", + "null" +]
- Changed
get_skill9 fields changed- changed
Input schema / properties / name / descriptionPrevious value: -"Exact English skill name, e.g. \"Mystic Regeneration\""New value: +"Exact skill name, e.g. \"Mystic Regeneration\". The official French name also resolves (\"Sceau de guérison\" -> Healing Signet); every other name field on every other tool is English-only." - removed
Output schema / properties / attribute / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / attribute / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / campaign / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / campaign / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / profession / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / profession / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / type / typeAdded value: +[ + "string", + "null" +]
- Changed
list_heroes4 fields changed- removed
Output schema / properties / heroes / items / properties / campaign / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / heroes / items / properties / campaign / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / heroes / items / properties / profession / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / heroes / items / properties / profession / typeAdded value: +[ + "string", + "null" +]
- Changed
search_skills7 fields changed- changed
Input schema / properties / nameContains / descriptionPrevious value: -"Case-insensitive substring match on the skill name, e.g. \"heal\" matches every skill with 'heal' in its name."New value: +"Case-insensitive substring match on the ENGLISH skill name, e.g. \"heal\" matches every skill with 'heal' in its name. A French substring matches nothing — use get_skill for a French name." - removed
Output schema / properties / skills / items / properties / attribute / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / skills / items / properties / attribute / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / skills / items / properties / campaign / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / skills / items / properties / campaign / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / skills / items / properties / profession / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / skills / items / properties / profession / typeAdded value: +[ + "string", + "null" +]
8 tool updates
- Changed
decode_pawned_team1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
decode_template1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
encode_template1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
get_hero1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
get_skill1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
list_heroes1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
search_skills2 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / campaignName / descriptionPrevious value: -"Filter by campaign: Core, Prophecies, Factions, Nightfall, or Eye of the North."New value: +"Filter by the campaign a skill was INTRODUCED in: Core, Prophecies, Factions, Nightfall, or Eye of the North. Not a filter on availability — every attribute line spans several campaigns, so combining this with attributeName hides most of the line. Omit it when exploring an attribute."
- Changed
validate_build1 field changed- added
Input schema / additionalPropertiesAdded value: +false
1 tool update
- Changed
decode_pawned_team1 field changed- changed
Input schema / properties / pwnd / maxLengthPrevious value: -262144New value: +16384
2 tool updates
- Changed
list_heroes2 fields changed- added
Input schema / properties / campaignName / descriptionAdded value: +"Filter by the campaign the hero is recruited in, exact English name: Prophecies, Factions, Nightfall or Eye of the North." - added
Input schema / properties / professionName / descriptionAdded value: +"Filter by the hero's profession, exact English name: Warrior, Ranger, Monk, Necromancer, Mesmer, Elementalist, Assassin, Ritualist, Paragon or Dervish."
- Changed
validate_build1 field changed- added
Input schema / properties / forHero / descriptionAdded value: +"Set true if this bar is for a hero (PvE-only skills are flagged)"
3 tool updates
- Changed
decode_pawned_team8 fields changed- changed
Output schema / properties / builds / items / properties / build / additionalPropertiesPrevious value: -falseNew value: +{} - changed
Output schema / properties / builds / items / properties / build / descriptionPrevious value: -"Decoded bar (absent if decoding failed)"New value: +"Decoded bar (absent if decoding failed). Same shape as decode_template's output." - removed
Output schema / properties / builds / items / properties / build / properties / attributesRemoved value: -{ - "items": { - "additionalProperties": false, - "properties": { - "attribute": { - "type": "string" - }, - "rank": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - } - }, - "required": [ - "attribute", - "rank" - ], - "type": "object" - }, - "type": "array" -} - removed
Output schema / properties / builds / items / properties / build / properties / primaryRemoved value: -{ - "description": "Primary profession name", - "type": "string" -} - removed
Output schema / properties / builds / items / properties / build / properties / rawRemoved value: -{ - "description": "The raw decoded template (ids, not names)" -} - removed
Output schema / properties / builds / items / properties / build / properties / secondaryRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Secondary profession name, null for none" -} - removed
Output schema / properties / builds / items / properties / build / properties / skillsRemoved value: -{ - "description": "The 8 bar slots in order", - "items": { - "additionalProperties": false, - "properties": { - "activation": { - "type": "number" - }, - "adrenaline": { - "type": "number" - }, - "attribute": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "description": { - "type": "string" - }, - "elite": { - "type": "boolean" - }, - "energy": { - "type": "number" - }, - "isRoleplay": { - "description": "PvE-only skill: max 3 per player bar, none on heroes", - "type": "boolean" - }, - "name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "null for an empty bar slot" - }, - "recharge": { - "type": "number" - }, - "sacrifice": { - "type": "number" - }, - "slot": { - "description": "Bar position 1-8", - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - } - }, - "required": [ - "slot", - "name" - ], - "type": "object" - }, - "type": "array" -} - removed
Output schema / properties / builds / items / properties / build / requiredRemoved value: -[ - "primary", - "secondary", - "attributes", - "skills", - "raw" -]
- Changed
encode_template1 field changed- added
Input schema / properties / forPvpAdded value: +{ + "default": false, + "description": "Set true for a PvP character's bar. PvP versions of split skills are only valid when this is true, and a PvP bar is expected to use them.", + "type": "boolean" +}
- Changed
validate_build1 field changed- added
Input schema / properties / forPvpAdded value: +{ + "default": false, + "description": "Set true for a PvP character's bar (PvP versions of split skills are only valid then).", + "type": "boolean" +}
1 tool update
- Changed
list_heroes2 fields changed- added
Input schema / properties / campaignName / maxLengthAdded value: +64 - added
Input schema / properties / professionName / maxLengthAdded value: +64
2 tool updates
- Changed
encode_template6 fields changed- changed
Input schema / properties / attributes / descriptionPrevious value: -"Attribute point allocations"New value: +"Attribute point allocations (template format caps this at 15 entries)" - added
Input schema / properties / attributes / maxItemsAdded value: +15 - changed
Output schema / properties / errors / descriptionPrevious value: -"Present (non-empty) only when resolution failed; mutually exclusive with code"New value: +"Present (non-empty) when resolution failed or the build is invalid" - added
Output schema / properties / errors / items / properties / suggestionsAdded value: +{ + "description": "Closest-match names, on resolution errors", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / validAdded value: +{ + "description": "false when the build resolved but is illegal; absent on the other two shapes", + "type": "boolean" +} - added
Output schema / properties / warnings / items / properties / suggestionsAdded value: +{ + "description": "Closest-match names, on resolution errors", + "items": { + "type": "string" + }, + "type": "array" +}
- Changed
validate_build4 fields changed- changed
Input schema / properties / attributes / descriptionPrevious value: -"Attribute point allocations"New value: +"Attribute point allocations (template format caps this at 15 entries)" - added
Input schema / properties / attributes / maxItemsAdded value: +15 - added
Output schema / properties / errors / items / properties / suggestionsAdded value: +{ + "description": "Closest-match names, on resolution errors", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / warnings / items / properties / suggestionsAdded value: +{ + "description": "Closest-match names, on resolution errors", + "items": { + "type": "string" + }, + "type": "array" +}
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Guild Wars 2 keyless public endpoints (worlds, items, achievements, build, commerce).
Bungie.net Destiny 2 + clan API: manifest, profile, characters, stats.
Read-only Interlude and High Five NPC, loot, Soul Crystal and XP reference tools.
- F1LapsOAuthcom.f1laps
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides read-only access to OSRS Calc's skill calculators, training plans, FAQ, and official links for Old School RuneScape planning.2MIT
- FlicenseCqualityBmaintenanceEnables accurate Castle Clash queries by computing hero stats, skill damage, combat math, builds, and fight simulations from real game data and engine formulas instead of model guesses.47-
- AlicenseNot gradedqualityCmaintenanceEnables querying Guild Wars 2 game data including items and achievements via natural language, part of the Pipeworx MCP gateway.9MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.6/5.0
Disambiguation5/5
Each tool targets a distinct operation: decoding team blobs vs. single templates vs. encoding; looking up a single hero vs. listing heroes; exact skill lookup vs. searching. Cross-references between similar tools (e.g., decode_pawned_team vs. decode_template) make boundaries clear.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: decode_*, encode_template, get_*, list_heroes, search_skills, validate_build. No mixed conventions or vague verbs.
Tool Count5/5
Eight tools is well-scoped for a build compiler: decoding/encoding, validation, and lookup utilities for skills and heroes. Each tool earns its place without redundancy or bloat.
Completeness4/5
The core lifecycle is covered: decode single/team, encode single template, validate, plus skill/hero discovery. A notable gap is the lack of a tool to encode a full team blob (paw-ned2 format), which would be the natural counterpart to decode_pawned_team, but agents can work around this by encoding individual templates.