@thehammer/danx-dashboard-mcp 0.1.170 → 0.1.172

package/dist/index.js

@@ -84,7 +84,7 @@ import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"
 import { z } from "zod";
 import { DashboardHttpClient } from "./http-client.js";
 import { planConnect, danxbotApi, danxbotApiList, danxbotApiSpec, attachFile, DANXBOT_API_METHODS, } from "./handlers.js";
-import { queryValueSchema } from "./types.js";
+import { bodyValueSchema, queryValueSchema } from "./types.js";
 import { registerLifecycleTools, applyLifecycleVisibility, readLifecycleUrlsFromEnv, } from "./lifecycle.js";
 function readEnvOrDie(name) {
     const v = process.env[name];
@@ -348,7 +348,16 @@ strictTool("danxbot_api", "Call any dashboard API route your credential may reac
     // elements are restricted to scalars, the only thing a comma-join can
     // represent losslessly.
     query: queryValueSchema.optional(),
-    body: z.unknown().optional(),
+    // DX-3685 — was `z.unknown()` (JSON Schema `{}`), which gave the model
+    // no structural hint that a body must be an OBJECT, so it sometimes
+    // sent `body` as a JSON-encoded string; `http-client.ts` then
+    // `JSON.stringify`'d that string again, and every dashboard route
+    // refused the resulting JSON-string-literal body with `body: must be an
+    // object` (every route's body schema is object-only — see
+    // `bodyValueSchema`'s own doc in `types.ts`). A string/array/etc body
+    // now fails zod validation at this boundary with a clear message
+    // instead of reaching the dashboard malformed.
+    body: bodyValueSchema.optional(),
     ...boardField,
 }, async (args) => jsonResult(await danxbotApi(client, args)));
 // ---------------- danxbot_api_list (DX-3465 A5, PLN-11 R-25) ----------------

package/dist/types.js

@@ -14,3 +14,33 @@ export const queryValueSchema = z.record(z.union([
     z.record(z.unknown()),
     z.array(z.union([z.string(), z.number(), z.boolean()])),
 ]));
+/**
+ * DX-3685 — the zod schema for `danxbot_api`'s `body` argument. Every
+ * dashboard route that takes a body validates it against a
+ * `BodyObjectSchema` (`src/http/body-schema.ts`, this repo) whose top-level
+ * `type` is ALWAYS `"object"` — no route ever accepts a body that is a
+ * string, an array, or any other JSON type at the top level (a plain-object
+ * request is the ONLY shape `validateBody`'s `"object"` case accepts; every
+ * other top-level shape hits its `body: must be an object` refusal).
+ *
+ * The previous schema, `z.unknown()`, compiles to `{}` in the tool's
+ * published JSON Schema — "any value, no structural hint at all" — which
+ * gave the calling model zero signal that an OBJECT was expected. In
+ * production this meant the model sometimes serialized `body` as a
+ * JSON-encoded STRING (e.g. `'{"text":"test"}'` instead of
+ * `{text:"test"}`); `http-client.ts#request` then ran `JSON.stringify` on
+ * that already-stringified value, producing a JSON STRING LITERAL as the
+ * wire body instead of a JSON object, which the dashboard's shared body
+ * validator correctly rejected with `body: must be an object` on every
+ * write (DX-3685).
+ *
+ * `z.record(z.unknown())` (the same idiom `queryValueSchema` above uses for
+ * its own field-tree branch) both (a) advertises `type: "object"` in the
+ * published JSON Schema, giving the model the structural hint it was
+ * missing, and (b) makes zod itself refuse a string/array/number/etc body
+ * at the MCP validation boundary with a clear, actionable
+ * `Expected object, received string`-class error — never silently
+ * forwarded, and never auto-`JSON.parse`d back into shape (Core Principle 1
+ * forbids tolerating a second input shape).
+ */
+export const bodyValueSchema = z.record(z.unknown());

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thehammer/danx-dashboard-mcp",
-  "version": "0.1.170",
+  "version": "0.1.172",
   "description": "Stdio MCP server fronting danxbot's dashboard API for agents (operator sessions and dispatched workers alike): the generic danxbot_api/danxbot_api_list/danxbot_api_spec tools reach any route the caller's credential may call, plus dedicated agent-specific tools (plan_connect, danxbot_complete, and other per-dispatch lifecycle callbacks) (DX-3465, PLN-11 R-25).",
   "license": "MIT",
   "type": "module",