wontopos-mcp 1.0.7 → 1.0.8

package/README.md

@@ -107,6 +107,33 @@ automatic retries, redirect refusal, response caps, and key hygiene apply as-is.
 
 ## Changelog
 
+- **1.0.8** - two bugs found by driving the server over stdio rather than reading
+  it. A store id with stray whitespace **split the store in two**: the client was
+  built from the raw env while the boot check, the ready line and `create_store`
+  used the trimmed value, so `create_store` made `alice` while every read and write
+  went to `" alice \n"` — a different collection — and the console still printed
+  `store "alice" verified`. And an oversized result was capped by slicing the
+  serialized JSON, handing the model a fragment with no closing bracket and a final
+  memory cut mid-sentence (measured: 131,041 bytes of unparseable text from a 764 KB
+  search). Now whole entries are dropped instead, the reply stays valid JSON, and
+  what was dropped is stated in the payload — a truncation nobody can see is worse
+  than a short answer.
+- **1.0.7** - the version in the MCP handshake is read from `package.json` instead
+  of a hand-kept copy (1.0.6 announced itself as "1.0.5", so hosts logged and bug
+  reports cited the wrong build). `event_date` accepts a plain date: the API needs a
+  full RFC3339 date-TIME and answered a bare `2026-03-14` with an opaque 400 — the
+  form a model naturally emits, and the one this tool's own example suggested. A
+  date-only value is completed by string append, never through `Date`, so the stated
+  day cannot shift a zone. `remember` now says dedup matches by MEANING, not exact
+  text, and what to do when a new fact only narrows an existing one.
+- **1.0.6** - `engram` takes a plain string, not an enum pinned to the original
+  three: every engram the service added afterwards was uncallable from here until
+  this package was republished. The API validates the name and answers 400 with the
+  list it accepts, so a new engram works the day it ships. The store fallback is no
+  longer silent — if `WONTOPOS_USER_ID` never reaches the process, everything goes to
+  `default`, and since every account is seeded with a `default` store the boot check
+  SUCCEEDS while the configured store sits untouched. Both the ready line and the
+  boot check now say so out loud.
 - **1.0.5** - correctness on the caps: they are now measured in UTF-8 **bytes**,
   not JS chars, so "128 KB" holds for Korean/CJK (a char cap let ~384 KB of
   Korean through). Result 128 KB, error 2 KB, content 8 KB, query 8 KB — all

package/index.mjs

