run-dmcp 0.1.0 → 0.2.0

package/dist/index.js

@@ -1,92 +1,184 @@
-#!/usr/bin/env node
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
-import { initializeSchema } from "./db/schema.js";
-import { closeDatabase } from "./db/connection.js";
-import { startHttpServer } from "./http/server.js";
-import { setHttpPort } from "./utils/webui.js";
-// Import registration functions
-import { registerCoreTools } from "./register/core.js";
-import { registerWorldTools } from "./register/world.js";
-import { registerCharacterTools } from "./register/character.js";
-import { registerCombatTools } from "./register/combat.js";
-import { registerInventoryTools } from "./register/inventory.js";
-import { registerQuestTools } from "./register/quests.js";
-import { registerNarrativeTools } from "./register/narrative.js";
-import { registerResourceTools } from "./register/resources.js";
-import { registerTimeTools } from "./register/time.js";
-import { registerTableTools } from "./register/tables.js";
-import { registerSecretTools } from "./register/secrets.js";
-import { registerRelationshipTools } from "./register/relationships.js";
-import { registerTagTools } from "./register/tags.js";
-import { registerStatusTools } from "./register/status.js";
-import { registerFactionTools } from "./register/factions.js";
-import { registerAbilityTools } from "./register/abilities.js";
-import { registerNoteTools } from "./register/notes.js";
-import { registerPauseTools } from "./register/pause.js";
-import { registerImageTools } from "./register/images.js";
-import { registerAudioTools } from "./register/audio.js";
-import { registerDisplayTools } from "./register/display.js";
-import { registerBatchTools } from "./register/batch.js";
-import { registerMcpResources } from "./register/mcp-resources.js";
-import { registerMcpPrompts } from "./register/mcp-prompts.js";
-// Initialize database
-initializeSchema();
-// Create MCP server
-const server = new McpServer({
-    name: "dmcp",
-    version: "0.1.0",
-});
-// Register all tools by domain
-registerCoreTools(server); // Game, Interview, Rules
-registerWorldTools(server); // Locations, Connections, Map
-registerCharacterTools(server); // Characters (PC/NPC)
-registerCombatTools(server); // Combat, Dice, Checks
-registerInventoryTools(server); // Items
-registerQuestTools(server); // Quests, Objectives
-registerNarrativeTools(server); // Events, History, Export, Player Choices
-registerResourceTools(server); // Custom Resources
-registerTimeTools(server); // Calendar, Time, Timers
-registerTableTools(server); // Random Tables
-registerSecretTools(server); // Secrets, Knowledge
-registerRelationshipTools(server); // Relationships
-registerTagTools(server); // Tags
-registerStatusTools(server); // Status Effects
-registerFactionTools(server); // Factions
-registerAbilityTools(server); // Abilities/Powers
-registerNoteTools(server); // Game Notes
-registerPauseTools(server); // Pause/Resume, Context Snapshots, External Updates
-registerImageTools(server); // Stored Images
-registerAudioTools(server); // Stored Audio (TTS, Voice References)
-registerDisplayTools(server); // Display/Theme Configuration
-registerBatchTools(server); // Batch Operations (multi-entity, workflows)
-// Register MCP Resources and Prompts
-registerMcpResources(server); // Read-only data access via URI
-registerMcpPrompts(server); // Reusable prompt templates
-// ============================================================================
-// START SERVER
-// ============================================================================
-// HTTP server port (configurable via environment variable)
-const HTTP_PORT = parseInt(process.env.DMCP_HTTP_PORT || "3456", 10);
-async function main() {
-    // Start HTTP server for web UI (runs alongside MCP)
-    const actualPort = await startHttpServer(HTTP_PORT);
-    setHttpPort(actualPort);
-    // Start MCP server with stdio transport
-    const transport = new StdioServerTransport();
-    await server.connect(transport);
-}
-// Handle cleanup
-process.on("SIGINT", () => {
-    closeDatabase();
-    process.exit(0);
-});
-process.on("SIGTERM", () => {
-    closeDatabase();
-    process.exit(0);
-});
-main().catch((error) => {
-    console.error("Server error:", error);
-    closeDatabase();
-    process.exit(1);
-});
+// The library entry point: exports, and nothing else.
+//
+// Importing this module must do nothing to the machine -- no database file, no
+// listener, no transport, no timer, no work of any kind. 0.1.0 shipped one
+// entry that was both library and application, so importing the package opened
+// a database inside node_modules and bound the web UI's port, and the listener
+// outlived the import by hours.
+//
+// The rule is asserted from the outside in src/__tests__/entrypoints.test.ts:
+// a child process imports this file and must be able to EXIT. Anything left
+// open keeps it alive and fails the test, so the guarantee does not depend on
+// anyone remembering to enumerate what must not start.
+//
+// Starting things is src/bin/run-dmcp.ts, which is what `bin` points at.
+//
+// THIS PACKAGE ROOT IS THE CORE (design §8, issue #17): entities, facts,
+// events, the timeline, and the entity/property domains a consumer cannot
+// lose without losing its own spine -- resources, relationships, factions,
+// secrets, locations, items. Dice, combat, abilities, status effects, random
+// tables and quests are genuinely game-shaped, and they are an OPTIONAL
+// layer above this, not part of it: import "run-dmcp/rpg" for
+// `createMcpServer`, the full assembly this package used to export under
+// that name. That is design §8's line, not an inversion of it -- the core
+// stays importable, buildable and useful with nothing above it, and the
+// layer stays free to depend down into the core without the core ever
+// depending up into it. `src/__tests__/layerBoundary.test.ts` walks the
+// static import graph from this file and fails if anything under `src/rpg/`
+// is reachable from it.
+export { createCoreMcpServer, SERVER_NAME, SERVER_VERSION } from "./mcp-server.js";
+// The database, and where it lives. The path resolves against the consuming
+// application (DMCP_DB_PATH, else an existing XDG data directory, else the
+// working directory) and never against this package's install location.
+export { getDatabase, closeDatabase, withTransaction, getDatabasePath, getDataDir, resolveDataPathFrom, } from "./db/connection.js";
+// The schema, and the hook a consuming application uses to bring up its own
+// tables in the same startup pass, in the same database, under the same rules.
+export { initializeSchema } from "./db/schema.js";
+// The timeline (design §5.1) -- the reason this engine exists, and therefore
+// something a consuming application reaches directly rather than only through
+// a tool call. `replay` answers what the world looked like at any `t`;
+// `declareTimeAxis` is where an application says what its `t` actually is,
+// which it must do before its first write for that game if it wants its own
+// origin (see clock.ts).
+//
+// `timelineDivergences` is exported for the same reason design §13 makes it a
+// stop condition rather than a nicety: an application that keeps its world
+// here is entitled to ask, of its own database, whether the log it is trusting
+// still reproduces its live tables. It returns rows and never a verdict.
+export { replay } from "./timeline/replay.js";
+export { declareTimeAxis, setStoryTime, currentStoryTime } from "./timeline/clock.js";
+// `changes_within(t0, t1)` (design §5.5) -- the range companion to `replay`,
+// for a consumer whose units have duration rather than instants. It returns
+// transitions and never a verdict: one caller reads a change inside a window
+// as a defect, another reads the same rows to build a summary of what has
+// happened since it last looked. Same primitive, opposite readings, which is
+// how you can tell it belongs in the core rather than to whoever asked first.
+export { changesWithin } from "./timeline/changes.js";
+export { compareT, assertT } from "./timeline/t.js";
+export { timelineDivergences } from "./timeline/checkpoint.js";
+// `irreversible` (design §5.3) -- the temporal member of the constraint family.
+// Exported because the enforcement is structural (triggers on `facts`), which
+// means an application never calls a checker: it declares, and later
+// contradictions are refused at the write that attempts them. What it does need
+// from here is the declaration itself, and the ability to ask which facts carry
+// it -- with the one hop of provenance (§5.2c) that makes a refusal reviewable
+// rather than merely obeyed.
+export { declareIrreversible, irreversibleFactFor, listIrreversibleFacts, } from "./timeline/irreversible.js";
+export { openingEventId } from "./timeline/provenance.js";
+// The narration constraint (design §5.2b/§5.2c, GitHub issues #11 and #12)
+// -- the outbound half of authority, and the half with two consumers.
+// "Here is what is true; depict it, do not argue with it." Exported as a
+// library function FIRST, before any MCP tool wraps it (the one tool that
+// does, `narration_constraint_at`, is a thin JSON-over-stdio wrapper around
+// this same call), because the consumer that most needs it is a process
+// that must never call a model at runtime: its units have duration and
+// everything in them is already known in advance, so its narrator output
+// is generated once, reviewed by a human, committed as a file, and
+// rendered hours later by a lint over that finished artifact, with no
+// engine and no model in the loop (§6's "library functions first, MCP
+// tools second," restated here because this is the export where it matters
+// most). `contradictions` is exported alongside it for the same reason and
+// takes no database handle at all -- it is a pure function over the plain
+// object `narrationConstraintAt` returns, so a caller can serialize a
+// constraint once, hand the JSON to an entirely separate process, and run
+// the check there hours or days later. Prohibitions in the returned shape
+// are derived and structural, never authored and lexical (hard rule 5): the
+// engine records that a fact holds and lets a claim disagree or not,
+// exactly the way `changes_within` (§5.5) records transitions rather than a
+// verdict -- there is no `mustNotSay`, no severity, nothing this project's
+// four recorded negative-prompt failures would recognise.
+export { narrationConstraintAt, contradictions, NARRATION_CONSTRAINT_FORMAT_VERSION, } from "./timeline/narration.js";
+// The constrained-write choke point (design §5.4 option (C)) -- the one place
+// a constrained numeric fact key changes, and the reason there is no longer a
+// `resource_history` table beside the timeline answering the same question.
+// Exported because an application that keeps invariant-bearing numbers here
+// has to be able to write them, and writing them anywhere else is precisely
+// the second path option (C) exists to close: a direct UPDATE still lands in
+// `facts` (the projection triggers see to that), but it arrives unchecked and
+// unannotated.
+//
+// `valueHistory` is the read half, and it is deliberately not a separate
+// mechanism -- it is `facts` and `events`, assembled. It returns rows and
+// never a verdict.
+//
+// `ConstraintViolationError` is exported because a refusal is only reviewable
+// if the caller can tell it apart from a failure. For the `irreversible`
+// member it carries §5.2c's one hop -- the contradicted fact, its
+// `valid_from_t`, and the event that opened it -- so a reviewer can answer
+// "is the fact wrong, or is the claim wrong", which is undecidable without it.
+export { writeConstrainedValue, transferConstrainedValue, valueHistory, } from "./timeline/constrained.js";
+export { ConstraintViolationError, constraintsFor, conservedConstraintFor } from "./timeline/registry.js";
+// The resolve protocol (design §5.2a, GitHub issue #10) -- the inbound half of
+// authority. The engine enforces the PROTOCOL -- resolution happens before
+// narration, writes go through the audited path, declared expectations are
+// checked -- without knowing what any particular mechanic MEANS. An application
+// registers its mechanics by passing them to `createResolver`, and the engine
+// dispatches them and never learns their names.
+//
+// Registration is injection at construction, exactly like `initializeSchema({
+// migrations })` and for exactly the same reason: a global registry would make
+// behaviour depend on module import order and on side effects at import time,
+// which is the disease the entry-point split above cured. A parameter cannot be
+// registered too late.
+//
+// NOTE WHAT IS DELIBERATELY *NOT* EXPORTED HERE: `withAdjudicationOpen` and
+// `adjudicationOpen` (./timeline/adjudication.js). `resolve_only` (issue #13)
+// means a value moves only through an adjudicating call, and the adjudication
+// window is what "adjudicating" is measured against -- so exporting the ability
+// to open one would hand every caller a one-line bypass of the constraint, and
+// the fourth member of the family would be enforced against everybody except
+// whoever read the export list. `resolver.resolve()` is the only public door to
+// a `resolve_only` value. That is the whole point of the constraint, so the
+// window stays internal to the engine that opens it.
+export { createResolver, ResolveProtocolError } from "./timeline/resolve.js";
+// The state-to-text projection (design §7, GitHub issue #16) -- "say what IS
+// true, never what is absent."
+//
+// What is exported here is the MECHANISM and the TYPE of a vocabulary. There
+// is deliberately no vocabulary value, no default and no example anywhere in
+// this package: a vocabulary rich enough to render a real world contains a
+// caller's own nouns, and either sitting in the engine would fail
+// `engineVocabulary.test.ts` on day one -- correctly (§7's closing paragraph,
+// §10). `RenderVocabulary` is a parameter type; a caller supplies the words.
+//
+// The rule is enforced at CONSTRUCTION and never by scanning output.
+// `createStateRenderer` refuses a vocabulary entry carrying any field but
+// `noun` and `adjectives`, by name -- which is what stops an `avoid:` or a
+// `negate:` being bolted on later -- and the renderer's only source of state
+// is `replay(t)`, so a fact that does not hold produces NOTHING rather than a
+// phrase about its absence. There is no differential form and never will be:
+// nothing here takes two `t`s, because "render the change between these two
+// states" is precisely the shape that produces "no longer" (hard rules 3 and
+// 4; the four recorded negative-prompt failures across two codebases).
+export { createStateRenderer } from "./timeline/render.js";
+// The turn reader (design §12 seam 3, GitHub issue #15) -- one model call per
+// unit of progress, answering the questions a server cannot answer with code.
+//
+// The engine owns the call, the citation rule, coercion to keys that actually
+// exist, the safe-direction default and the fallback ladder; the caller owns
+// the questions and the key vocabulary they are answered in. Answers come back
+// as KEYS, never prose.
+//
+// NOTE WHAT IS NOT HERE, BECAUSE IT IS THE POINT: no transport. A
+// `ReaderTransport` is a plain async function the CALLER writes and injects,
+// so this package contains no vendor SDK, no API key, no endpoint, and no
+// network code of any kind -- enforced mechanically by
+// `src/reader/__tests__/noVendorTransports.test.ts`, which scans this
+// directory for vendor and credential tokens the way the vocabulary test
+// scans for a consumer's language. The engine is provably ignorant of what is
+// on the other end of a rung, which is also why the ladder's ORDER is the
+// caller's: it never learns which rung is local and which is hosted.
+export { createTurnReader } from "./reader/turnReader.js";
+// Timeline export (design §6) -- the boundary that keeps both halves honest:
+// conversational authoring upstream of a frozen artifact, deterministic
+// consumers downstream of it. These are exported as library functions first
+// and served as MCP tools second, because the consumer that most needs them
+// is a process that must never call a model at runtime.
+export { exportTimeline, importTimeline, exportTimelineToFile, importTimelineFromFile, TIMELINE_FORMAT_VERSION, } from "./timeline/export.js";
+export { ENTITY_KINDS } from "./timeline/kinds.js";
+// The web UI's port helpers -- no RPG dependency, so they stay here. The web
+// UI server itself (`createHttpServer`/`startHttpServer`) imports quest,
+// ability and combat tools and is exported from "run-dmcp/rpg" instead
+// (src/rpg/index.ts), even though the file that implements it stays at
+// src/http/server.ts on disk.
+export { DEFAULT_HTTP_PORT, httpPortFromEnv, webUiEnabled, setHttpPort, getWebUiBaseUrl, } from "./utils/webui.js";

