Guild Wars 1 Build Compiler

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral details: tolerance for whitespace and line wraps, and a clear account of what the decoded output contains. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: main purpose with format and output, whitespace tolerance, and the alternative-tool pointer. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a clear input description, explicit output breakdown, whitespace tolerance, and a named alternative for single builds, the description is fully complete for practical use. The presence of an output schema means return-value details need not be repeated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents pwnd with a starting-prefix requirement and max length, providing 100% coverage. The description adds contextual meaning by giving the format example 'pwnd0001...>...<' and clarifying it is a team build blob, plus the whitespace-tolerance caveat—valuable beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Decode a paw-ned2 team build blob') and the resource/format, then specifies the output ('individual builds: player/hero label, description, and each skill bar fully decoded'). It explicitly distinguishes from the sibling tool decode_template, so there is no ambiguity about scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit usage boundary: 'For a single (non-team) build code, use decode_template instead.' It also explains where these blobs are found (PvXwiki team pages, paw-ned2 tool), making it clear when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds behavior context by specifying the output content (professions, attribute allocations, 8 skills with stats/descriptions) and the limitation to single codes. It does not repeat the annotations and is consistent with them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with no wasted words. The first sentence front-loads the core function and output, the second provides a clear usage distinction and sibling pointer. The example is valuable and compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter), the schema fully documents the parameter, output schema exists, and annotations cover safety. The description covers the purpose, the input format example, and the single-code scope. With output schema present, the description does not need to explain return values, making this sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for the single 'code' parameter (string, maxLength), so the baseline is 3. The description adds meaningful context by providing a concrete example ('OwpiMypMBg1cxcBAMBdmtIKAA'), clarifying it's an in-game GW1 skill template code, and emphasizing it's a single build code. This goes beyond the schema's generic 'string' description, so a 4 is justified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool decodes an in-game GW1 skill template code into professions, attribute allocations, and 8 skills with stats/descriptions. It explicitly distinguishes from decode_pawned_team by noting this handles a SINGLE build code, which differentiates it from siblings like decode_pawned_team. The verb 'decode' is specific and the resource is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says this decodes a SINGLE build code, and for a multi-hero team blob, use decode_pawned_team instead. This provides clear when-to-use and when-not-to-use guidance with a named alternative. No other sibling tools compete for this exact job.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with readOnlyHint, idempotentHint, and destructiveHint annotations, the description adds valuable behavioral detail: validation before encoding, returning errors on rule violations, and returning closest-match suggestions for unknown skill names. This goes beyond what annotations state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each earning its place: purpose, validation behavior, unknown-name handling, and a critical usage warning with a cross-reference to decode_template. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover safety traits, the description supplies sufficient context: what the tool does, when to use it, how errors are handled, and what to do if uncertain. It is complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters in detail. The description adds minimal parameter-specific semantics beyond restating 'exact English name' and the high-level categories (professions, attributes, 8 skills), which is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Compile a build ... into an official in-game template code.' It clearly distinguishes encode_template from siblings like decode_template and validate_build by stating its function is to produce a template code, not to decode or merely validate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: template codes must come from this tool, never hand-written, and if unsure, verify with decode_template. It also states that the build is validated first, implying appropriate use cases and a fallback alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds contextual behavior: the note about heroes equipping account-unlocked skills and PvE-only restrictions, plus the return contents. It does not mention error handling or edge cases, but the annotations cover safety aspects, and the extra context about game mechanics adds value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary action and resource. Each sentence serves a distinct purpose: action/returns, relevant game mechanic, and usage guidance. There is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with an output schema and fully described parameters, the description covers all necessary aspects: what it does, when to use it, and how it differs from siblings. The note about hero skill mechanics also provides context an agent might need to interpret results correctly. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are fully described in the schema (100% coverage). The description adds clarity by explaining the id as 'GWCA HeroID, matching the AccountExport plugin output' and provides a concrete example for name ('Master of Whispers'). This goes beyond the schema's basic descriptions, making parameter usage unambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Look up a GW1 hero by name or by id', specifies the return values (profession, campaign, unlock method), and distinguishes it from the sibling tool list_heroes by explicitly mentioning 'Use this for one known hero; to browse or filter the roster, use list_heroes instead.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use this tool versus alternatives: 'Use this for one known hero; to browse or filter the roster, use list_heroes instead.' This directly addresses tool selection and mentions the alternative by name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and idempotent hints, so the description doesn't need to repeat safety. It adds the closest-match fallback behavior and the list of returned fields, which is helpful beyond the schema 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each contributing distinct value: purpose, behavior/fallback, and usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a rich output schema and clear behavioral description including error/fallback behavior, the description is sufficiently complete. It also covers the primary alternative tool, making it contextually complete for selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description reinforces exact-name and template-ID semantics but doesn't add material new parameter details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool looks up a single GW1 skill by exact English name or template ID, with a specific verb and scope. It explicitly distinguishes itself from search_skills by noting the exact-skill use case, so it fully differentiates from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'Use this when you already know the exact skill' and points to search_skills for discovery by profession/attribute/name fragment. This is a clear when-to-use and alternative recommendation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so no additional safety disclosure is needed. The description adds context beyond annotations by revealing that the output shows which professions are coverable by heroes and how each hero is unlocked, which is helpful behavioral information about the tool's output. It doesn't describe pagination/ordering, but the presence of an output schema likely covers return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the primary action and optional filters, the second adds the use case and output value. It is front-loaded with the verb 'List' and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with rich schema coverage (both params fully described), read-only annotations, and an output schema, the description adequately covers purpose, usage context, and what the output conveys. No critical information is missing for an agent to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters fully documented using exact allowed values. The description repeats 'profession or campaign name' without adding extra meaning beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all GW1 heroes, optionally filtered by profession or campaign name' – a specific verb ('List') and resource ('GW1 heroes') with modifiers. It also implicitly distinguishes from the sibling get_hero by focusing on the list of all heroes rather than a single hero.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete use case ('team-building') and indicates what the tool shows (professions coverable, unlock status). It does not explicitly mention alternative tools or when-not-to-use, but the context is clear enough for an agent to decide when this list tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful behavioral context by stating the tool returns 'compact records' rather than full data, and scopes it to the 'full GW1 skill database' — detail not present in annotations or schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero fluff. The first sentence names the action and filter dimensions; the second gives output granularity and points to the sibling tool for detail. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is moderately complex with 8 optional parameters and an output schema, but the schema already documents all parameter semantics and return structure. The description appropriately notes the compact-record nature and the get_skill alternative. It does not mention pagination behavior explicitly, though offset/limit are well-documented in the schema, so the description is sufficient for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (elite, limit, offset, campaignName, nameContains, attributeName, professionName, includePvpVersions) already has a detailed description. The tool description adds only a high-level summary of filter dimensions and notes that valid values are documented per parameter, which does not materially exceed what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb "Search" and the resource "full GW1 skill database", listing concrete filter dimensions (profession, attribute, campaign, elite flag, name fragment). It clearly distinguishes from the sibling get_skill by noting it returns compact records for searching rather than full details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly directs the agent to 'use get_skill for full details,' naming the appropriate alternative for follow-up lookups. It implies search_skills is for initial filtered discovery, but it does not enumerate scenarios where sibling search-like tools might be preferable, so it stops short of full when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior, so the description adds value by specifying the return structure ({valid, errors, warnings}) and explicitly noting it does not perform encoding. The listed validation rules also give the agent an accurate expectation of the tool's behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently covers purpose, input format, validation rules, and return shape. It is slightly dense but contains no fluff. It earns a 4 rather than 5 because the long list of rules in one sentence could be slightly easier to parse if broken up.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 7 parameters and the existence of an output schema, the description is quite complete: it states the input types (professions, attributes, 8 skills), key validation rules, return shape, and a distinguishing trait (no encoding). The output schema will fill in detailed return fields, so the description does not need to.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds minimal extra semantic value: it mentions 'exact English name' for skills and the general input of professions, attributes, and skills, but does not go beyond the schema. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb 'Check' and clearly states the resource (a build) and the domain (Guild Wars 1 rules). It enumerates the exact rules validated and differentiates from sibling tools by emphasizing this is validation rather than encoding/decoding or retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: whenever one needs to validate a build against GW1 rules. While it doesn't explicitly name alternatives or exclusions, the sibling tools (encode/decode/search/get) are obviously different, so the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.