@@ -107,7 +107,14 @@ const model = process.env.WONTOPOS_MODEL?.trim();
 
 const mem = new Client({
   apiKey,
-  userId: process.env.WONTOPOS_USER_ID || "default",
+  // STORE, not the raw env: the value is trimmed once at the top and everything —
+  // the boot check, the "ready" line, create_store — speaks in terms of that. Reading
+  // the env again here re-introduced the untrimmed value, so a config with a stray
+  // space or newline (easy in JSON/YAML env blocks, and heredocs add one) SPLIT the
+  // store in two: create_store made "alice" while every read and write went to
+  // " alice \n", which the API sanitizes into a different collection entirely — and
+  // the console still printed 'store "alice" verified'. One value, one store.
+  userId: STORE,
   // A stalled API must fail fast and in-band, not dangle until the MCP host
   // gives up. 20s covers a slow engram; override with WONTOPOS_TIMEOUT_MS.
   timeoutMs,
@@ -117,20 +124,75 @@ const mem = new Client({
 
 const server = new McpServer({ name: "wontopos", version: VERSION });
 
+/** The result fields that hold lists of memories. Trimming happens here first,
+ *  because dropping whole entries keeps the reply parseable. */
+const LIST_FIELDS = ["memories", "self_memories", "results", "turns", "context"];
+
+/** Shrink a result until it fits the byte cap, WITHOUT breaking the JSON.
+ *
+ *  Cutting the serialized string mid-array (what this used to do) hands the model
+ *  a fragment: no closing bracket, and a final memory sliced mid-sentence that
+ *  reads as if that is all it said. Measured: a 764KB search came back as 131,041
+ *  bytes of unparseable text. Drop whole entries instead and say how many went,
+ *  so what arrives is valid JSON and its incompleteness is a stated fact.
+ *  Returns the text to send. */
+function fitToCap(result) {
+  const ser = (v) => JSON.stringify(v, null, 1);
+  let text = ser(result);
+  if (byteLen(text) <= MAX_RESULT_BYTES) return text;
+
+  // Trim the largest list field, longest-first, halving until it fits.
+  if (result && typeof result === "object") {
+    const clone = Array.isArray(result) ? [...result] : { ...result };
+    const dropped = {};
+    const lists = Array.isArray(clone)
+      ? [["", clone]]
+      : LIST_FIELDS.filter((f) => Array.isArray(clone[f]) && clone[f].length).map((f) => [f, clone[f]]);
+    if (lists.length) {
+      // Shrink every list proportionally until the whole payload fits. A plain
+      // loop, not a clever estimate: entry sizes vary wildly (one 8KB memory next
+      // to twenty short ones) so measuring is the only honest stop condition.
+      let guard = 64;
+      while (byteLen(text) > MAX_RESULT_BYTES && guard-- > 0) {
+        let cutAny = false;
+        for (const [name, arr] of lists) {
+          if (arr.length <= 1) continue;
+          const keep = Math.max(1, Math.floor(arr.length / 2));
+          dropped[name || "items"] = (dropped[name || "items"] ?? 0) + (arr.length - keep);
+          arr.length = keep;
+          cutAny = true;
+        }
+        if (!cutAny) break;
+        text = ser(Array.isArray(clone) ? clone : { ...clone, _truncated: dropped });
+      }
+      if (byteLen(text) <= MAX_RESULT_BYTES) {
+        const note =
+          `dropped ${Object.entries(dropped).map(([k, n]) => `${n} ${k}`).join(", ")} to fit the ` +
+          `${MAX_RESULT_BYTES}-byte cap — narrow the query, lower limit, or page with cursor.`;
+        // An array result (search) has nowhere to hang a note, so the cut would be
+        // SILENT — the model would read a short list as the whole answer. Append a
+        // sentinel entry instead: still valid JSON, still an array, and the reader
+        // is told what is missing. A truncation nobody can see is the worse bug.
+        return Array.isArray(clone) ? ser([...clone, { _truncated: note }]) : ser({ ...clone, _truncated: note });
+      }
+    }
+  }
+  // Last resort — a single entry too big to drop (one 400KB memory): the string
+  // cut, still labelled. Reserve the note's REAL byte length, not a guessed 160:
+  // the note grew past that guess and pushed the reply back over the cap, which is
+  // what the existing byte-cap tests caught.
+  const note =
+    `\n…[response truncated: ${byteLen(text)} bytes exceeded the ${MAX_RESULT_BYTES}-byte cap. ` +
+    "Narrow the query, lower limit, or page with cursor. NOTE: this text is a fragment, not valid JSON.]";
+  return truncateToBytes(text, MAX_RESULT_BYTES - byteLen(note)) + note;
+}
+
 /** Wrap a handler: JSON out, typed WosError in-band so the agent can react. */
 function run(fn) {
   return async (args) => {
     try {
       const result = await fn(args ?? {});
-      let text = JSON.stringify(result, null, 1);
-      const bytes = byteLen(text);
-      if (bytes > MAX_RESULT_BYTES) {
-        // Leave room for the note itself so the whole reply stays under the cap.
-        text =
-          truncateToBytes(text, MAX_RESULT_BYTES - 160) +
-          `\n…[response truncated: ${bytes} bytes exceeded the ${MAX_RESULT_BYTES}-byte cap. ` +
-          "Narrow the query, lower limit, or page with cursor.]";
-      }
+      const text = fitToCap(result);
       return { content: [{ type: "text", text }] };
     } catch (e) {
       // WosError.message already carries "[status] ... (request_id: ...)".

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wontopos-mcp",
-  "version": "1.0.7",
+  "version": "1.0.8",
   "mcpName": "com.wontopos/mcp",
   "description": "(beta) Wontopos (WOS) long-term memory as an MCP server — one memory across Claude Code, Claude Desktop, Cursor, ChatGPT, and your own agents.",
   "keywords": [