Embers: Tabletop RPG Toolkit

Read 5e24 character-creation options

vault_get_pc_creation_options

Read-onlyIdempotent

Read the legal choices for guided 5e24 character creation — the same projections vault's web wizard reads. Pass 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 their arrays and point-buy costs, 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

Name	Required	Description	Default
`kind`	Yes	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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description adds critical behavioral nuances beyond those: the index-aligned arrays with null placeholders, the meaning of `prepared: true` (spells excluded from preparedSpellPicks), and the `bg:` prefix for repeatable feats in the background slot. No contradiction with annotations.

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 a single dense block of text with heavy parentheticals, repeating much of the schema description nearly verbatim. It is not structured with bullets or clear separation of the five kinds, making it hard to scan. While the opening sentence is clear and the 'Use this BEFORE' instruction is early, the bulk is unwieldy and redundant.

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

Completeness4/5

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

Despite an output schema existing, the description covers all essential nuances: return structure per kind, the index alignment, the prepared flag exclusion, the bg prefix, and the recommended reading order. It is complete but overly verbose; a shorter version that pointed to the schema for details would have been sufficient given the output schema.

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 100% and already detailed, but the tool description adds essential extra semantics: the index-alignment note (null entries hold positions) and the `bg:` prefix for repeatable feats in background picks. It also clarifies the 'constants' kind includes originFeatCategory for filtering the feat list. These are not in the schema and are vital for correct invocation.

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 ('Read') and a clear resource ('legal choices for guided 5e24 character creation'), explicitly stating it returns the same projections the web wizard uses. It differentiates from siblings by positioning itself as a pre-build step before vault_build_pc, and the sibling list shows vault_get_levelup_options is for leveling, not creation.

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 says 'Use this BEFORE vault_build_pc' and gives a recommended reading order: 'Start with constants and class, then read species/background/feat as the build takes shape.' This tells the agent exactly when and how to use the tool, though it does not explicitly say when not to use it, the positive guidance is strong.

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

All Embers: Tabletop RPG Toolkit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?