package/dist/mcp-server.d.ts

@@ -0,0 +1,49 @@
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { type Mechanic } from "./timeline/resolve.js";
+import { type RenderVocabulary } from "./timeline/render.js";
+export declare const SERVER_NAME = "dmcp";
+export declare const SERVER_VERSION = "0.2.0";
+/**
+ * Build an MCP server with every CORE tool, resource and prompt this engine
+ * serves -- entities, facts, events, the timeline, and the entity/property
+ * domains (resources, relationships, factions, secrets, locations, items)
+ * design §8 keeps out of the RPG layer because a consumer that lost them
+ * would have to drag that layer back in to get them. No dice, no combat, no
+ * abilities, no status effects, no random tables, no quests, and no
+ * game-master prompt library -- those are `registerRpgTools` in
+ * src/rpg/index.ts, which calls this function first and adds its layer on
+ * top of what it returns. `createMcpServer` there is the full assembly this
+ * function used to be, under the same name, with the same behaviour, so
+ * nothing that already depends on the full server sees any difference.
+ *
+ * The returned server is not connected to anything. Connect it to a transport
+ * yourself, and call `initializeSchema()` before serving a request -- both are
+ * the caller's to decide, and neither happens on import.
+ *
+ * `mechanics` (design §5.2a, issue #10) is injection at construction, the
+ * same way `initializeSchema({ migrations })` (src/db/schema.ts) is -- there
+ * is no global resolver anywhere in this codebase, only the one a caller
+ * builds by passing its mechanics here. Every existing zero-argument call
+ * site (src/bin/run-dmcp.ts, via src/rpg/index.ts) keeps working unchanged:
+ * `options` and `options.mechanics` are both optional, and calling
+ * `createCoreMcpServer()` with nothing at all registers every core tool this
+ * engine serves and no resolve surface. That absence is deliberate, not an
+ * oversight -- an engine with no mechanics registered has nothing a
+ * `resolve` tool could ever dispatch, so it gets no `resolve`/`list_mechanics`
+ * tools rather than a pair that could only ever answer "unknown-mechanic"
+ * and "[]".
+ *
+ * `vocabulary` (design §7, issue #16) is injected the same way and for the
+ * same reason -- and here the injection is not merely a style choice, it is
+ * the design's own line: the state-to-text projection's MECHANISM is core,
+ * and the NOUNS it may emit belong to each caller. A vocabulary rich enough
+ * to render a real world would fail this engine's vocabulary hygiene test on
+ * day one, correctly, so this package ships none and there is no default to
+ * fall back to. An engine with no vocabulary injected has nothing it could
+ * name, so it registers no `render_state_at` tool at all -- the identical
+ * shape (and the identical silence) as `mechanics` above.
+ */
+export declare function createCoreMcpServer(options?: {
+    mechanics?: readonly Mechanic[];
+    vocabulary?: RenderVocabulary;
+}): McpServer;

