Skip to main content
Glama
rjenks
by rjenks

build_validate_build

Validate Pathfinder 2e builds for rule violations and missing prerequisites. Returns errors and warnings on feats, skill ranks, ancestry budget, archetype dedication, proficiency, and PFS.

Instructions

Structured validation, not prose -- returns errors (definite rule violations) and warnings (things that couldn't be auto-verified and need human confirmation). Covers: duplicate feats, prerequisites of every taken feat still being satisfied (important after e.g. a hypothetical ancestry swap mid-build), skill ranks not exceeding the fixed level-3/7/15 expert/master/legendary caps, whether the number of ancestry-category feats taken fits the character's actual budget for their level, and (new) the archetype "one dedication feat at a time" rule -- a level-ordered check that no dedication feat was taken while an earlier, different dedication still needed two other archetype feats first (see _validate_dedication_exclusivity; this is validation this project does that Foundry's own reference implementation doesn't attempt either -- confirmed nothing in its source enforces it), and (new) a warning for any fixed (non-player-choice) trained skill or Lore the character's background/class grants but that isn't actually trained on the character (see _validate_fixed_trained_skills -- deliberately scoped to just the fixed/unconditional grants, not the player's free "additional" choices, since those can't be cleanly told apart from later Skill Increases without risking a false positive at higher levels), (new) a warning if the character's total count of trained-or-better skills/lores is below the level-1 minimum implied by class fixed+additional skills, background fixed/lore/choice skills, and the character's Intelligence modifier if positive -- a floor check, not an identity check, so it stays valid at any level (see _validate_trained_skill_count; this exists specifically because the Intelligence-modifier bonus to a class's additional trained-skill count is a universal core rule not baked into list_classes' additional field, and is easy to silently drop), and (new) a warning for any save/Perception/weapon/ armor/class-DC proficiency rank that's lower than what the character's class baseline plus its granted class features/taken feats up to their level should produce (see _validate_proficiency_ranks). Does NOT yet check ability-boost-tier double-ups across sources, or spellcasting proficiency specifically (tradition-dependent -- see _validate_proficiency_ranks's docstring for why that one key is skipped).

`variant_rules` (see rules_list_variant_rules / get_level_up_choices)
changes the ancestry-feat budget when `'ancestry-paragon'` is included
(2 feats at level 1, one more at every odd level, instead of the
class's normal 1/5/9/13/17 schedule), and adds a soft, non-blocking
note about archetype-trait feat count when `'free-archetype'` is
included -- that one is a warning rather than an error because this
server doesn't track class/skill-feat-slot usage at all, so it can't
tell a normal-slot archetype feat apart from a free-archetype bonus
slot with certainty; only ancestry feats get a hard budget check, since
'ancestry' is otherwise never used as a normal class/skill/general feat
slot. The **Ancestral Paragon** general feat (a real, always-available
pick independent of any variant rule) adds +1 to the ancestry budget on
its own if taken.

`pfs_legal_only=True` adds a warning for any taken feat whose
best-effort PFS status (see pfs.py) isn't 'legal' -- not authoritative,
see that module's docstring.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
characterYes
variant_rulesNo
pfs_legal_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries the full burden and delivers thoroughly. It explains the error/warning distinction, details each validation check, describes how variant_rules changes behavior, notes the soft/non-blocking nature of some warnings, and discloses limitations (e.g., no ability-boost double-up check, no spellcasting proficiency). It even provides rationale for scoping decisions (e.g., fixed trained skills warning).

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 very long and includes parenthetical references to internal function names and docstrings, which adds noise. However, it is front-loaded with the main purpose and logically organized: validation categories first, then variant rules and parameter effects. Most sentences add meaningful information, but it could be tightened by removing some internal implementation details.

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 tool has 3 parameters, one nested object, and an output schema, yet the description covers all key aspects: return types (errors/warnings), validation scope, parameter effects, limitations, and even the distinction from Foundry's implementation. It is complete enough for an agent to use correctly without additional lookups, despite the moderate complexity.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate. It does so excellently: it explains variant_rules values ('ancestry-paragon', 'free-archetype') and their effects, and describes pfs_legal_only semantics with caveats. The 'character' parameter's meaning is inherently clear from the tool's purpose. Nearly all parameter intent is covered.

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 validates builds and returns structured errors and warnings. It enumerates specific validation categories (duplicate feats, prerequisites, skill caps, ancestry budget, archetype dedication, etc.), which distinguishes it from sibling tools like build_check_prerequisite. The verb-resource pair is explicit: 'build_validate_build' validates a character build.

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 gives strong context on when the tool is appropriate (full build validation) and lists limitations ('Does NOT yet check...'), but it does not explicitly name alternatives or say 'use this when validating an entire build'. The scope is clear, though exclusions for alternative tools are implicit rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

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/rjenks/pf2e-mcp'

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