run-dmcp 0.3.0 → 0.5.0

package/dist/register/world.js

@@ -1,7 +1,7 @@
 import { z } from "zod";
 import * as worldTools from "../tools/world.js";
 import { imageGenSchema } from "../schemas/index.js";
-import { LIMITS } from "../utils/validation.js";
+import { LIMITS, validatedSchemas } from "../utils/validation.js";
 import { ANNOTATIONS } from "../utils/tool-annotations.js";
 export function registerWorldTools(server) {
     server.registerTool("create_location", {
@@ -26,7 +26,7 @@ export function registerWorldTools(server) {
     server.registerTool("get_location", {
         description: "Get location details",
         inputSchema: {
-            locationId: z.string().describe("The location ID"),
+            locationId: validatedSchemas.id.describe("The location ID"),
         },
         annotations: ANNOTATIONS.READ_ONLY,
     }, async ({ locationId }) => {
@@ -44,9 +44,9 @@ export function registerWorldTools(server) {
     server.registerTool("update_location", {
         description: "Update a location",
         inputSchema: {
-            locationId: z.string().describe("The location ID"),
-            name: z.string().optional().describe("New name"),
-            description: z.string().optional().describe("New description"),
+            locationId: validatedSchemas.id.describe("The location ID"),
+            name: validatedSchemas.token.optional().describe("New name"),
+            description: validatedSchemas.description.optional().describe("New description"),
             properties: z.record(z.string(), z.unknown()).optional().describe("Property updates"),
             imageGen: imageGenSchema.nullable().optional().describe("Image generation metadata (null to remove)"),
         },
@@ -66,7 +66,7 @@ export function registerWorldTools(server) {
     server.registerTool("list_locations", {
         description: "List all locations in a game",
         inputSchema: {
-            gameId: z.string().describe("The game ID"),
+            gameId: validatedSchemas.id.describe("The game ID"),
         },
         annotations: ANNOTATIONS.READ_ONLY,
     }, async ({ gameId }) => {
@@ -78,11 +78,11 @@ export function registerWorldTools(server) {
     server.registerTool("connect_locations", {
         description: "Create exits/paths between two locations. Call this whenever you describe how locations connect to each other - the player should be able to navigate based on database connections.",
         inputSchema: {
-            fromLocationId: z.string().describe("First location ID"),
-            toLocationId: z.string().describe("Second location ID"),
-            fromDirection: z.string().describe("Direction from first location (e.g., 'north', 'up', 'through the door')"),
-            toDirection: z.string().describe("Direction from second location back (e.g., 'south', 'down')"),
-            description: z.string().optional().describe("Description of the path"),
+            fromLocationId: validatedSchemas.id.describe("First location ID"),
+            toLocationId: validatedSchemas.id.describe("Second location ID"),
+            fromDirection: validatedSchemas.token.describe("Direction from first location (e.g., 'north', 'up', 'through the door')"),
+            toDirection: validatedSchemas.token.describe("Direction from second location back (e.g., 'south', 'down')"),
+            description: validatedSchemas.description.optional().describe("Description of the path"),
             bidirectional: z.boolean().optional().describe("Create exit in both directions (default: true)"),
         },
         annotations: ANNOTATIONS.CREATE,
@@ -108,8 +108,8 @@ export function registerWorldTools(server) {
     server.registerTool("get_location_by_name", {
         description: "Look up a location by name within a game. Supports exact, partial, and fuzzy matching. Returns the best match or an error if no reasonable match found.",
         inputSchema: {
-            gameId: z.string().describe("The game ID to search within"),
-            name: z.string().describe("Location name to search for (case-insensitive)"),
+            gameId: validatedSchemas.id.describe("The game ID to search within"),
+            name: validatedSchemas.token.describe("Location name to search for (case-insensitive)"),
         },
         annotations: ANNOTATIONS.READ_ONLY,
     }, async ({ gameId, name }) => {

package/dist/rpg/index.d.ts

@@ -1,26 +1,10 @@
 import type { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import type { Mechanic } from "../timeline/resolve.js";
-import type { RenderVocabulary } from "../timeline/render.js";
 /**
  * Register every RPG-layer tool, resource and prompt onto an existing
  * server. Combat brings dice with it (registerCombatTools registers both,
  * matching how the pre-split assembly registered them as one domain).
  */
 export declare function registerRpgTools(server: McpServer): void;
-/**
- * Build the FULL assembly: every core tool plus every RPG tool, resource and
- * prompt this engine has always served. Same name, same `{ mechanics?,
- * vocabulary? }` options as the pre-split `createMcpServer` in
- * src/mcp-server.ts -- this is that function, now composed from two layers
- * instead of one, so src/bin/run-dmcp.ts's zero-argument call site keeps
- * working unchanged and the registered tool/resource/prompt set is
- * unchanged too (src/__tests__/layerBoundary.test.ts asserts this exactly).
- */
-export declare function createMcpServer(options?: {
-    mechanics?: readonly Mechanic[];
-    vocabulary?: RenderVocabulary;
-}): McpServer;
-export { createHttpServer, startHttpServer } from "../http/server.js";
 export * from "./tools/dice.js";
 export * from "./tools/combat.js";
 export * from "./tools/ability.js";

package/dist/rpg/index.js

@@ -1,4 +1,3 @@
-import { createCoreMcpServer } from "../mcp-server.js";
 import { registerCombatTools } from "./register/combat.js";
 import { registerAbilityTools } from "./register/abilities.js";
 import { registerStatusTools } from "./register/status.js";
@@ -22,27 +21,10 @@ export function registerRpgTools(server) {
     registerRpgMcpResources(server); // game-quests, quest
     registerMcpPrompts(server); // Reusable prompt templates (game-master session library)
 }
-/**
- * Build the FULL assembly: every core tool plus every RPG tool, resource and
- * prompt this engine has always served. Same name, same `{ mechanics?,
- * vocabulary? }` options as the pre-split `createMcpServer` in
- * src/mcp-server.ts -- this is that function, now composed from two layers
- * instead of one, so src/bin/run-dmcp.ts's zero-argument call site keeps
- * working unchanged and the registered tool/resource/prompt set is
- * unchanged too (src/__tests__/layerBoundary.test.ts asserts this exactly).
- */
-export function createMcpServer(options) {
-    const server = createCoreMcpServer(options);
-    registerRpgTools(server);
-    return server;
-}
-// The web UI. An application opts into serving it; importing this never
-// does. It lives on disk at src/http/server.ts, not under src/rpg/ -- it
-// imports RPG tools (quest/ability/combat), which is why it cannot be
-// reachable from the core entry point, but its CLIENT_DIST path resolution
-// is depth-sensitive in both src/ and compiled dist/, so it stays put and
-// only its EXPORT moves up to this layer.
-export { createHttpServer, startHttpServer } from "../http/server.js";
+// `createMcpServer` and the web UI are NOT here. Both are assembly, and both
+// moved to "run-dmcp/rpg/server" (src/rpg/server.ts) so that importing the
+// layer's tool functions stops loading a server and an HTTP framework with
+// them.
 // The RPG tool modules, exported as library functions -- the same shape
 // core's index.ts uses for the timeline (replay, changesWithin, and so on):
 // a consumer that wants to call combat/quest/table/status/ability/dice logic

package/dist/rpg/register/batch.js

@@ -2,7 +2,7 @@ import { z } from "zod";
 import * as characterTools from "../../tools/character.js";
 import * as narrativeTools from "../../tools/narrative.js";
 import * as combatTools from "../tools/combat.js";
-import { LIMITS } from "../../utils/validation.js";
+import { LIMITS, validatedSchemas } from "../../utils/validation.js";
 import { ANNOTATIONS } from "../../utils/tool-annotations.js";
 // The one multi-entity workflow tool that reaches into combat, split out of
 // src/register/batch.ts (design §8, issue #17): everything else there --
@@ -17,8 +17,8 @@ export function registerRpgBatchTools(server) {
     server.registerTool("setup_combat_encounter", {
         description: "Complete combat setup in one call: creates enemy NPCs and starts combat with all participants (enemies + players at location). Returns the ready-to-play combat state.",
         inputSchema: {
-            gameId: z.string().describe("The game ID"),
-            locationId: z.string().describe("Location where combat takes place"),
+            gameId: validatedSchemas.id.describe("The game ID"),
+            locationId: validatedSchemas.id.describe("Location where combat takes place"),
             enemies: z
                 .array(z.object({
                 name: z.string().min(1).max(LIMITS.NAME_MAX).describe("Enemy name"),

package/dist/rpg/server.d.ts

@@ -0,0 +1,16 @@
+import type { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import type { Mechanic } from "../timeline/resolve.js";
+import type { RenderVocabulary } from "../timeline/render.js";
+/**
+ * Build the FULL assembly: every core tool plus every RPG tool, resource and
+ * prompt this engine has always served. Same name and same `{ mechanics?,
+ * vocabulary? }` options as the pre-split `createMcpServer` in
+ * src/mcp-server.ts, so src/bin/run-dmcp.ts's zero-argument call site keeps
+ * working unchanged and the registered tool/resource/prompt set is unchanged
+ * too (src/__tests__/layerBoundary.test.ts asserts this exactly).
+ */
+export declare function createMcpServer(options?: {
+    mechanics?: readonly Mechanic[];
+    vocabulary?: RenderVocabulary;
+}): McpServer;
+export { createHttpServer, startHttpServer } from "../http/server.js";

package/dist/rpg/server.js

@@ -0,0 +1,22 @@
+import { createCoreMcpServer } from "../mcp-server.js";
+import { registerRpgTools } from "./index.js";
+/**
+ * Build the FULL assembly: every core tool plus every RPG tool, resource and
+ * prompt this engine has always served. Same name and same `{ mechanics?,
+ * vocabulary? }` options as the pre-split `createMcpServer` in
+ * src/mcp-server.ts, so src/bin/run-dmcp.ts's zero-argument call site keeps
+ * working unchanged and the registered tool/resource/prompt set is unchanged
+ * too (src/__tests__/layerBoundary.test.ts asserts this exactly).
+ */
+export function createMcpServer(options) {
+    const server = createCoreMcpServer(options);
+    registerRpgTools(server);
+    return server;
+}
+// The web UI. An application opts into serving it; importing this never
+// does. It lives on disk at src/http/server.ts, not under src/rpg/ -- it
+// imports RPG tools (quest/ability/combat), which is why it cannot be
+// reachable from the core entry point, but its CLIENT_DIST path resolution
+// is depth-sensitive in both src/ and compiled dist/, so it stays put and
+// only its EXPORT moves up to this layer.
+export { createHttpServer, startHttpServer } from "../http/server.js";