charactercheck-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| deriveA | Compile selected D&D Beyond character fields into deterministic values, canonical trust states, provenance, unsupported/unknown findings, and lint. This is partial read-only context, not complete rules validation. Input: exact public DDB character URL or id. |
| stanceC | Pre-combat context with canonical assessment. Observed hand/equipment state requires player or session-host confirmation. |
| qaB | Run the 100-question extraction Coverage Inventory. Every answer carries its question and closed trust state; this is not a validity score. |
| diffA | Classify the supported subset of changes between a supplied CharacterSnapshotV1 object and a freshly observed public character. No mutation is applied and unclassified changes are named. |
| snapshotA | Observe a public character once and return a privacy-filtered, versioned CharacterSnapshotV1. Account identifiers, linked images, and persona are omitted. |
| seatpackC | Privacy-minimized read-only character context. Persona is never exposed; mutable player-authority state is marked rather than treated as host truth. |
| quizB | Read-only settlement and sheet-specific finding prompts. Expected answers exist only for canonical trusted fields; mutable or uncertain fields remain null. |
| reportC | Canonical trust and field assessments plus unhandled and lint findings. |
| intakeC | One pre-session packet: supported-coverage state, the exact questions to resolve before dice (each with the family it unblocks), unsupported content, the fields that are the player's to declare, and a baseline-snapshot hint. |
| selftestA | Check the offline installation against a bundled sample character — no network, no D&D Beyond account, no character required. Run this first when bootstrapping: it separates 'the tool is broken' from 'I cannot reach that character'. |
| doctorA | Diagnose why it is not working: python, DNS, outbound HTTPS, and (with a ref) reachability of that character. Each check reports PASS/FAIL and the first failure carries the remedy. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Several tools (derive, report, stance, seatpack, intake) all produce some form of character assessment, but their descriptions specify distinct focuses (deterministic values, trust reports, pre-combat context, privacy-minimized context, pre-session prep). qa and quiz both involve questions but differ in coverage inventory vs. finding prompts. With detailed descriptions an agent can likely disambiguate, but the boundaries are not immediately obvious.
Tool names are all lowercase single words, but mix verbs (derive, diff), nouns (stance, report), and cryptic compounds (seatpack, selftest) without a consistent verb_noun pattern. This makes it hard to predict what a tool does from its name. There is no discoverable naming scheme.
At 11 tools, the count is within the reasonable 3-15 band, but includes two maintenance/diagnostic tools (selftest, doctor) that seem tangential to the core character-checking purpose. Slightly heavy, but each character-focused tool earns its place.
For a read-only character validation domain, the set covers observation (snapshot), comparison (diff), assessment (derive, report), context (stance, seatpack, quiz, intake), and self-testing (selftest, doctor). Minor gaps: no batch processing or field-level catalog, but core workflows are complete.