Skip to main content
Glama
rjenks
by rjenks

build_list_available_feats

Returns only feats in a category that a character meets the prerequisites for at a target level, separating confirmed from unconfirmed ones for manual review.

Instructions

The main token-saving discovery tool: returns only feats of the requested category at or below the target level (character's current level if unspecified) whose prerequisites the character already meets, instead of the caller reasoning over the full feat list or raw rules text. Split into two buckets:

- "available": prerequisites confirmed satisfied (or none required).
- "unconfirmed": at least one prerequisite couldn't be automatically
  verified (freeform text the parser can't structure -- roughly 16% of
  all feats per the Phase 0 parsing spike). Never silently included in
  "available" -- surface these to the user for manual confirmation.

Feats that definitely fail a prerequisite, or that the character
already has, are omitted entirely.

"class" and "ancestry" feats are further restricted to the character's
own class/ancestry (matched via the feat's trait list, e.g. a Fighter
class feat carries the "fighter" trait) -- category alone only narrows
to "any class feat from any class".

"archetype" is a special case: the source data has no "archetype"
category value at all (confirmed against the real data -- every
archetype/dedication feat is stored as category "class" or "skill",
with "archetype" appearing only as a trait). This matches actual PF2e
rules: archetype feats are taken using ordinary class or skill feat
slots, not a separate slot type. This function queries for the
"archetype" trait within those two categories instead. It does not
filter further to one specific chosen archetype (e.g. "only Alchemist
archetype feats") -- that gating already happens naturally through each
feat's own prerequisite (e.g. "Alchemist Dedication"), checked the same
way as any other prerequisite.

Every returned entry also carries `rarity` and a best-effort `pfs`
legality status (not authoritative -- see pfs.py module docstring),
so a PFS-bound build can be steered away from restricted picks without
a separate lookup per feat.

`include_legacy` (default False): excludes pre-Remaster/OGL-flagged
feats unless set. See `_legacy_filter_sql`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
levelNo
characterYes
feat_categoryYes
include_legacyNo

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 provided, the description carries full burden and excels. It discloses the two output buckets ('available' vs 'unconfirmed'), the rule that unconfirmed feats are never silently included, and the omission of failing/owned feats. It also honestly notes that pfs legality is 'best-effort' and 'not authoritative,' and explains the archetype data anomaly in detail.

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 well-structured and front-loaded with the core purpose. Each paragraph addresses a distinct aspect: output buckets, filtering logic, archetype special case, and return metadata. Some redundancy exists (e.g., restating PF2e rules context), but for the tool's complexity, the length is justified and every major section adds value.

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, the description is remarkably complete. It covers output semantics, filtering edge cases, category-specific behavior, legacy filtering, and added metadata. The presence of an output schema reduces the need to explain return values, but the description already covers what appears in each entry (rarity, pfs status). It fully equips an agent to decide when and how to invoke this tool.

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 explains level defaults to character's current level, feat_category includes the special 'archetype' handling, and include_legacy default behavior is described. The character parameter is implied through repeated references to 'character's own class/ancestry' and 'current level,' providing enough context for an agent to understand its role.

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: a 'token-saving discovery tool' that 'returns only feats of the requested category at or below the target level whose prerequisites the character already meets.' This clearly distinguishes it from sibling tools like rules_search and build_check_prerequisite by emphasizing its filtering and token-saving role.

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?

It explicitly states when to use the tool: instead of reasoning over the full feat list or raw rules text. It also provides when-not guidance by explaining that feats failing prerequisites or already owned are omitted, and that archetype feats are queried via trait within class/skill categories. Special cases like class/ancestry restrictions and include_legacy behavior are thoroughly covered.

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