Skip to main content
Glama

Guild Wars 1 Build Compiler

by io.github.Graphmaxer

Search Guild Wars 1 skills

search_skills
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eliteNoIf true, return only elite skills; if false, only non-elite; omit for both.
limitNoMaximum number of records to return (1–200, default 50). Narrow filters if you hit it.
offsetNoNumber of records to skip, for paging through results beyond the limit.
campaignNameNoFilter 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.
nameContainsNoCase-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.
attributeNameNoFilter by attribute line, exact English name, e.g. "Blood Magic", "Swordsmanship", "Divine Favor".
professionNameNoFilter by profession: Warrior, Ranger, Monk, Necromancer, Mesmer, Elementalist, Assassin, Ritualist, Paragon, Dervish, or None (common / PvE-only skills that belong to no profession).
includePvpVersionsNoInclude separate '(PvP)' skill versions. Default false — most builds want the PvE version only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalYesTotal matches before limit/offset are applied
skillsYesCompact 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.

All Guild Wars 1 Build Compiler toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources