Skip to main content
Glama

Embers: Tabletop RPG Toolkit

Read character-creation options

vault_get_pc_creation_options
Read-onlyIdempotent

Read the legal choices for guided character creation — the same projections vault's web wizard reads. Pass ruleset (one with guided creation: the ruleset field's list; list_rulesets gives each code's label) and kind to select one list: 'class' / 'species' / 'background' / 'feat' return the option projections (the calling user's own content plus stock, each option carrying its nested choices: skillChoices, toolChoices, startingEquipmentOptions, and per applied ability/feat — proficiencyChoices, spellChoices, spellListChoices, preparedSpells, and choice whose options carry a type; a background option also carries skillChoices + languages, a species option carries languages; background bump modes / feat, etc.); 'feat' returns every feat (a feat picked via an ability's choice carries its own proficiency/spell sub-choices); 'constants' returns the static reference data (skill list with attributes, ability-score methods with each method's data, language options + pick count, alignments, background bump modes, max ability score, and originFeatCategory — the feat category the background's open feat slot is restricted to; filter the 'feat' list to it for the background pick). Use this BEFORE vault_build_pc so every id and pick you send is one the user is actually entitled to. Start with 'constants' and 'class', then read 'species' / 'background' / 'feat' as the build takes shape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesWhich creation list to read. 'class' / 'species' / 'background' / 'feat' return the option projections (the user's own + stock content they may pick, with each option's nested choices — skillChoices, toolChoices, startingEquipmentOptions, and per applied ability/feat: proficiencyChoices {types,count,options}, spellChoices {count,options,prepared}, spellListChoices {categories,picks[].optionsByCategory,prepared}, preparedSpells {count} (a block's `prepared: true` = its spells land always-prepared and are EXCLUDED from the preparedSpellPicks pool), abilityScoreBump {options[].lines[]:{amount,count,eligible,max}} (supply the player's pick via `vault_build_pc.abilityBumpPicks`), and `choice` {count,options} where each option carries a `type`. The spellChoices / spellListChoices arrays are INDEX-ALIGNED with the authored blocks — a null entry holds the position of a block that grants nothing at the starting level; skip it when rendering but count it when keying picks. A 'background' option ALSO carries its own `skillChoices {count,options}` (a background skill-choice grant → supply picks via `vault_build_pc.backgroundSkillProficiencies`) and `languages {fixed, choose:{count,options}}`; a 'species' option carries `languages {fixed, choose}`. For a `languages.choose` grant, supply the picks via `vault_build_pc.languageChoicePicks` keyed by that rule's `_id`; `languages.fixed` apply automatically). 'feat' returns EVERY feat (the background slot uses the `originFeatCategory` feats; a feat picked via an ability's `choice` may be any) — a picked feat carries its own proficiency/spell sub-choices. Each 'feat' option carries `repeatable`; a `repeatable` feat filling the background slot keys its `vault_build_pc` picks with a `bg:` prefix. 'constants' returns the static reference data (skill list, ability-score methods and each method's data, language options, alignments, background bump modes, max ability score, and originFeatCategory — the feat category the background's open feat slot is restricted to; filter the 'feat' list to it for the background pick). Read 'constants' plus 'class' first; read 'species'/'background'/'feat' as the build takes shape.
rulesetNoA ruleset with guided character creation. Send the same ruleset to `vault_build_pc`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"Which 5e24 creation list to read. 'class' / 'species' / 'background' / 'feat' return the option projections (the user's own + stock content they may pick, with each option's nested choices — skillChoices, toolChoices, startingEquipmentOptions, and per applied ability/feat: proficiencyChoices {types,count,options}, spellChoices {count,options,prepared}, spellListChoices {categories,picks[].optionsByCategory,prepared}, preparedSpells {count} (a block's `prepared: true` = its spells land always-prepared and are EXCLUDED from the preparedSpellPicks pool), abilityScoreBump {options[].lines[]:{amount,count,eligible,max}} (supply the player's pick via `vault_build_pc.abilityBumpPicks`), and `choice` {count,options} where each option carries a `type`. The spellChoices / spellListChoices arrays are INDEX-ALIGNED with the authored blocks — a null entry holds the position of a block that grants nothing at level 1; skip it when rendering but count it when keying picks. A 'background' option ALSO carries its own `skillChoices {count,options}` (a background skill-choice grant → supply picks via `vault_build_pc.backgroundSkillProficiencies`) and `languages {fixed, choose:{count,options}}`; a 'species' option carries `languages {fixed, choose}`. For a `languages.choose` grant, supply the picks via `vault_build_pc.languageChoicePicks` keyed by that rule's `_id`; `languages.fixed` apply automatically). 'feat' returns EVERY feat (the background slot uses Origin-category feats; a feat picked via an ability's `choice` may be any) — a picked feat carries its own proficiency/spell sub-choices. Each 'feat' option carries `repeatable`; a `repeatable` feat filling the background slot keys its `vault_build_pc` picks with a `bg:` prefix. 'constants' returns the static reference data (skill list, ability-score methods and their arrays/point-buy costs, language options, alignments, background bump modes, max ability score, and originFeatCategory — the feat category the background's open feat slot is restricted to; filter the 'feat' list to it for the background pick). Read 'constants' plus 'class' first; read 'species'/'background'/'feat' as the build takes shape."New value: +"Which creation list to read. 'class' / 'species' / 'background' / 'feat' return the option projections (the user's own + stock content they may pick, with each option's nested choices — skillChoices, toolChoices, startingEquipmentOptions, and per applied ability/feat: proficiencyChoices {types,count,options}, spellChoices {count,options,prepared}, spellListChoices {categories,picks[].optionsByCategory,prepared}, preparedSpells {count} (a block's `prepared: true` = its spells land always-prepared and are EXCLUDED from the preparedSpellPicks pool), abilityScoreBump {options[].lines[]:{amount,count,eligible,max}} (supply the player's pick via `vault_build_pc.abilityBumpPicks`), and `choice` {count,options} where each option carries a `type`. The spellChoices / spellListChoices arrays are INDEX-ALIGNED with the authored blocks — a null entry holds the position of a block that grants nothing at the starting level; skip it when rendering but count it when keying picks. A 'background' option ALSO carries its own `skillChoices {count,options}` (a background skill-choice grant → supply picks via `vault_build_pc.backgroundSkillProficiencies`) and `languages {fixed, choose:{count,options}}`; a 'species' option carries `languages {fixed, choose}`. For a `languages.choose` grant, supply the picks via `vault_build_pc.languageChoicePicks` keyed by that rule's `_id`; `languages.fixed` apply automatically). 'feat' returns EVERY feat (the background slot uses the `originFeatCategory` feats; a feat picked via an ability's `choice` may be any) — a picked feat carries its own proficiency/spell sub-choices. Each 'feat' option carries `repeatable`; a `repeatable` feat filling the background slot keys its `vault_build_pc` picks with a `bg:` prefix. 'constants' returns the static reference data (skill list, ability-score methods and each method's data, language options, alignments, background bump modes, max ability score, and originFeatCategory — the feat category the background's open feat slot is restricted to; filter the 'feat' list to it for the background pick). Read 'constants' plus 'class' first; read 'species'/'background'/'feat' as the build takes shape."
    • addedInput schema / properties / ruleset
      Added value: +{
      +  "description": "A ruleset with guided character creation. Send the same ruleset to `vault_build_pc`.",
      +  "enum": [
      +    "5e24"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds substantial behavioral context: it returns the calling user's own content plus stock, it mirrors the web wizard's projections, it explains nested choice structures, index-aligned null placeholders, repeatable feat key prefixes, and the originFeatCategory restriction. This is rich context beyond what annotations provide.

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

Conciseness2/5

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

The description is extremely long and dense, and large portions duplicate the already exhaustive input schema descriptions. While the purpose and sequencing are front-loaded, the sheer volume means many sentences do not earn their place, making it hard to scan.

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 guided character creation and the presence of a rich output schema, the description is complete enough: it covers ordering, entitlement filtering, what each kind returns, and key relationships to vault_build_pc. Return-value details are appropriately left to the output schema.

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% and the input schema already exhaustively documents both parameters, including each kind's returned structures. The description largely restates the same kind semantics, adding only a minor reference to list_rulesets for ruleset labels. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb ('Read') and resource ('legal choices for guided character creation'), and distinguishes itself from the build tool by positioning as the pre-read step before vault_build_pc. An agent can immediately tell this tool returns option projections rather than performing a mutation.

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?

Explicitly says to use this BEFORE vault_build_pc, gives an ordering ('Start with constants and class, then read species/background/feat as the build takes shape'), and points to list_rulesets for ruleset labels. It leaves no ambiguity about when and in what sequence to call it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources