Skip to main content
Glama
rjenks
by rjenks

build_list_classes

List Pathfinder 2e classes with their level-1 baseline proficiencies including HP, saves, trained skills, and weapon/armor, ready for character creation. Optionally filter by name.

Instructions

List classes, optionally filtered by name substring. Includes each class's level-1 initial proficiency baseline (HP, Perception, saves, trained skills formula, weapon/armor proficiencies) -- sourced directly from the class item's own data rather than requiring the caller to recall or look this up externally. Proficiency ranks in the returned perception/fortitude/reflex/will/class_dc/attacks/defenses fields use this project's 0/2/4/6/8 convention (untrained/trained/ expert/master/legendary), the same as a character's proficiencies dict elsewhere -- ready to drop into a draft character directly.

Note this is the class's own *baseline* only -- doctrine/subclass
choices (e.g. Cleric's Warpriest doctrine granting expert Fortitude and
martial weapons) and later automatic class features (e.g. Champion's
Weapon Expertise at level 5) can raise these further; this call doesn't
know about either, only what every member of the class starts with at
level 1.

**`trained_skills.additional` is the class's own flat baseline ONLY --
it does NOT include the Intelligence-modifier bonus to additional
trained skills that every class gets at character creation** ("...
becomes trained in a number of skills equal to [class value] plus your
Intelligence modifier" -- Player Core, Skills step of character
creation). This is a genuinely easy value to miscount: confirmed live
building a level-10 Magus with Int 14 (+2) where only 2 additional
skills were picked instead of the correct 4. The caller is responsible
for adding `max(0, ability_mod(character's Int score))` to this value
themselves before presenting a skill count to the user; `validate_build`
now includes a floor check for this specifically (see
`_validate_trained_skill_count`) but it's a warning after the fact, not
a substitute for getting the count right when first proposing it.

`trained_skills.choice`, when present, is a class's "trained in X **or**
Y" pattern (e.g. Fighter's Acrobatics-or-Athletics) that `fixed` alone
can't represent -- sourced from the class item's own ChoiceSet rule
element (see `item_choice_sets`), not from `fixed` being silently
incomplete.

`include_legacy` (default False): excludes pre-Remaster/OGL-flagged
classes unless set -- currently a no-op (every class chassis has been
reprinted under ORC, so all 29 are is_remaster:1), kept for API
consistency with the other `list_*` tools and in case a future release
adds a class before its own remaster reprint. See `_legacy_filter_sql`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNo
include_legacyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It extensively discloses behaviors: the 0/2/4/6/8 proficiency rank convention, the fact that this is 'baseline only' excluding subclass/later features, the no-op status of include_legacy, and detailed caveats about the trained skills count. This is exemplary transparency.

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 long but structured with clear paragraphs and bold text, front-loading the core purpose before diving into caveats. While some internal details like `_legacy_filter_sql` and the Magus anecdote could be trimmed, the length is justified by the complexity of the output semantics.

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 complexity of the tool and the presence of an output schema, the description covers the necessary behavioral context: the meaning of the returned proficiency ranks, the baseline vs. subclass distinction, the trained skills calculation gotcha, and the parameter semantics. It leaves little ambiguity for an agent to misuse the 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?

Schema coverage is 0%, so the description must explain the parameters. It adequately describes `filter` as a name substring, and it thoroughly explains `include_legacy` including its default, its current no-op status, and the reason for its existence. Although `filter` lacks details like case sensitivity, the description adds meaning far beyond the empty 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 'List classes, optionally filtered by name substring', which clearly states the verb and resource. It further specifies that it returns level-1 proficiency baselines and distinguishes itself from generic list tools by noting the data source. The purpose is specific and distinguishes from sibling list tools.

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

Usage Guidelines4/5

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

The description provides clear context on when to use this tool: for obtaining class baseline stats for a draft character, with a caution that it does not account for doctrine/subclass choices or later automatic features. It also explains that the caller must add the Intelligence modifier to `trained_skills.additional`, which is a usage directive. However, it does not explicitly name alternative tools for those other needs, so it falls short of fully explicit alternative selection.

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