package/dist/mcp-server.js

@@ -0,0 +1,127 @@
+// The CORE MCP server, built but not started.
+//
+// This module exists so that "which tools does this engine serve" is separable
+// from "and now go listen on stdio and bind a port". Constructing the server
+// opens no database, binds no port and connects no transport; a caller decides
+// all three. src/bin/run-dmcp.ts is the caller that decides them the way an
+// application would.
+//
+// This is the CORE half of design §8's split (issue #17): entities, facts,
+// events, the timeline, resource/relationship/faction/secret/location/item
+// concepts, and the resolve/render/timeline surfaces that sit on top of them.
+// Dice, combat, abilities, status effects, random tables and quests are
+// genuinely game-shaped and live one layer up, in src/rpg/index.ts, which
+// calls `registerRpgTools(server)` on a server this file already built.
+// `createMcpServer` (the full assembly, unchanged in name and behaviour from
+// before the split) lives there too now, not here -- this file only knows
+// how to build the core.
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+// Import registration functions
+import { registerCoreTools } from "./register/core.js";
+import { registerWorldTools } from "./register/world.js";
+import { registerCharacterTools } from "./register/character.js";
+import { registerInventoryTools } from "./register/inventory.js";
+import { registerNarrativeTools } from "./register/narrative.js";
+import { registerResourceTools } from "./register/resources.js";
+import { registerTimeTools } from "./register/time.js";
+import { registerSecretTools } from "./register/secrets.js";
+import { registerRelationshipTools } from "./register/relationships.js";
+import { registerTagTools } from "./register/tags.js";
+import { registerFactionTools } from "./register/factions.js";
+import { registerNoteTools } from "./register/notes.js";
+import { registerPauseTools } from "./register/pause.js";
+import { registerImageTools } from "./register/images.js";
+import { registerAudioTools } from "./register/audio.js";
+import { registerDisplayTools } from "./register/display.js";
+import { registerBatchTools } from "./register/batch.js";
+import { registerMcpResources } from "./register/mcp-resources.js";
+import { registerTimelineTools } from "./register/timeline.js";
+import { registerResolveTools } from "./register/resolve.js";
+import { registerRenderTools } from "./register/render.js";
+import { createResolver } from "./timeline/resolve.js";
+import { createStateRenderer } from "./timeline/render.js";
+export const SERVER_NAME = "dmcp";
+export const SERVER_VERSION = "0.2.0";
+/**
+ * Build an MCP server with every CORE tool, resource and prompt this engine
+ * serves -- entities, facts, events, the timeline, and the entity/property
+ * domains (resources, relationships, factions, secrets, locations, items)
+ * design §8 keeps out of the RPG layer because a consumer that lost them
+ * would have to drag that layer back in to get them. No dice, no combat, no
+ * abilities, no status effects, no random tables, no quests, and no
+ * game-master prompt library -- those are `registerRpgTools` in
+ * src/rpg/index.ts, which calls this function first and adds its layer on
+ * top of what it returns. `createMcpServer` there is the full assembly this
+ * function used to be, under the same name, with the same behaviour, so
+ * nothing that already depends on the full server sees any difference.
+ *
+ * The returned server is not connected to anything. Connect it to a transport
+ * yourself, and call `initializeSchema()` before serving a request -- both are
+ * the caller's to decide, and neither happens on import.
+ *
+ * `mechanics` (design §5.2a, issue #10) is injection at construction, the
+ * same way `initializeSchema({ migrations })` (src/db/schema.ts) is -- there
+ * is no global resolver anywhere in this codebase, only the one a caller
+ * builds by passing its mechanics here. Every existing zero-argument call
+ * site (src/bin/run-dmcp.ts, via src/rpg/index.ts) keeps working unchanged:
+ * `options` and `options.mechanics` are both optional, and calling
+ * `createCoreMcpServer()` with nothing at all registers every core tool this
+ * engine serves and no resolve surface. That absence is deliberate, not an
+ * oversight -- an engine with no mechanics registered has nothing a
+ * `resolve` tool could ever dispatch, so it gets no `resolve`/`list_mechanics`
+ * tools rather than a pair that could only ever answer "unknown-mechanic"
+ * and "[]".
+ *
+ * `vocabulary` (design §7, issue #16) is injected the same way and for the
+ * same reason -- and here the injection is not merely a style choice, it is
+ * the design's own line: the state-to-text projection's MECHANISM is core,
+ * and the NOUNS it may emit belong to each caller. A vocabulary rich enough
+ * to render a real world would fail this engine's vocabulary hygiene test on
+ * day one, correctly, so this package ships none and there is no default to
+ * fall back to. An engine with no vocabulary injected has nothing it could
+ * name, so it registers no `render_state_at` tool at all -- the identical
+ * shape (and the identical silence) as `mechanics` above.
+ */
+export function createCoreMcpServer(options) {
+    const server = new McpServer({
+        name: SERVER_NAME,
+        version: SERVER_VERSION,
+    });
+    // Register all core tools by domain
+    registerCoreTools(server); // Game, Interview, Rules
+    registerWorldTools(server); // Locations, Connections, Map
+    registerCharacterTools(server); // Characters (PC/NPC)
+    registerInventoryTools(server); // Items
+    registerNarrativeTools(server); // Events, History, Export, Player Choices
+    registerResourceTools(server); // Custom Resources
+    registerTimeTools(server); // Calendar, Time, Timers
+    registerSecretTools(server); // Secrets, Knowledge
+    registerRelationshipTools(server); // Relationships
+    registerTagTools(server); // Tags
+    registerFactionTools(server); // Factions
+    registerNoteTools(server); // Game Notes
+    registerPauseTools(server); // Pause/Resume, Context Snapshots, External Updates
+    registerImageTools(server); // Stored Images
+    registerAudioTools(server); // Stored Audio (TTS, Voice References)
+    registerDisplayTools(server); // Display/Theme Configuration
+    registerBatchTools(server); // Batch Operations (multi-entity, workflows -- entity/property only)
+    registerTimelineTools(server); // replay(t), story-time axis declaration
+    const mechanics = options?.mechanics;
+    if (mechanics && mechanics.length > 0) {
+        const resolver = createResolver({ mechanics });
+        registerResolveTools(server, resolver); // resolve(), list_mechanics -- only when mechanics are registered
+    }
+    const vocabulary = options?.vocabulary;
+    if (vocabulary) {
+        // Built here rather than accepted pre-built so the vocabulary is
+        // validated at construction of the SERVER too, not merely at
+        // construction of a renderer a caller might have made anywhere:
+        // `createStateRenderer` throws on a malformed vocabulary, so a server
+        // that would have served an unnameable projection never comes up.
+        registerRenderTools(server, createStateRenderer({ vocabulary })); // render_state_at -- only when a vocabulary is injected
+    }
+    // Register core MCP Resources (RPG resources -- game-quests, quest -- are
+    // registered by registerRpgMcpResources, one layer up)
+    registerMcpResources(server); // Read-only data access via URI
+    return server;
+}