@mnemoverse/mcp-memory-server 0.10.2 → 0.11.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js CHANGED
@@ -2,62 +2,16 @@
2
2
  import { createRequire } from "node:module";
3
3
  import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
4
4
  import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
5
- import { z } from "zod";
6
- import { formatReadItem, formatRecentPage, safeInline, } from "./render.js";
7
- // `NO_MATCH_MESSAGE` is no longer imported here: this file used to pick between
8
- // it and buildReadEmptyResponse by testing a note string for truthiness, which
9
- // is how "we could not check" came to be spelled like "the store is there".
10
- // Assembling the whole answer belongs in one place — src/teaching.ts.
11
- import { SERVER_INSTRUCTIONS, buildReadEmptyResponse } from "./teaching.js";
12
- import { classifyRooms, futureSinceNote, probeReadScope, readScopeNote, scopeLabel, } from "./scope.js";
13
- import { readRequestBody, recentRequestBody, writeRequestBody, searchedScope, refusePlaceholderKey, } from "./requests.js";
14
- import { exactLiteral, formatDomainList, roomNamePhrase, withDomainEscapeLegend, } from "./names.js";
5
+ import { SERVER_INSTRUCTIONS } from "./teaching.js";
6
+ import { refusePlaceholderKey } from "./requests.js";
7
+ import { registerMemoryTools } from "./tools.js";
8
+ import { registerMemoryPrompts } from "./prompts.js";
9
+ import { registerMemoryResources } from "./resources.js";
15
10
  // Every non-2xx becomes an instruction to the calling model instead of a raw
16
11
  // wire echo — see the header of src/errors.ts for why, and for what each status
17
12
  // actually means in this engine. So does a 2xx whose body this client cannot
18
13
  // parse, which is a third case and not a variant of either of the other two.
19
14
  import { ApiError, NetworkError, UnreadableBodyError } from "./errors.js";
20
- /**
21
- * What we know about the scope this read actually covered — a VALUE rather
22
- * than a sentence-or-empty-string. Costs one GET (rooms or stats, chosen by
23
- * the scope) and runs on zero-result paths only — but it is not that path's
24
- * only probe: the plain unscoped empty read also hands buildReadEmptyResponse
25
- * a stats call for the first-contact greeting, so that answer makes two
26
- * probes where 0.8.0 made one, and the scoped/filtered answers make one where
27
- * 0.8.0 made none. Disclosed in the 0.8.1 CHANGELOG entry.
28
- *
29
- * This replaces `domainMissNote`, whose `catch { return ""; }` made three
30
- * different states share one spelling: the store is there and the query missed,
31
- * the room is there and the query missed, and the probe failed. The caller then
32
- * read that string as a boolean, so "we could not check" was rendered exactly
33
- * like "the store exists" — the collision this release is about, at the point
34
- * where the whole scoped path converges. The states are now arms of a union
35
- * (src/scope.ts) and every consumer must answer for each of them.
36
- *
37
- * The probe routing lives in src/scope.ts: a room address is checked against the
38
- * ROOM list and a domain against `/memory/stats`, because stats never contains a
39
- * room address (CodeRabbit #65). `searched` is the RAW value that went over the
40
- * wire, so the diagnosis can never describe a different store than the request.
41
- */
42
- /**
43
- * How long a HONESTY PROBE may take before the answer goes out without it (#73).
44
- *
45
- * The probes are a courtesy: they let a zero-result answer say what it did NOT
46
- * cover. They are not the answer. Without a deadline they inherit undici's
47
- * default (~300s), so one slow engine endpoint turns an empty read — which
48
- * 0.8.0 answered instantly, having probed nothing — into a multi-minute stall.
49
- * `probeReadScope` already treats a failed probe as "unknown" and says so, so
50
- * an abort degrades into the honest fallback rather than an error.
51
- *
52
- * 4s is chosen against measured production latency: `/memory/read` averaged
53
- * 1,330 ms with a 10.2 s maximum (core observability, 2026-08), and these two
54
- * are cheaper GETs. Long enough not to fire on a normal slow day, short enough
55
- * that a hung endpoint costs seconds instead of minutes.
56
- */
57
- const PROBE_TIMEOUT_MS = 4000;
58
- function probeScope(searched) {
59
- return probeReadScope(searched, () => apiFetch("/memory/stats", { signal: AbortSignal.timeout(PROBE_TIMEOUT_MS) }), () => apiFetch("/memory/rooms", { signal: AbortSignal.timeout(PROBE_TIMEOUT_MS) }), safeInline);
60
- }
61
15
  // Version is read at runtime from package.json so there is exactly one place
62
16
  // to bump on each release. Works both from `dist/` during local dev and from
63
17
  // `node_modules/@mnemoverse/mcp-memory-server/dist/` after an npm install.
@@ -68,10 +22,6 @@ const pkg = require("../package.json");
68
22
  const DEFAULT_API_URL = "https://core.mnemoverse.com/api/v1";
69
23
  const API_URL = process.env.MNEMOVERSE_API_URL || DEFAULT_API_URL;
70
24
  const API_KEY = process.env.MNEMOVERSE_API_KEY || "";
71
- // Hard cap on tool result size — required by Claude Connectors Directory
72
- // (https://support.claude.com/en/articles/12922490-remote-mcp-server-submission-guide).
73
- // Approximate token count = chars / 4. Cap at 24,000 tokens to leave headroom under the 25K limit.
74
- const MAX_RESULT_CHARS = 24_000 * 4;
75
25
  /**
76
26
  * Is `MNEMOVERSE_API_URL` an address this client may attach the API key to —
77
27
  * and if not, what does the user have to change (#99, CWE-319)?
@@ -330,101 +280,6 @@ async function apiFetch(path, options = {}) {
330
280
  });
331
281
  }
332
282
  }
333
- /**
334
- * Truncate a result string to MAX_RESULT_CHARS, appending a notice if truncated.
335
- * Required by Claude Connectors Directory submission policy.
336
- *
337
- * Defensive against splitting UTF-16 surrogate pairs: if the character right
338
- * before the cut point is a high surrogate (U+D800–U+DBFF), drop it so the
339
- * result stays well-formed. Otherwise an emoji or non-BMP character at the
340
- * boundary can produce a lone surrogate and corrupt downstream JSON encoding.
341
- */
342
- function capResult(text,
343
- // The default recommends ONLY the control that works. A previous draft also
344
- // said "or smaller top_k" — but top_k is not a hard cap (association
345
- // expansion can return more, the relevance floor fewer; the same query at
346
- // 1/5/20 returned 6/7/4 items), which this release's own top_k description
347
- // already admits. One surface must not recommend the knob another refutes.
348
- moreHint = "Use a more specific query to see all results.") {
349
- if (text.length <= MAX_RESULT_CHARS)
350
- return text;
351
- let truncated = text.slice(0, MAX_RESULT_CHARS - 200);
352
- const lastCode = truncated.charCodeAt(truncated.length - 1);
353
- if (lastCode >= 0xd800 && lastCode <= 0xdbff) {
354
- truncated = truncated.slice(0, -1);
355
- }
356
- // `moreHint` lets no-input tools (the discovery lists) give accurate truncation
357
- // guidance instead of the read-tool default (which points at a query control a
358
- // repeated no-arg call cannot use). Existing callers keep the default message.
359
- return `${truncated}\n\n[…truncated to fit the 25K token limit. ${moreHint}]`;
360
- }
361
- /**
362
- * A 2xx whose body does not carry what core always sends for this operation.
363
- *
364
- * Reading such a body as an EMPTY list is the substitution this release exists
365
- * to remove: `Array.isArray(x) ? x : []` turned "this client could not read
366
- * the response" into "there is nothing there" — an absence claim on zero
367
- * evidence. `classifyRooms` (src/scope.ts) and the stats domains guard closed
368
- * it for rooms and domains; this builder is the same answer for the remaining
369
- * list surfaces (search results, the feed, the vault), phrased the way the
370
- * room list already phrases it. The three parts are the subject, what the body
371
- * is NOT ("a list of your rooms"), and the absence it is NOT evidence of
372
- * ("you have none") — so every consumer states its own boundary while the
373
- * sentence stays one sentence everywhere (truth F13, 2026-08-08).
374
- *
375
- * NOT ONLY LISTS any more: memory_write was the last surface still reading
376
- * a missing field as a stated one — `if (r?.stored)`, whose else-branch was an
377
- * unconditional "NOT STORED — nothing was saved" plus a mechanism nobody sent.
378
- * It is the same class of claim about a different shape, so it gets the same
379
- * sentence, and the name no longer says "List".
380
- *
381
- * `extra` exists for the write surface alone: a list that could not be read
382
- * leaves the caller merely uninformed, whereas a WRITE that could not be read
383
- * leaves an operation whose outcome is unknown, and the caller must be told not
384
- * to report either outcome to the user.
385
- */
386
- function unreadableAnswerReply(subject, notA, absence, extra = "") {
387
- return {
388
- content: [
389
- {
390
- type: "text",
391
- // The tail attributes the unreadable 200 to "whatever answered this
392
- // call", not to "the memory service" — this client cannot establish
393
- // WHO answered: a gateway, a proxy, or the endpoint a mis-set
394
- // MNEMOVERSE_API_URL points at produces the same 200 with an
395
- // unrecognised body (truth re-verification, 2026-08-09). Pinned in
396
- // test/handlers.test.ts.
397
- text: `${subject} came back in a shape this client does not recognise — so this ` +
398
- `is not ${notA}, and it is not evidence that ${absence}.${extra} Retry; ` +
399
- `if it persists, whatever answered this call — the memory service, a ` +
400
- `gateway or proxy in front of it, or the endpoint a mis-set ` +
401
- `MNEMOVERSE_API_URL points at — is answering in a shape this client ` +
402
- `cannot read.`,
403
- },
404
- ],
405
- };
406
- }
407
- /**
408
- * Two renderers, and which one a value gets is a decision, not a style choice.
409
- *
410
- * `safeInline` (src/render.ts) SANITISES an untrusted display string for inline
411
- * rendering in tool output that a DIFFERENT principal's LLM will read (CN-032
412
- * anti-injection): strip to a conservative charset, collapse whitespace, cap
413
- * the length. The treatment `formatAuthorTag` applies to a server-stamped
414
- * author, and the defensive second pass the machine-shaped room fields
415
- * (address, room_id, role, scope — all charset-validated or enum-shaped in
416
- * core) get here. It is lossy on purpose, and everything it still renders is a
417
- * value the reader looks at and never has to retype or compare.
418
- *
419
- * `exactLiteral` / `domainPhrase` / `roomNamePhrase` (src/names.ts) print a
420
- * value as a JSON string literal, or refuse to print it. Domain names because
421
- * the engine matches them byte-for-byte, so the reader must be able to send
422
- * the exact bytes back. Room NAMES (0.8.1) because the sanitiser did not make
423
- * them harmless so much as it made them WRONG: "проект" echoed back as `""` on
424
- * create, "Zoë" as "Zo" inside quotes that claim to be the name. The literal
425
- * is one line with quotes, backslashes and invisibles escaped, so it is as
426
- * injection-safe as the sanitised spelling was — without the renaming.
427
- */
428
283
  // --- Server setup ---
429
284
  // The second argument lands verbatim in the connected model's system prompt on
430
285
  // clients that surface MCP instructions — it is the single highest-leverage
@@ -439,1330 +294,14 @@ export const server = new McpServer({
439
294
  name: "mnemoverse-memory",
440
295
  version: pkg.version,
441
296
  }, { instructions: SERVER_INSTRUCTIONS });
442
- /**
443
- * True for a shared-room address (`xroom:<room_id>`).
444
- *
445
- * Mirrors core's own predicate (`memory_engine._is_room_domain`), which is a
446
- * plain prefix test — deliberately, so a padded or otherwise non-canonical
447
- * address does NOT normalise into a room. Byte-for-byte, no trimming: this
448
- * file's write handler documents at length why trimming a domain here once
449
- * nearly wrote into a room visible to other accounts.
450
- *
451
- * Used only to choose which TRUE sentence to print about a refusal. It never
452
- * changes what is sent, so a wrong answer here misinforms and cannot misroute.
453
- */
454
- function isRoomDomain(domain) {
455
- return typeof domain === "string" && domain.startsWith("xroom:");
456
- }
457
- /**
458
- * The three outcomes this client will ever print a WRITE promise about for a
459
- * room membership. Core grants exactly two scopes — "read" and "read_write"
460
- * (rooms_routes.py `_VALID_SCOPES`) — and refuses a read-only member's
461
- * memory_write with a 403 "Read-only membership cannot write to this room"
462
- * (src/errors.ts). Anything else on the wire (missing field, a Copilot-shaped
463
- * partial body) is UNSPECIFIED: the server did not say what memory_write would
464
- * do for this membership, so this client does not guess either — it is treated
465
- * like "read" for the purpose of NOT promising write, but is not told it is
466
- * read-only, because that is also a claim the response did not make.
467
- *
468
- * Bug hunt (pre-0.9.2, P2): memory_join_room's usage sentence and
469
- * memory_list_rooms's per-row tail both used to print "use domain=... [on
470
- * memory_write / memory_read] to read and write" unconditionally — true for a
471
- * read_write membership, false for a read-only one.
472
- */
473
- function roomScopeVerdict(scope) {
474
- if (scope === "read_write")
475
- return "read_write";
476
- if (scope === "read")
477
- return "read";
478
- return "unspecified";
479
- }
480
- // --- Tool: memory_write ---
481
- server.registerTool("memory_write", {
482
- description: "Store a long-term memory that persists across sessions AND across every AI tool the user has connected to Mnemoverse (Claude, ChatGPT, Cursor, VS Code) — write once, recall everywhere. Call this PROACTIVELY the moment the user states a preference, makes a decision, or you learn a durable fact (people, roles, project setup, a lesson). Don't wait to be asked. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records; skip transient chatter that only matters this turn. Behavior: an importance gate may filter low-value writes, so the result tells you whether the memory was stored or filtered. Write `content` as a self-contained statement that still makes sense when recalled out of context.",
483
- inputSchema: {
484
- content: z
485
- .string()
486
- .min(1)
487
- .max(10000)
488
- .describe("The memory to store as a self-contained statement, e.g. 'User prefers TypeScript strict mode' or 'Decided to deploy the API on Cloudflare Workers (2026-06)'."),
489
- concepts: z
490
- .array(z.string())
491
- .optional()
492
- .describe("Key concepts for linking related memories (e.g. ['deploy', 'friday', 'staging'])"),
493
- domain: z
494
- .string()
495
- .optional()
496
- .describe("Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme')." +
497
- " Matched byte-for-byte — a leading space, a different case, or an invisible" +
498
- " character opens a SEPARATE, permanent store, so reuse an exact name from" +
499
- " memory_stats rather than retyping one. To write into a shared room, pass its" +
500
- " address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with" +
501
- " memory_list_rooms."),
502
- },
503
- annotations: {
504
- title: "Store Memory",
505
- readOnlyHint: false,
506
- destructiveHint: false,
507
- idempotentHint: false,
508
- openWorldHint: true,
509
- },
510
- }, async ({ content, concepts, domain }) => {
511
- // NO NORMALISATION HERE — deliberately, after a review found two ways it
512
- // breaks (2026-08-08). Trimming looked like an obvious win: domain names
513
- // are matched byte-for-byte in core, so " engineering" opens a permanent
514
- // second store beside "engineering". But:
515
- //
516
- // 1. Core REJECTS a non-canonical room address on purpose — 400
517
- // "Non-canonical room address", so a write "can't be mis-routed and
518
- // tagged with a spoofed xroom domain" in its own words. Trimming
519
- // " xroom:room_01ABC" normalises past that guard, and the atom lands
520
- // in the ROOM's store, visible to every member. Content that never
521
- // left the caller in 0.8.0 would leave the account in 0.8.1. The
522
- // address in that shape is one our own output hands the model.
523
- // 2. For a caller who has been padding a domain for months, trimming
524
- // silently relocates new writes and orphans the old corpus, and (at
525
- // the time this was written) memory_delete_domain did NOT trim, so
526
- // the same client could no longer even name the shard it created —
527
- // that tool was withdrawn to an administrative REST-only operation
528
- // on 2026-08-20, so this specific consequence no longer applies, but
529
- // the orphaned-corpus risk from silently relocating writes does.
530
- //
531
- // Both are behaviour changes, so they do not belong in a patch whose
532
- // whole claim is that it only changes wording. Normalisation, if it ever
533
- // returns, needs room addresses deliberately EXEMPT and zero-width
534
- // characters handled (JS trim() does not strip them — verified, contrary
535
- // to what an earlier comment here asserted).
536
- const r = await apiFetch("/memory/write", {
537
- method: "POST",
538
- body: JSON.stringify(writeRequestBody({ content, concepts, domain })),
539
- });
540
- // `stored` MUST BE A BOOLEAN before either verdict below may be printed.
541
- //
542
- // This was the last surface reading a MISSING field as a field that said
543
- // false. `if (r?.stored)` sent every body that did not say `true` to the
544
- // else-branch, whose first four words are "NOT STORED — nothing was saved"
545
- // and whose last sentence explains WHY: "Writes are gated on how much a
546
- // memory adds… so a near-duplicate is refused." So a 204, an empty `{}`, a
547
- // proxy or gateway answering `{"ok":true}`, and a mis-set
548
- // MNEMOVERSE_API_URL all produced an absence claim about the user's memory
549
- // AND a fabricated mechanism for it — two statements, neither with any
550
- // evidence behind it. The write is also the surface where being wrong costs
551
- // most: a caller told "nothing was saved" re-words and retries, or drops
552
- // the fact, and the atom that may in fact be sitting in the store is not
553
- // what the user is told about.
554
- //
555
- // The four LIST surfaces have had this guard since 0.8.1 (truth F13); the
556
- // write did not. The test for `boolean` and not for presence is deliberate:
557
- // `{"stored":"yes"}` is not core speaking either.
558
- if (typeof r?.stored !== "boolean") {
559
- return unreadableAnswerReply("The write result", "confirmation that the memory was stored", "it was refused", " Whether the content reached memory is unknown from here — report the" +
560
- " outcome of the RETRY, not of this call, and do not tell the user it" +
561
- " was saved or that it was rejected.");
562
- }
563
- // "unknown", not 0.00, when the server didn't send a score — the same rule
564
- // memory_stats got in this release. A live surface exists that answers
565
- // {"stored":false} with no reason and no score; printing "0.00" there
566
- // fabricates the gate's verdict (review, 2026-08-08).
567
- const importance = typeof r?.importance === "number" ? r.importance.toFixed(2) : "unknown";
568
- // `Server reason:` is a VERBATIM label, and safeInline made it a lie on
569
- // every occurrence: core's only rejection reason is
570
- // "Below importance threshold (0.412 < 0.500)", whose parentheses and `<`
571
- // are outside the sanitiser's charset — so the relay read "Below importance
572
- // threshold 0.412 0.500", with the comparison operator and both delimiters
573
- // deleted and the two numbers left unlabelled and order-only. Quoted
574
- // exactly instead (src/names.ts). If it will not fit, say THAT rather than
575
- // drop the clause: omitting it would report a server that gave no reason.
576
- const reasonQuote = r?.reason
577
- ? (exactLiteral(r.reason, 400)?.literal ?? "(too long to quote exactly)")
578
- : "";
579
- // Narrowed to `true` by the guard above, so this is now the server's stated
580
- // verdict rather than "the body was not falsy".
581
- if (r.stored) {
582
- return {
583
- content: [
584
- {
585
- type: "text",
586
- text: `Stored (importance: ${importance}). ID: ${r.atom_id ?? "unknown"}`,
587
- },
588
- ],
589
- };
590
- }
591
- // NOT STORED. The old wording ("Filtered — …") named the mechanism but
592
- // never the outcome, so a caller could read it as a soft success and move
593
- // on. In dogfooding this ate a CORRECTION to a wrong fact: the stale
594
- // version stayed as the only record, and looked more authoritative for
595
- // having no competitor (2026-08-07).
596
- //
597
- // The ADVICE was wrong until 2026-08-08, and wrong in a way that made
598
- // things worse. It told the caller to rewrite the content as a cleaner
599
- // factual statement — but the gate scores GEOMETRIC NOVELTY against the
600
- // nearest existing atom in the same domain, not phrasing or factuality.
601
- // "Below importance threshold" means TOO SIMILAR TO SOMETHING ALREADY
602
- // STORED. A rewrite of the same fact therefore produces a near-identical
603
- // embedding, scores the same or lower, and is rejected again — and the old
604
- // text ended with "write it again", so a compliant agent looped. It was
605
- // anti-correlated with the mechanism in exactly the case it was written
606
- // for: a correction, which is by nature similar to what it corrects.
607
- return {
608
- content: [
609
- {
610
- type: "text",
611
- // WHAT IS CONDITIONAL HERE, stated exactly, because a previous
612
- // version of this comment claimed more than the code does.
613
- //
614
- // Conditional: the SERVER'S VERDICT and the SCORE. `Server reason:`
615
- // is printed only when `reason` came back, and `Novelty score` only
616
- // when a numeric `importance` did — a live surface answers
617
- // `{"stored":false}` with neither, and quoting a verdict nobody sent
618
- // would be a claim on zero evidence.
619
- //
620
- // Unconditional: the MECHANISM sentence below, and it is not derived
621
- // from this response. It is a statement about core: `/memory/write`
622
- // refuses for exactly one reason — the importance gate, scoring
623
- // geometric novelty against the nearest existing atom in the same
624
- // domain, with "Below importance threshold (x < y)" as its only text
625
- // (two branches in memory_engine, one reason). The BATCH endpoint has
626
- // other failure paths; this client does not call it. So for any
627
- // rejection this client can receive, that sentence is true whether or
628
- // not the server bothered to say why. The earlier comment here read
629
- // "the cause is named only when the server named it", which describes
630
- // a draft that did not carry this sentence at all.
631
- //
632
- // NOT PRESENT AT ALL: a prediction about the retry. "Rewording will
633
- // score the same or lower" was asserted as fact and is probably
634
- // BACKWARDS — novelty decreases with similarity to the blocking
635
- // memory, so a reworded sentence is usually LESS similar and scores
636
- // HIGHER. And delete-then-write advice an earlier draft carried was
637
- // impossible for a room write even when memory_delete still existed:
638
- // the blocker is a room atom, which that tool could not touch either
639
- // (reviews, 2026-08-08). Deletion is administrative-only now
640
- // (2026-08-20), so this message never suggests it at all.
641
- text: `NOT STORED — nothing was saved.` +
642
- (reasonQuote ? ` Server reason: ${reasonQuote}.` : ``) +
643
- (importance === "unknown"
644
- ? ``
645
- : ` Novelty score ${importance}. That score is a first-generation` +
646
- ` metric under active development and known to be unreliable —` +
647
- ` identical content has measured ~0.08 in Russian against ~0.55 in` +
648
- ` English — so read it as a rough hint about similarity, not as a` +
649
- ` judgement of whether this memory was worth keeping.`) +
650
- (isRoomDomain(domain)
651
- ? // ROOM RULE (core#482, 2026-08-13). A room is a message bus:
652
- // the second agent's job is to receive a restatement of what
653
- // the first was told, so a briefing or a status summary STORES
654
- // here. Only a write the embedder cannot distinguish from one
655
- // already present is refused. Telling a caller to "write the
656
- // delta" in a room would be advice against the room's purpose.
657
- ` Restatements are allowed in rooms — this one was refused only` +
658
- ` because it is indistinguishable by embedding from a message` +
659
- ` already there. Similarity is judged on roughly the first 500` +
660
- ` tokens, so a long message that OPENS like an earlier one can` +
661
- ` land here even when its body differs: lead with what is new.`
662
- : ` Writes are gated on how much a memory adds over what is already in the` +
663
- ` same domain, so a near-duplicate is refused. If the point is genuinely` +
664
- ` new, write what is DIFFERENT rather than restating the whole fact.`),
665
- },
666
- ],
667
- };
668
- });
669
- // --- Tool: memory_read ---
670
- server.registerTool("memory_read", {
671
- description: "Search your long-term memory before answering anything that may have come up before — user preferences, past decisions, project setup, people, or earlier context. This memory is shared: it persists across sessions and across every AI tool the user has connected (Claude, ChatGPT, Cursor, VS Code). ALWAYS check here first when you're unsure whether you already know something; no need to call it for general world knowledge you already hold. Returns matches ranked by relevance (or newest-first with order_by: 'recency'); each result carries an id you can pass to memory_feedback. A wrong or stale memory is corrected by writing a fresh one with memory_write, not by deleting it.",
672
- inputSchema: {
673
- query: z
674
- .string()
675
- .min(1)
676
- .max(5000)
677
- .describe("Natural-language description of what you're looking for, e.g. 'database choice for the API' or 'user's preferred testing framework'."),
678
- top_k: z
679
- .number()
680
- .int()
681
- .min(1)
682
- .max(50)
683
- .optional()
684
- .describe("Requested number of results (default: 5). ⚠️ Not a hard cap: association expansion can return MORE than this, and the relevance floor can return fewer — raising it does not reliably widen the result set. For a complete, exactly-bounded listing use memory_list_recent instead."),
685
- domain: z
686
- .string()
687
- .optional()
688
- .describe("Restrict the search to one domain namespace (e.g. 'project:acme'). Omitting it searches your OWN domains — it does NOT include shared rooms, which are separate stores: to search a room, pass its address here (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms."),
689
- order_by: z
690
- .enum(["relevance", "recency"])
691
- .optional()
692
- .describe("'relevance' (default) = ranking order. 'recency' = the matched " +
693
- "set re-sorted newest-first. For a complete newest-first feed " +
694
- "with no search at all, use memory_list_recent instead."),
695
- since: z
696
- .string()
697
- .max(40)
698
- .optional()
699
- .describe("Only memories created at/after this ISO-8601 instant (naive = " +
700
- "UTC) — e.g. your last-seen watermark in a shared room."),
701
- until: z
702
- .string()
703
- .max(40)
704
- .optional()
705
- .describe("Only memories created at/before this ISO-8601 instant."),
706
- exclude_author: z
707
- .string()
708
- .max(200)
709
- .optional()
710
- .describe("Drop memories written by this author PRINCIPAL — the server-side " +
711
- "identity. ⚠️ NOT USABLE FROM HERE YET: the principal is not shown " +
712
- "in these results, so there is no value you can obtain through " +
713
- "this tool, and a guess like 'me' silently matches nothing and " +
714
- "filters nothing. Only pass it if your system knows the exact " +
715
- "principal from elsewhere (e.g. the REST API). A self-exclusion " +
716
- "shortcut is planned."),
717
- },
718
- annotations: {
719
- title: "Search Memories",
720
- readOnlyHint: true,
721
- destructiveHint: false,
722
- idempotentHint: true,
723
- openWorldHint: true,
724
- },
725
- }, async ({ query, top_k, domain, order_by, since, until, exclude_author }) => {
726
- // ONE value, used for the request AND for every decision about it.
727
- //
728
- // A previous draft sent the raw string but decided the wording from a
729
- // TRIMMED copy, and the two disagreed in the release's own founding case:
730
- // a read on " engineering" searched the padded store (correct) while the
731
- // diagnosis checked "engineering", found it, and stayed silent — so the
732
- // one note that would have said "a stray space makes a different store"
733
- // was suppressed exactly when a stray space had made a different store.
734
- // For a whitespace-only domain it went the other way and claimed the
735
- // search had covered the caller's own domains when it had covered none
736
- // (reviews, 2026-08-08).
737
- //
738
- // `|| undefined` is what 0.8.0 sent and must stay: core filters on
739
- // `domain is not None`, not on truthiness, so passing "" through would
740
- // become `WHERE domain = ''` — a store that cannot exist — turning a
741
- // search of every domain into a guaranteed miss. That is data movement,
742
- // not wording, and it does not belong in a patch.
743
- const searched = searchedScope(domain);
744
- const r = await apiFetch("/memory/read", {
745
- method: "POST",
746
- body: JSON.stringify(readRequestBody({ query, top_k, domain, order_by, since, until, exclude_author })),
747
- });
748
- // `items` must be a REAL array before anything below may speak. Core's
749
- // read response always carries one on a 200, so a body without it is not
750
- // core's answer — and the old `Array.isArray(r?.items) ? r.items : []`
751
- // fed exactly that body to the entire zero-result machinery: head
752
- // sentence, scope probe, diagnosis. An absence claim derived from a body
753
- // this client could not read — the substitution classifyRooms removed for
754
- // rooms, one level up from the probes (truth F13, 2026-08-08).
755
- const items = r?.items;
756
- if (!Array.isArray(items)) {
757
- return unreadableAnswerReply("The search result", "a list of matches", "nothing matched");
758
- }
759
- if (items.length === 0 && (since || until || exclude_author)) {
760
- // A bounded/filtered read that finds nothing is NOT a bad query —
761
- // the truthful answer is "nothing new for these filters" (the feed's
762
- // filtered head uses the same sentence; no stats probe, no broaden
763
- // hint). Unscoped, it also has to name the rooms it never looked in.
764
- const scopeNote = readScopeNote(await probeScope(searched));
765
- return {
766
- content: [
767
- {
768
- type: "text",
769
- // The scope is IN the sentence, not appended after it. This
770
- // branch was already the honest one in 0.8.0 — it names its
771
- // filters — and it is the model the feed's copy now follows.
772
- //
773
- // The legend wraps the WHOLE message and is added at most once:
774
- // `scopeNote` may itself have named a store (a case-twin), and one
775
- // explanation of the escaping per answer is the point of it.
776
- text: withDomainEscapeLegend(`Nothing in ${scopeLabel(searched)} matches within the given time/author filters.` +
777
- futureSinceNote(since, Date.now()) +
778
- scopeNote, searched),
779
- },
780
- ],
781
- };
782
- }
783
- if (items.length === 0) {
784
- // Zero results. The scope is probed FIRST and the whole answer is then
785
- // assembled from that ONE value in src/teaching.ts — head sentence and
786
- // disclosure together, per state.
787
- //
788
- // ORDER MATTERS and is now structural: whether the caller has rooms we
789
- // could not search decides whether the first-contact greeting is even
790
- // true, so the room knowledge is an INPUT to the answer rather than a flag
791
- // consulted beside it. `total_atoms` counts the personal org only, so a
792
- // joiner with three full rooms and no personal writes would otherwise be
793
- // told "nothing has been saved yet" and contradicted by the note right
794
- // underneath (review, 2026-08-08).
795
- //
796
- // Nothing is appended here any more. While the head came from teaching.ts
797
- // and the tail was concatenated at this line, the two could disagree — a
798
- // head promising "that is not the whole picture:" with an empty tail after
799
- // it was a live bug for an account whose only room was archived.
800
- const scope = await probeScope(searched);
801
- const text = await buildReadEmptyResponse(
802
- // THE THIRD PROBE, and the one the first pass at #73 missed. An
803
- // UNSCOPED empty read takes this path: probeScope only fetches the
804
- // room list (scope.ts: `if (!searched) return { kind: "own-domains" }`),
805
- // and the stats call for the first-contact greeting is issued here.
806
- // Deadlining only the two inside probeScope left the commonest empty
807
- // read of all still able to hang for undici's ~300s default — the exact
808
- // symptom #73 names.
809
- () => apiFetch("/memory/stats", {
810
- signal: AbortSignal.timeout(PROBE_TIMEOUT_MS),
811
- }), scope);
812
- return {
813
- content: [
814
- {
815
- type: "text",
816
- // NO legend wrapper here, on purpose — `withDomainEscapeLegend(
817
- // text, searched)` stood on this line and was dead code that
818
- // looked load-bearing (tests-lens F9, 2026-08-08): every arm of
819
- // buildReadEmptyResponse either names no store at all (fixed
820
- // sentences), or names it inside a note that appends its own
821
- // legend (the case-twin diagnosis, src/scope.ts) — and the
822
- // unscoped path passes `searched === undefined`, which can never
823
- // need one. So there was no input on which the wrapper fired.
824
- // Pinned by "the plain-empty read is legended by its notes" in
825
- // test/handlers.test.ts.
826
- text,
827
- },
828
- ],
829
- };
830
- }
831
- // Rendering lives in src/render.ts (testable): each line carries the
832
- // CN-001 author tag, the created_at date (#404 R1 — a reader cannot
833
- // reason about recency it cannot see) and the full atom id (the tool
834
- // description always promised ids for memory_feedback/memory_delete;
835
- // the old render never delivered them, making both uncallable from
836
- // read results).
837
- const lines = items.map((item, i) => formatReadItem(item, i));
838
- // `?? 0` prints a FABRICATED `(0ms)` when the server sent no timing — the
839
- // same class as "Associations: 0" for an unknown count, which memory_stats
840
- // fixed in this release. Untouched here and recorded in CHANGELOG's "Known
841
- // and NOT fixed here" with the other three.
842
- const searchMs = (r?.search_time_ms ?? 0).toFixed(0);
843
- const text = lines.join("\n\n") + `\n\n(${searchMs}ms)`;
844
- return {
845
- content: [
846
- {
847
- type: "text",
848
- // Each line's `@"domain"` tag is an exact literal; the legend that
849
- // explains an escape belongs to the answer, not to twenty tags.
850
- //
851
- // Legend AFTER the cap, never before. capResult truncates from the
852
- // END, and the legend is appended at the end — so applied first it
853
- // was the first thing the cap ate, on exactly the pages long enough
854
- // to need both: a hundred escaped tags left with nothing saying that
855
- // \u00a0 is ONE character, not six (truth F6, 2026-08-08). Applied
856
- // to the CAPPED text the legend survives; and since it fires only
857
- // when an escaped literal is still on the page, a cap that removed
858
- // every escaped name drops the legend with it.
859
- text: withDomainEscapeLegend(capResult(text), ...items.map((it) => it?.domain)),
860
- },
861
- ],
862
- };
863
- });
864
- // --- Tool: memory_list_recent ---
865
- /**
866
- * How big ONE feed page may get, and how the handler stays under it (#104).
867
- *
868
- * THE INCIDENT. `memory_list_recent(domain: "xroom:…", limit: 40, cursor: …)`
869
- * over a shared room of long archival entries produced a single tool result of
870
- * 72,648 characters. Claude Code refused to inline it and spilled it to a file;
871
- * a client without that fallback loses the page. MAX_RESULT_CHARS did not fire,
872
- * and could not have: 72,648 is comfortably under 96,000. That number is
873
- * `24,000 tokens × 4 chars/token`, and the 4 is an average over ordinary prose —
874
- * archival room entries carry ids, code, punctuation and non-ASCII, which
875
- * tokenize far worse. A cap derived from an optimistic ratio is not a promise
876
- * about a client's real limit.
877
- *
878
- * WHY `limit` COULD NOT SOLVE IT. `limit` bounds the COUNT. Whether a count is
879
- * safe depends entirely on how long the entries happen to be — 1,500–4,000+
880
- * chars each in coordination rooms, against a 10,000-char write cap — and the
881
- * caller cannot know that before asking. Too high explodes; too low costs
882
- * dozens of round trips for the same catch-up.
883
- *
884
- * WHAT THIS IS. A page is assembled from small sub-requests and stops BEFORE
885
- * the budget is exceeded, returning the server cursor of the last FULLY
886
- * accepted sub-batch. The cursor is per-batch, which is why the batch is small:
887
- * it is the granularity at which the page can end without losing or repeating
888
- * an entry. Nothing is dropped silently — an entry that exceeds the budget on
889
- * its own is returned whole, as a page of one, because per-entry truncation
890
- * needs a fetch-one-by-id verb this server does not have (#104, suggestion 2).
891
- *
892
- * THE NUMBER IS DELIBERATELY CONSERVATIVE AND DELIBERATELY LOCAL. 40,000 is
893
- * roughly half of what already failed in production; the true boundary of any
894
- * given client is unmeasured, and calibrating it is follow-up work. It does NOT
895
- * touch MAX_RESULT_CHARS, which is shared with memory_read and every other
896
- * surface and remains the final backstop after this budget has done its work.
897
- */
898
- const LIST_PAGE_CHAR_BUDGET = 40_000;
899
- /**
900
- * Entries per sub-request. Small enough that the budget can end a page at a
901
- * useful granularity, large enough that an ordinary short-entry feed still
902
- * costs one or two round trips (the default `limit` of 20 costs two).
903
- */
904
- const LIST_PAGE_CHUNK = 10;
905
- /**
906
- * A ceiling on sub-requests per call — the loop's own stop condition is the
907
- * budget, the caller's `limit`, or the end of the feed, and this fires only if
908
- * a server answers in a way none of those three catch. `limit: 100` needs ten,
909
- * plus a few for narrowing an over-budget batch.
910
- */
911
- const LIST_PAGE_MAX_REQUESTS = 16;
912
- /**
913
- * Appended when the page stopped because a LATER sub-request failed. Chunking
914
- * multiplies the requests per call and therefore the chance one of them fails
915
- * mid-page; discarding the entries already in hand would make this change a
916
- * regression for exactly the long-entry rooms it exists for. Saying nothing
917
- * would be worse — a short page with a valid cursor is indistinguishable from
918
- * a page the budget ended, which is the could-not-fetch/does-not-exist
919
- * collision this codebase keeps closing.
920
- */
921
- const LIST_PAGE_EARLY_STOP_NOTE = "\n\n(This page stopped early — the request for the next batch of older " +
922
- "entries did not come back usable, so this page holds fewer entries than " +
923
- "asked for. The cursor above is unaffected: continue from it.)";
924
- server.registerTool("memory_list_recent", {
925
- description: "List the NEWEST memories first — no search query needed. Semantic search answers 'what do I know about X'; this answers 'what happened lately': resuming work after a break, catching up on a shared room ('any new messages?'), or reviewing what was saved recently. Pass `since` (your last-seen time) to get only what's new, and page through older entries with the returned cursor. Complete by construction WITHIN ONE SCOPE — nothing is skipped there, unlike a semantic search. A page is also bounded by SIZE, so a page of long entries comes back shorter than `limit` and hands you a cursor for the rest — nothing is dropped, and following the cursor is how you get it. To catch up on a shared room you MUST pass its address as `domain`: rooms are separate stores and an unscoped call never covers them.",
926
- inputSchema: {
927
- domain: z
928
- .string()
929
- .optional()
930
- .describe("Restrict to one domain. REQUIRED to read a shared room — pass its address ('xroom:room_01ABC'), because rooms are separate stores that an unscoped feed does NOT cover. Omit only when you mean your own domains. Room addresses come from memory_list_rooms. Room entries are often long — a room feed usually reaches its size budget after a handful of them, so expect to page (see `limit`)."),
931
- since: z
932
- .string()
933
- .optional()
934
- .describe("Only entries created at/after this ISO-8601 instant (naive = UTC) — your novelty watermark."),
935
- until: z
936
- .string()
937
- .optional()
938
- .describe("Only entries created at/before this ISO-8601 instant (inclusive). Pair with `since` to read a closed window — 'what happened on Monday' — instead of paging back from now."),
939
- exclude_author: z
940
- .string()
941
- .max(200)
942
- .optional()
943
- .describe("Drop entries written by this author PRINCIPAL. ⚠️ NOT USABLE FROM HERE YET — the principal is never shown in these results, so there is no value you can get through this tool; a guess like 'me' filters nothing, silently. Same caveat as on memory_read."),
944
- limit: z
945
- .number()
946
- .int()
947
- .min(1)
948
- .max(100)
949
- .optional()
950
- .describe("Most entries per page (default: 20). Newest first. ⚠️ A CEILING, not a promise: the page is ALSO bounded by size, so a page of long entries stops early and returns a cursor for the rest. In rooms whose entries run long, ask for 5–10 — a large `limit` there buys nothing the size budget will not take back, and costs round trips."),
951
- cursor: z
952
- .string()
953
- .max(512)
954
- .optional()
955
- .describe("Opaque cursor from a previous page's 'More older entries exist' line — continues the listing without skips or duplicates."),
956
- },
957
- annotations: {
958
- title: "List Recent Memories",
959
- readOnlyHint: true,
960
- destructiveHint: false,
961
- idempotentHint: true,
962
- openWorldHint: true,
963
- },
964
- }, async ({ domain, since, until, exclude_author, limit, cursor }) => {
965
- // ONE value for the request and for every decision about it — see the note
966
- // at the top of memory_read.
967
- const searched = searchedScope(domain);
968
- // The caller's `limit` is a CEILING on the item count. The page also has a
969
- // character budget (LIST_PAGE_CHAR_BUDGET), and whichever binds first ends
970
- // the page — which is why this is a loop over small sub-requests rather
971
- // than one request for `limit` entries followed by a cap that arrives too
972
- // late to do anything but truncate.
973
- const ceiling = limit || 20;
974
- const accepted = [];
975
- // The server cursor of the last FULLY accepted sub-batch: the only value
976
- // that can be handed back without losing or repeating an entry, since a
977
- // cursor names a batch boundary and nothing finer.
978
- let acceptedCursor;
979
- // Where the next sub-request continues from — the caller's cursor first,
980
- // the server's thereafter. Resending the caller's would replay page one.
981
- let position = cursor || undefined;
982
- let ask = Math.min(LIST_PAGE_CHUNK, ceiling);
983
- let stoppedEarly = false;
984
- for (let attempt = 0; attempt < LIST_PAGE_MAX_REQUESTS; attempt++) {
985
- let r;
986
- try {
987
- r = await apiFetch("/memory/recent", {
988
- method: "POST",
989
- body: JSON.stringify(recentRequestBody({
990
- domain,
991
- since,
992
- until,
993
- exclude_author,
994
- limit: ask,
995
- cursor: position,
996
- })),
997
- });
998
- }
999
- catch (e) {
1000
- // A failure with entries already in hand ends the page instead of the
1001
- // call: the caller keeps what was fetched plus a cursor that still
1002
- // continues correctly, and the appended note says the page was cut
1003
- // short by a failed request rather than by the budget. With nothing
1004
- // accepted there is no page to return, so the error surfaces exactly
1005
- // as it did before chunking.
1006
- if (accepted.length > 0) {
1007
- stoppedEarly = true;
1008
- break;
1009
- }
1010
- // Graceful degradation while the server side rolls out: a 404 with no
1011
- // error `code` in the body is what an undeployed /memory/recent looks
1012
- // like, so degrade to a usable alternative instead of surfacing a raw
1013
- // HTTP error.
1014
- //
1015
- // NAMED FOR WHAT IT TESTS. This was `endpointAbsent`, which asserted a
1016
- // deployment fact the check cannot establish: every engine 404 carries a
1017
- // `code`, so a real room-404 is excluded, but a gateway, a proxy or a
1018
- // wrong MNEMOVERSE_API_URL produces the same bare 404 and is
1019
- // indistinguishable from here. The MESSAGE below still states the
1020
- // deployment cause outright, which is more than this boolean knows —
1021
- // listed in CHANGELOG's "Known and NOT fixed here" rather than papered
1022
- // over with a hedge.
1023
- //
1024
- // NOW READ FROM STRUCTURED FIELDS. It used to be
1025
- // `e.message.startsWith("Mnemoverse API error 404:")` plus a substring
1026
- // hunt for `"code"` in the same string — a behavioural branch keyed to the
1027
- // exact prefix of a user-facing sentence. Rewording that sentence, which
1028
- // is precisely what src/errors.ts does, would have flipped this branch
1029
- // silently: every per-request 404 would have degraded into "the service
1030
- // does not support the feed yet". `ApiError.isBare404` asks the parsed
1031
- // envelope instead, so the prose and the branch can no longer collide.
1032
- const bare404 = e instanceof ApiError && e.isBare404;
1033
- if (bare404) {
1034
- return {
1035
- content: [
1036
- {
1037
- type: "text",
1038
- text: "The memory service does not support the recent-entries feed yet. " +
1039
- "Use memory_read with order_by: 'recency' as an approximation.",
1040
- },
1041
- ],
1042
- };
1043
- }
1044
- throw e;
1045
- }
1046
- // Same guard as memory_read: a 200 without an items array is UNREADABLE,
1047
- // not empty — and the feed's empty heads below are precisely the absence
1048
- // claims that must not be derived from it (truth F13, 2026-08-08). Mid
1049
- // page it is treated like a failed sub-request, for the same reason.
1050
- const batch = r?.items;
1051
- if (!Array.isArray(batch)) {
1052
- if (accepted.length > 0) {
1053
- stoppedEarly = true;
1054
- break;
1055
- }
1056
- return unreadableAnswerReply("The recent-entries feed", "an empty feed", "there is nothing to list");
1057
- }
1058
- const next = r?.next_cursor;
1059
- // Measured on the TEXT THAT WOULD SHIP, rendered by the same function
1060
- // that renders the answer — an estimate from item lengths would drift
1061
- // from the renderer the first time a line gained a field. The early-stop
1062
- // note's length is reserved up front: it is appended only when a LATER
1063
- // sub-request fails, which cannot be known while this batch is being
1064
- // sized, so every page keeps room for it (CodeRabbit, PR #108).
1065
- const fits = formatRecentPage(accepted.concat(batch), next).length <=
1066
- LIST_PAGE_CHAR_BUDGET - LIST_PAGE_EARLY_STOP_NOTE.length;
1067
- if (fits) {
1068
- accepted.push(...batch);
1069
- acceptedCursor = next;
1070
- position = typeof next === "string" && next ? next : undefined;
1071
- // No cursor: the feed ended, and the page says so. No entries: the
1072
- // server is not advancing, so continuing would spend requests on the
1073
- // same nothing. Ceiling reached: the caller's count is spent.
1074
- if (!position || batch.length === 0 || accepted.length >= ceiling)
1075
- break;
1076
- ask = Math.min(LIST_PAGE_CHUNK, ceiling - accepted.length);
1077
- continue;
1078
- }
1079
- // Over budget. With entries already accepted, THIS is the ordinary stop:
1080
- // keep the batches that fit and hand back the cursor of the last one.
1081
- if (accepted.length > 0)
1082
- break;
1083
- // Nothing accepted yet, so this one batch is over budget by itself and
1084
- // the page cannot be empty — something must be returned.
1085
- //
1086
- // `batch.length > ask` means the server ignored `limit`; asking again,
1087
- // smaller, would be a wasted round trip against a deployment that is not
1088
- // listening, and MAX_RESULT_CHARS is the backstop for it. A batch of one
1089
- // is the entry that exceeds the budget alone: it ships whole, because
1090
- // dropping it is silent loss and truncating it needs a fetch-by-id verb
1091
- // that does not exist yet (#104).
1092
- //
1093
- // KNOWN EDGE, inherited rather than introduced (CodeRabbit, PR #108):
1094
- // when a limit-ignoring server's batch ships whole and capResult then
1095
- // truncates the tail, the printed cursor points past entries the reader
1096
- // never saw. 0.9.1 had the identical hazard (one request, the server's
1097
- // cursor, the same cap). The alternatives are worse lies: slicing to
1098
- // `ask` keeps the server's cursor and SKIPS the sliced entries silently;
1099
- // rejecting the batch outright answers a working feed with "unreadable".
1100
- // A contract-violating server is the precondition; the real fix is
1101
- // fetch-by-id (#104 follow-up), not a guess here.
1102
- const narrower = Math.max(1, Math.min(Math.floor(ask / 2), batch.length - 1));
1103
- if (batch.length <= 1 || batch.length > ask || narrower >= ask) {
1104
- accepted.push(...batch);
1105
- acceptedCursor = next;
1106
- break;
1107
- }
1108
- // Re-ask the SAME position for fewer entries. `narrower < batch.length`
1109
- // by construction, so the ask strictly shrinks and the loop converges.
1110
- ask = narrower;
1111
- }
1112
- const items = accepted;
1113
- if (items.length === 0) {
1114
- // THE SENTENCE ITSELF carries the scope — and it is selected by EVERY
1115
- // filter that narrowed the window, not by `since` alone.
1116
- //
1117
- // Two prior shapes of this branch were wrong the same way. In 0.8.0 it
1118
- // printed "Nothing new since your watermark." with no scope in it — the
1119
- // sentence src/scope.ts was written to eliminate. The first fix put the
1120
- // scope into the clause but kept choosing BETWEEN the two heads by
1121
- // looking at `since` only, so {until} alone and {exclude_author} alone
1122
- // fell to "No memories in ${where} yet." — an emptiness claim about a
1123
- // store holding a thousand atoms outside the window — and {since, until}
1124
- // kept the watermark phrasing, which pretends the read reached the
1125
- // present when `until` stopped it years short (review, 2026-08-08).
1126
- //
1127
- // Four heads, one rule: the emptiness claim ("yet") is allowed only
1128
- // when NOTHING narrowed the window; the watermark phrasing only when
1129
- // `since` was the whole narrowing; any other filter combination gets the
1130
- // sentence memory_read's filtered branch uses — the filters are named as
1131
- // what bounded the result, and nothing is claimed beyond them.
1132
- //
1133
- // A `cursor` outranks all three. It is not a filter over the store — it
1134
- // is a POSITION in a listing whose earlier pages the caller has already
1135
- // read, so every other head is false here: "No memories in ${where}
1136
- // yet." is an absence claim about a store the caller has just SEEN
1137
- // entries from, and the watermark phrasing pretends a continuation that
1138
- // stopped mid-listing was a clean catch-up. The engine hands out a
1139
- // cursor only when more entries existed at that moment, so an empty
1140
- // continued page means the listing moved under the caller — entries
1141
- // removed between page fetches — and the head speaks about the
1142
- // continuation only, never about what the store holds (follow-up to the
1143
- // head-selection fix, 2026-08-08). Decided by the same truthiness the
1144
- // request used: an empty-string cursor never reaches the wire
1145
- // (src/requests.ts), so it may not pick the sentence either.
1146
- const scopeNote = readScopeNote(await probeScope(searched));
1147
- const where = scopeLabel(searched);
1148
- const head = cursor
1149
- ? `Nothing further in ${where} past this cursor — entries may have been ` +
1150
- `removed since the previous page was fetched.` +
1151
- (since || until || exclude_author
1152
- ? ` The given time/author filters still bounded this page.`
1153
- : ``)
1154
- : since && !until && !exclude_author
1155
- ? `Nothing new in ${where} since your watermark.`
1156
- : since || until || exclude_author
1157
- ? `Nothing in ${where} matches within the given time/author filters.`
1158
- : `No memories in ${where} yet.`;
1159
- return {
1160
- content: [
1161
- {
1162
- type: "text",
1163
- text: withDomainEscapeLegend(head + futureSinceNote(since, Date.now()) + scopeNote, searched),
1164
- },
1165
- ],
1166
- };
1167
- }
1168
- return {
1169
- content: [
1170
- {
1171
- type: "text",
1172
- // The page body comes from src/render.ts; the escape legend is
1173
- // applied HERE, to the CAPPED text. formatRecentPage used to append
1174
- // it itself, which put it before capResult — and capResult truncates
1175
- // from the end, so the one sentence explaining the escapes was the
1176
- // first casualty on every page long enough to be capped (truth F6,
1177
- // 2026-08-08). Same order as memory_read's result page, same
1178
- // automatic drop: a cap that removed every escaped name removes the
1179
- // reason for the legend too.
1180
- //
1181
- // The cursor is the last ACCEPTED batch's, never the newest one
1182
- // seen: a batch that did not fit the budget was not returned, so
1183
- // pointing past it would skip every entry in it.
1184
- text: withDomainEscapeLegend(capResult(formatRecentPage(items, acceptedCursor) +
1185
- (stoppedEarly ? LIST_PAGE_EARLY_STOP_NOTE : ""),
1186
- // Still true, and now only reachable when ONE entry is larger
1187
- // than the whole budget — the case `limit` cannot fix and the
1188
- // global cap has to.
1189
- "Lower `limit` or add a `domain` for smaller pages."), ...items.map((it) => it?.domain)),
1190
- },
1191
- ],
1192
- };
1193
- });
1194
- // --- Tool: memory_feedback ---
1195
- /**
1196
- * Why ids can miss, listed once and used by both branches that need it — the
1197
- * total miss (`updated_count: 0`) and the partial one (a count short of the
1198
- * ids sent). They are the same event at two scales, and when the sentence
1199
- * lived inline in the zero branch only, the partial case got no explanation at
1200
- * all.
1201
- *
1202
- * No frequency claim. "Most often that means…" was a statistic we do not have
1203
- * (review, 2026-08-08); the causes are listed as possibilities, with the one
1204
- * the caller cannot otherwise guess first because it is invisible from the
1205
- * tool surface — this tool takes no `domain`, so a room atom is unreachable
1206
- * from it by construction.
1207
- */
1208
- const FEEDBACK_MISS_CAUSES = "Possible causes: the ids came from a shared room (this tool takes no domain " +
1209
- "argument and cannot reach room atoms, so rating them is a no-op); the memory " +
1210
- "was deleted; or the id came from somewhere other than a memory_read result.";
1211
- server.registerTool("memory_feedback", {
1212
- description:
1213
- // "negative feedback lets it fade" was withdrawn as false by 0.9.1
1214
- // (#95) — and survived here, in the sentence every connected model
1215
- // reads. Nothing time-decays and nothing is auto-deleted: a downvoted
1216
- // memory is OUT-RANKED, and deletion has been administrative-only since
1217
- // 0.9.0. The replacement is the wording that release put on the README.
1218
- "Report whether memories returned by memory_read were actually helpful. This is a learning signal, not a log: positive feedback raises a memory's ranking so it surfaces faster next time (across all of the user's tools), negative feedback lowers it so other memories out-rank it — nothing is erased and nothing decays with time. Call it right after you act on (or reject) recalled memories, passing the ids from the memory_read results. NOTE: this reaches your own domains only — it takes no domain argument, so rating a memory that lives in a shared room silently does nothing.",
1219
- inputSchema: {
1220
- atom_ids: z
1221
- .array(z.string())
1222
- .min(1)
1223
- .describe("IDs of memories to give feedback on (from memory_read results)"),
1224
- outcome: z
1225
- .number()
1226
- .min(-1)
1227
- .max(1)
1228
- .describe("How helpful was this? 1.0 = very helpful, 0 = neutral, -1.0 = harmful/wrong"),
1229
- },
1230
- annotations: {
1231
- title: "Rate Memory Helpfulness",
1232
- readOnlyHint: false,
1233
- // Feedback permanently mutates the memory's valence and importance
1234
- // scores on the backend — per MCP spec, that is a destructive update
1235
- // to the stored state (cf. ToolAnnotations.destructiveHint), even
1236
- // though the caller intends it as quality signal rather than delete.
1237
- destructiveHint: true,
1238
- idempotentHint: false,
1239
- openWorldHint: true,
1240
- },
1241
- }, async ({ atom_ids, outcome }) => {
1242
- const r = await apiFetch("/memory/feedback", {
1243
- method: "POST",
1244
- body: JSON.stringify({ atom_ids, outcome }),
1245
- });
1246
- // A FIELD THE SERVER DID NOT SEND IS UNKNOWN, NOT ZERO — the rule
1247
- // memory_stats already applies with `num()`, broken here by
1248
- // `r?.updated_count ?? 0` in three directions at once:
1249
- //
1250
- // 1. A 200 with the field absent, an explicit null, and a 204 (which
1251
- // apiFetch turns into `{}`) all became 0, and 0 prints "No feedback
1252
- // was recorded" plus three causes for it — an absence claim read out
1253
- // of a body that carried no claim. Under core's async path the
1254
- // rating may well have been applied while the ack said nothing.
1255
- // 2. A string "0" is not 0, so `??` passed it straight through and the
1256
- // ±1 branches printed "The service reports 0 memories updated — they
1257
- // should surface sooner next time": two clauses contradicting each
1258
- // other in one sentence.
1259
- // 3. Nothing rejected a negative: "reports -2 memories updated".
1260
- //
1261
- // So: usable means a non-negative integer. Anything else is UNKNOWN and
1262
- // gets its own sentence, which diagnoses nothing — the causes of a miss
1263
- // belong to a reported zero, not to a number we never received.
1264
- const reported = r?.updated_count;
1265
- const count = typeof reported === "number" && Number.isInteger(reported) && reported >= 0
1266
- ? reported
1267
- : undefined;
1268
- // Direction is echoed for every outcome, including the ones with no count
1269
- // to report: the same four words for +1 and -1 gave a caller no evidence
1270
- // the loop did anything, which is why nobody calls it twice.
1271
- const sent = outcome > 0
1272
- ? `Rating sent: +${outcome} (helpful).`
1273
- : outcome < 0
1274
- ? `Rating sent: ${outcome} (unhelpful).`
1275
- : "Rating sent: 0.";
1276
- // Zero has no effect clause to offer — promising "this shifts how they
1277
- // rank" for outcome 0 would be a claim we cannot make (dogfooding saw a
1278
- // neutral rating move a score UP by about five points, CodeRabbit #65) —
1279
- // so it offers the one thing that is actionable instead.
1280
- //
1281
- // WHAT 0 ACTUALLY DOES, restated against core#493 (merged 2026-08-13). The
1282
- // valence step used to be `sign(outcome) * |prediction error|`, so outcome
1283
- // 0 took the POSITIVE branch and pushed valence UP — which is what
1284
- // dogfooding saw, and what the previous version of this comment recorded.
1285
- // That is no longer true: core now uses the SIGNED error,
1286
- // `pe = outcome - valence` (memory_engine.py:5167-5169), so a 0 against a
1287
- // positive valence moves it DOWN, toward neutral. Either way 0 is not a
1288
- // no-op and the line must not imply one — but the old explanation is now
1289
- // backwards, and it ships verbatim inside dist/index.js, so it cannot be
1290
- // left to rot in a comment.
1291
- const pickADirection = outcome === 0
1292
- ? " Use +1 (helpful) or -1 (harmful/wrong) to express a clear direction."
1293
- : "";
1294
- if (count === undefined) {
1295
- return {
1296
- content: [
1297
- {
1298
- type: "text",
1299
- text: `${sent} The service accepted the call but did not report how many ` +
1300
- `memories it updated, so whether any changed is unknown from here. ` +
1301
- `That is not evidence of a failure — do not re-send the same rating ` +
1302
- `on the strength of it.` + pickADirection,
1303
- },
1304
- ],
1305
- };
1306
- }
1307
- // "Feedback recorded for 0 memories." is one character away from the
1308
- // success line and reads like one. But the DIAGNOSIS matters as much as
1309
- // the fact: an earlier version of this branch blamed deletion, which is
1310
- // usually the wrong cause (review, 2026-08-08).
1311
- //
1312
- // Core resolves the feedback org from a `domain` argument that defaults to
1313
- // "general" — and THIS TOOL EXPOSES NO domain PARAMETER. So the ordinary
1314
- // way to get zero is to rate atoms that live somewhere else: read a room,
1315
- // take the ids off the `id:` lines, rate them, and every one silently
1316
- // misses. The atoms exist, the ids are valid, and telling the caller they
1317
- // were deleted sends them to look for a problem that isn't there.
1318
- if (count === 0) {
1319
- return {
1320
- content: [
1321
- {
1322
- type: "text",
1323
- text: "No feedback was recorded — none of those ids matched a memory in your own " +
1324
- `domains. ${FEEDBACK_MISS_CAUSES}`,
1325
- },
1326
- ],
1327
- };
1328
- }
1329
- // WHOSE NUMBER THIS IS (#68). `updated_count` is the count of memories the
1330
- // service says it touched — and that is true only while core runs
1331
- // `feedback_async = False`. Under async it returns the number of ids
1332
- // SUBMITTED, not applied (core schemas.py:826-838, memory_engine.py:4898-4902),
1333
- // and nothing in the response says which mode ran. A server-side config
1334
- // flip would therefore turn a confident sentence here false on every
1335
- // installed client, silently. So the number is reported as the SERVICE'S
1336
- // report rather than asserted as an outcome this client verified. The
1337
- // hosted connector took the same correction on 2026-08-13
1338
- // (mnemoverse-mcp-remote#38); one number, one degree of confidence,
1339
- // whichever surface a model reaches it through.
1340
- const noun = `${count} memor${count === 1 ? "y" : "ies"}`;
1341
- const effect = outcome > 0
1342
- ? " — they should surface sooner next time."
1343
- : outcome < 0
1344
- // No fade. 0.9.1 (#95) withdrew "lets it fade" as false — nothing
1345
- // time-decays, nothing is auto-deleted, and deletion has been
1346
- // administrative-only since 0.9.0 — and this line kept promising it
1347
- // after the release that deleted the claim from the README.
1348
- ? " — they should rank lower next time. Out-ranked, not erased: nothing is deleted and nothing decays with time."
1349
- : ".";
1350
- // WHAT THE COUNT IS NOT: a guarantee that every id landed. `atom_ids.length`
1351
- // was never compared with it, so five ids and `updated_count: 2` printed
1352
- // the unqualified success line and three silent misses — the typical shape
1353
- // of the room case, where half the ids came off a room read this tool
1354
- // cannot reach. A SHORTFALL can only come from core's sync path (the async
1355
- // ack is exactly `len(atom_ids)`, memory_engine.py:4898-4902), where the
1356
- // number is the authoritative count of atoms that existed — so the same
1357
- // causes as the zero branch apply, at a smaller scale, and the string is
1358
- // shared so the two cannot drift apart.
1359
- //
1360
- // An EXCESS is not a shape core produces at all (sync counts one per id
1361
- // that resolved, async counts the ids). But MNEMOVERSE_API_URL points
1362
- // wherever it is pointed, and "reports 9 memories updated" for one id
1363
- // would otherwise read as nine of the caller's memories rated. Say what it
1364
- // cannot be rather than pass it off as a per-id result.
1365
- const idsSent = `${atom_ids.length} id${atom_ids.length === 1 ? "" : "s"} you sent`;
1366
- const mismatch = count < atom_ids.length
1367
- ? ` That is fewer than the ${idsSent}: ${atom_ids.length - count} of them ` +
1368
- `matched nothing in your own domains. ${FEEDBACK_MISS_CAUSES}`
1369
- : count > atom_ids.length
1370
- ? ` That is more than the ${idsSent}, so it cannot be a per-id result — ` +
1371
- `read it as the service's own tally, not as how many of your memories ` +
1372
- `were rated.`
1373
- : "";
1374
- return {
1375
- content: [
1376
- {
1377
- type: "text",
1378
- // Order: what was sent, what the service reported, what that means
1379
- // for the ids — then the advice. Putting `pickADirection` before the
1380
- // mismatch clause interrupted the report with a suggestion and
1381
- // resumed it afterwards.
1382
- text: `${sent} The service reports ${noun} updated${effect}${mismatch}${pickADirection}`,
1383
- },
1384
- ],
1385
- };
1386
- });
1387
- // --- Tool: memory_stats ---
1388
- server.registerTool("memory_stats", {
1389
- description: "Get an overview of the stored memory: total count, episodes vs consolidated prototypes, number of learned associations, the list of domains, and average quality scores. This memory is shared across all AI tools the user has connected to Mnemoverse. Use it to orient yourself, to confirm the exact domain name before writing to it, or when the user asks what you remember. Read-only — changes nothing.",
1390
- inputSchema: {},
1391
- annotations: {
1392
- title: "Memory Statistics",
1393
- readOnlyHint: true,
1394
- destructiveHint: false,
1395
- idempotentHint: true,
1396
- openWorldHint: true,
1397
- },
1398
- }, async () => {
1399
- const r = await apiFetch("/memory/stats");
1400
- // A field the server did not send is UNKNOWN, not zero. Rendering it as
1401
- // "0" is the same class of lie as an empty search claiming emptiness:
1402
- // "Associations: 0" reads as "this memory has learned nothing", which is
1403
- // a strong and possibly false statement about the product itself.
1404
- const num = (v) => (typeof v === "number" ? String(v) : "unknown");
1405
- const dec = (v) => (typeof v === "number" ? v.toFixed(2) : "unknown");
1406
- // THE surface this tool's own description sends the reader to, to
1407
- // confirm the exact domain name before writing to it — so it has to be
1408
- // able to answer that. (Until 2026-08-20 memory_delete_domain also sent
1409
- // readers here for the same reason, before deletion was withdrawn to an
1410
- // administrative REST-only operation; see CHANGELOG.)
1411
- //
1412
- // Quoting was tried, then withdrawn as a fix that wasn't one: safeInline
1413
- // collapses and trims whitespace BEFORE the quotes go on, so " engineering"
1414
- // and "engineering" printed identically and the list read like a tool bug.
1415
- // The conclusion drawn then — "revealing whitespace needs escaping rather
1416
- // than quoting" — was right; this is that escaping. Each name is a JSON
1417
- // string literal, so a leading space, a no-break space, a newline and a
1418
- // zero-width character are all visible, Cyrillic stays Cyrillic, and two
1419
- // different names can no longer print as one. Assembly lives in
1420
- // src/names.ts, where it is unit-tested against those exact inputs.
1421
- //
1422
- // The assembly also BOUNDS the list (MAX_DOMAIN_LIST_CHARS), which is what
1423
- // makes this handler respect the 25K-token cap every other surface already
1424
- // respected. The line is linear in the number of stores and nothing bounded
1425
- // it: 4,000 domains rendered past 100,000 characters — deterministically,
1426
- // with no hostile input involved. Bounding the LIST rather than leaning on
1427
- // capResult alone is the point: capResult truncates from the END, so the
1428
- // wall of names would have taken the average-quality line and the rooms
1429
- // reminder down with it, leaving the answer nothing but names.
1430
- const domains = formatDomainList(r?.domains);
1431
- const text = [
1432
- `Memories: ${num(r?.total_atoms)} (${num(r?.episodes)} episodes, ${num(r?.prototypes)} prototypes)`,
1433
- // The gloss names the real mechanism. Core's `hebbian_edges` counts
1434
- // concept-concept edges (api/schemas.py: "Number of Hebbian
1435
- // concept-concept edges"), and every path that learns one links two
1436
- // CONCEPTS: `strengthen` walks pairs within one atom's concept list at
1437
- // write time and again on feedback, `co_activate` links query concepts
1438
- // to result concepts on use. An earlier gloss said "links between
1439
- // memories that get used together" — wrong unit (memories, not
1440
- // concepts) and wrong trigger (an edge records co-occurrence, not two
1441
- // memories being used together).
1442
- `Associations: ${num(r?.hebbian_edges)} Hebbian edges — concept-to-concept links learned from concepts that occur together as memories are stored and used`,
1443
- `Domains: ${domains}`,
1444
- `Avg quality: valence ${dec(r?.avg_valence)} (how well recalls turned out, -1..1), importance ${dec(r?.avg_importance)} (0..1)`,
1445
- "",
1446
- "Counts cover your own domains. Shared rooms are separate stores and are not included — see memory_list_rooms.",
1447
- ].join("\n");
1448
- return {
1449
- content: [
1450
- {
1451
- type: "text",
1452
- // Array.isArray, not `?? []`: `domains` is typed as a string[] but
1453
- // arrives over the wire, and spreading a non-iterable object would
1454
- // throw here — turning a malformed payload into a dead tool instead
1455
- // of the "none reported" it degrades to two lines up.
1456
- //
1457
- // capResult is the second belt, not the mechanism: the domain list is
1458
- // already bounded above, so this only fires if some future line grows
1459
- // unboundedly. It stays because this was the ONE tool result with no
1460
- // cap at all, and "every surface is capped" is worth being an
1461
- // invariant rather than an argument about which surfaces can grow.
1462
- // Its hint names a control this no-input tool actually has — none —
1463
- // rather than the read tool's "use a more specific query".
1464
- //
1465
- // Legend AFTER the cap, as everywhere else: it must describe the names
1466
- // that SURVIVED, and it is appended at the end, where the cap cuts.
1467
- text: withDomainEscapeLegend(capResult(text, "The domain list was truncated — some domain names are not shown."), ...(Array.isArray(r?.domains) ? r.domains : [])),
1468
- },
1469
- ],
1470
- };
1471
- });
1472
- // --- Tool: memory_create_room ---
1473
- server.registerTool("memory_create_room", {
1474
- description: "Create a SHARED memory room — a space OTHER people's assistants can read, and write too when their invite granted read_write (the default scope), across Claude/ChatGPT/Cursor. Use when the user wants to share context or collaborate with someone else (e.g. 'make a room for me and Olya'). Returns the room's address; pass that address as the `domain` on memory_write/memory_read to use it. To bring someone in, call memory_invite_to_room next.",
1475
- inputSchema: {
1476
- name: z
1477
- .string()
1478
- .min(1)
1479
- .max(200)
1480
- .describe("Room name, unique within your account (e.g. 'me-and-olya')."),
1481
- description: z
1482
- .string()
1483
- .max(2000)
1484
- .optional()
1485
- .describe("Optional description of the room."),
1486
- },
1487
- annotations: {
1488
- title: "Create shared room",
1489
- readOnlyHint: false,
1490
- destructiveHint: false,
1491
- idempotentHint: false,
1492
- openWorldHint: true,
1493
- },
1494
- }, async ({ name, description }) => {
1495
- const r = await apiFetch("/memory/rooms", {
1496
- method: "POST",
1497
- body: JSON.stringify({ name, description }),
1498
- });
1499
- // The name is echoed back to the caller who CHOSE it, so it is printed
1500
- // exactly (src/names.ts): safeInline turned `memory_create_room({name:
1501
- // "проект"})` into `Created shared room ""` — an echo claiming the caller
1502
- // named their room the empty string.
1503
- const rawName = r?.name ?? name;
1504
- const roomName = roomNamePhrase(rawName);
1505
- const address = safeInline(r?.address);
1506
- const roomId = safeInline(r?.room_id);
1507
- // If core returned no usable id (empty body / sanitized away), don't print
1508
- // broken `domain=""` guidance — say so instead (Copilot).
1509
- const text = address
1510
- ? `Created shared room ${roomName}. Address: ${address}\n` +
1511
- `Use it now: pass domain="${address}" on memory_write / memory_read.\n` +
1512
- (roomId
1513
- ? `To add someone: call memory_invite_to_room with room_id="${roomId}".`
1514
- : "")
1515
- : `Room ${roomName} was created but the server did not return a usable address — ` +
1516
- `retry, or check that your API key is set.`;
1517
- return {
1518
- content: [
1519
- {
1520
- type: "text",
1521
- // Legend AFTER the cap (same rule as memory_read/memory_list_recent):
1522
- // capResult cuts from the end, so a legend applied first would be the
1523
- // first casualty; applied to the capped text it also drops itself when
1524
- // the cap removed the only escaped name.
1525
- text: withDomainEscapeLegend(capResult(text), rawName),
1526
- },
1527
- ],
1528
- };
1529
- });
1530
- // --- Tool: memory_invite_to_room ---
1531
- server.registerTool("memory_invite_to_room", {
1532
- description: "Mint a one-time invite for a room you own and get a ready-to-forward message. The user sends that message to the person they want to add (any messenger); the recipient opens the link or tells THEIR assistant the code to join. Use after memory_create_room, or whenever the user says 'invite <someone>' to an existing room.",
1533
- inputSchema: {
1534
- room_id: z
1535
- .string()
1536
- .min(1)
1537
- .max(100)
1538
- .describe("The room's id (room_...), from memory_create_room."),
1539
- scope: z
1540
- .enum(["read", "read_write"])
1541
- .optional()
1542
- .describe("Role the invitee gets — 'read' or 'read_write' (default read_write)."),
1543
- expires_in_days: z
1544
- .number()
1545
- .int()
1546
- .min(1)
1547
- .max(90)
1548
- .optional()
1549
- .describe("Days until the invite expires (default 7)."),
1550
- },
1551
- annotations: {
1552
- title: "Invite to room",
1553
- readOnlyHint: false,
1554
- destructiveHint: false,
1555
- idempotentHint: false,
1556
- openWorldHint: true,
1557
- },
1558
- }, async ({ room_id, scope, expires_in_days }) => {
1559
- const r = await apiFetch(`/memory/rooms/${encodeURIComponent(room_id)}/invites`, {
1560
- method: "POST",
1561
- body: JSON.stringify({ scope, expires_in_days }),
1562
- });
1563
- return {
1564
- content: [
1565
- {
1566
- type: "text",
1567
- // Shown to the room OWNER (who minted it), not a foreign principal, so
1568
- // the core-generated share_message is fine as-is; capResult only bounds
1569
- // its length for the Connectors-Directory 25K cap.
1570
- text: capResult(`Invite ready. Forward this message to the person you're inviting:\n\n` +
1571
- `${r?.share_message ?? r?.join_url ?? "(no message returned)"}`),
1572
- },
1573
- ],
1574
- };
1575
- });
1576
- // --- Tool: memory_join_room ---
1577
- server.registerTool("memory_join_room", {
1578
- description: "Join a shared memory room using an invite code (starts with 'mnvr_'). Use when the user pastes an invite code or says something like 'join room with code ...'. After joining, use the returned address as the `domain` on memory_read to read the shared room — the result tells you what you may do with it: memory_write to that address is only allowed when your membership scope is read_write; a read-only membership has that write refused; and when the server does not report a scope, whether memory_write would succeed is stated as unknown rather than promised either way.",
1579
- inputSchema: {
1580
- code: z.string().min(1).max(200).describe("The invite code (mnvr_...)."),
1581
- },
1582
- annotations: {
1583
- title: "Join room",
1584
- readOnlyHint: false,
1585
- destructiveHint: false,
1586
- idempotentHint: true,
1587
- openWorldHint: true,
1588
- },
1589
- }, async ({ code }) => {
1590
- const r = await apiFetch("/memory/rooms/join", {
1591
- method: "POST",
1592
- body: JSON.stringify({ code }),
1593
- });
1594
- // The room name is OWNER-chosen and rendered into the JOINER's LLM context
1595
- // (CN-032) — and it is printed EXACTLY (src/names.ts): the literal is one
1596
- // line with quotes and invisibles escaped, so it cannot forge an
1597
- // instruction block, and "Zoë" stops being quoted as "Zo" in a sentence
1598
- // that presents it as the name. `scope` stays sanitised: server-shaped
1599
- // enum, display-only.
1600
- const roomName = roomNamePhrase(r?.name);
1601
- const scope = safeInline(r?.scope) || "member";
1602
- const address = safeInline(r?.address);
1603
- const prefix = r?.already_member
1604
- ? `You're already a member of ${roomName}.`
1605
- : `Joined ${roomName} (${scope}).`;
1606
- // Don't print broken `domain=""` guidance if no address came back (Copilot).
1607
- // The write half of this sentence is scope-gated (roomScopeVerdict, above
1608
- // isRoomDomain): a "read" invite gets told memory_write will be refused
1609
- // rather than offered it, and a scope the response did not report at all
1610
- // gets no promise about write either way.
1611
- const verdict = roomScopeVerdict(r?.scope);
1612
- const usage = !address
1613
- ? `The server did not return a room address — retry, or check that your API key is set.`
1614
- : verdict === "read_write"
1615
- ? `Use it: pass domain="${address}" on memory_write / memory_read to read and write the shared room.`
1616
- : verdict === "read"
1617
- ? `Use it: pass domain="${address}" on memory_read to read it; this membership is read-only, so memory_write to that address will be refused.`
1618
- : `Use it: pass domain="${address}" on memory_read to read it — the server did not report this membership's write access, so whether memory_write to that address would succeed is unknown.`;
1619
- return {
1620
- content: [
1621
- {
1622
- type: "text",
1623
- // Legend after the cap — same ordering rule as everywhere else.
1624
- text: withDomainEscapeLegend(capResult(`${prefix}\n${usage}`), r?.name),
1625
- },
1626
- ],
1627
- };
1628
- });
1629
- // --- Tool: memory_list_rooms ---
1630
- server.registerTool("memory_list_rooms", {
1631
- description: "List the shared memory rooms you can use — the ones you OWN plus the ones you've JOINED — each with the address to pass as `domain` on memory_read, and on memory_write too where your membership scope is read_write; a read-only membership has that write refused. Use this to RE-FIND a room in a new session (e.g. 'what rooms do I have?', 'resume the room with Olya') instead of having to create or re-join it.",
1632
- inputSchema: {},
1633
- annotations: {
1634
- title: "List rooms",
1635
- readOnlyHint: true,
1636
- destructiveHint: false,
1637
- idempotentHint: true,
1638
- openWorldHint: true,
1639
- },
1640
- }, async () => {
1641
- // The same classifier the scope notes use, for the same reason: this handler
1642
- // did `Array.isArray(rooms) ? rooms : []` and then asserted "You have no
1643
- // shared rooms yet" — a claim about the account derived from a body it could
1644
- // not read. It is the third consumer of this payload and the third place the
1645
- // substitution was made; all three now go through one function that maps an
1646
- // unreadable body to `unknown`, never to `none`.
1647
- const rooms = classifyRooms(await apiFetch("/memory/rooms"), safeInline);
1648
- if (rooms.state === "unknown") {
1649
- // Byte-identical to the inline wording this replaces — the builder is
1650
- // shared so the four list surfaces answer the unreadable case with one
1651
- // sentence, not four drifting ones.
1652
- return unreadableAnswerReply("The room list", "a list of your rooms", "you have none");
1653
- }
1654
- if (rooms.state === "none") {
1655
- return {
1656
- content: [
1657
- {
1658
- type: "text",
1659
- text: "You have no shared rooms yet. Create one with memory_create_room, " +
1660
- "or join one with memory_join_room using an invite code.",
1661
- },
1662
- ],
1663
- };
1664
- }
1665
- // ARCHIVED ROOMS ARE LISTED HERE, unlike in the scope note — this tool's job
1666
- // is the inventory, and the `[archived]` tag says which ones cannot be read.
1667
- const list = rooms.rooms;
1668
- // Room name is OWNER-chosen — printed EXACTLY (src/names.ts), like every
1669
- // other room-name surface as of 0.8.1: the sanitiser listed "проект" and
1670
- // "план" as two "(unnamed room)" entries and quoted "Zoë" as "Zo".
1671
- // address/role/scope are server-shaped and keep the defensive sanitiser.
1672
- const lines = list.map((r) => {
1673
- const name = roomNamePhrase(r?.name);
1674
- const roomId = safeInline(r?.room_id);
1675
- // Always surface the canonical address: fall back to xroom:<room_id> when the server
1676
- // omits `address`, so the domain guidance this tool promises is never silently dropped.
1677
- const address = safeInline(r?.address) || (roomId ? `xroom:${roomId}` : "");
1678
- const role = safeInline(r?.role);
1679
- const scope = safeInline(r?.scope);
1680
- // No "use domain=..." on an archived room: core refuses EVERY read of one
1681
- // with a 403, for owner and member alike (see the archived-only note in
1682
- // src/scope.ts), so that clause was an instruction to make a call that
1683
- // cannot succeed. The address stays visible — it is the room's identity —
1684
- // but the line says what a read against it will do.
1685
- //
1686
- // For a live room, the write half is scope-gated the same way
1687
- // memory_join_room's usage sentence is (roomScopeVerdict, near
1688
- // isRoomDomain): this used to say "use domain=..." with no operation
1689
- // named, which read as an unqualified read+write invitation even for a
1690
- // "read" member — false, since core refuses that member's memory_write.
1691
- const verdict = roomScopeVerdict(scope);
1692
- const tail = r?.archived
1693
- ? address
1694
- ? ` [archived] — address ${address}, but every read is refused while it is archived`
1695
- : ` [archived] — every read is refused while it is archived`
1696
- : !address
1697
- ? ""
1698
- : verdict === "read_write"
1699
- ? ` — use domain="${address}" to read and write it`
1700
- : verdict === "read"
1701
- ? ` — use domain="${address}" on memory_read only; this membership is read-only, so memory_write to it will be refused`
1702
- : ` — use domain="${address}" on memory_read; this membership's write access was not reported`;
1703
- return `- ${name} (${role}${scope ? `, ${scope}` : ""})${tail}`;
1704
- });
1705
- const text = `Your shared rooms (${list.length}):\n${lines.join("\n")}`;
1706
- return {
1707
- content: [
1708
- {
1709
- type: "text",
1710
- // Legend after the cap: this is the one room surface long enough to
1711
- // actually overflow, and the legend must describe the names that
1712
- // SURVIVED the cut, not the ones it removed.
1713
- text: withDomainEscapeLegend(capResult(text, "The room list was truncated — some rooms are not shown."), ...list.map((r) => r?.name)),
1714
- },
1715
- ],
1716
- };
1717
- });
1718
- // --- Tool: vault_list ---
1719
- server.registerTool("vault_list", {
1720
- description: "List the secrets stored in your Mnemoverse Vault — by ALIAS and purpose only; the secret VALUE is never returned or shown to you, and no tool on this server returns it. Use this to check WHICH secrets the user has stored and under what alias (e.g. the user says 'do I have a GitHub token saved?'). Only YOUR account's secrets are listed.",
1721
- inputSchema: {},
1722
- annotations: {
1723
- title: "List vault secrets",
1724
- readOnlyHint: true,
1725
- destructiveHint: false,
1726
- idempotentHint: true,
1727
- openWorldHint: true,
1728
- },
1729
- }, async () => {
1730
- const r = await apiFetch("/vault/secrets");
1731
- // A 200 missing the `secrets` array used to print "No secrets are stored
1732
- // in your Vault yet." — an absence claim about the Vault derived from a
1733
- // body this client could not read. The family fix (classifyRooms, the
1734
- // domains guard) had stopped one tool short of here (truth F13,
1735
- // 2026-08-08). A genuinely empty array keeps the absence claim below.
1736
- const list = r?.secrets;
1737
- if (!Array.isArray(list)) {
1738
- return unreadableAnswerReply("The secret list", "a list of your Vault secrets", "none are stored");
1739
- }
1740
- if (list.length === 0) {
1741
- return {
1742
- content: [
1743
- {
1744
- type: "text",
1745
- text: "No secrets are stored in your Vault yet.",
1746
- },
1747
- ],
1748
- };
1749
- }
1750
- const lines = list.map((s) => {
1751
- const alias = safeInline(s?.alias) || "(no alias)";
1752
- const context = safeInline(s?.context);
1753
- return context ? `- ${alias} — ${context}` : `- ${alias}`;
1754
- });
1755
- const text = `Your Vault secrets (${list.length}) — alias and purpose only, never the value:\n` +
1756
- lines.join("\n");
1757
- return {
1758
- content: [
1759
- {
1760
- type: "text",
1761
- text: capResult(text, "The secret list was truncated — some secrets are not shown."),
1762
- },
1763
- ],
1764
- };
1765
- });
297
+ // The tools themselves live in src/tools.ts, shared with every other server
298
+ // that exposes Mnemoverse memory over MCP (ADR-025). This server's part is
299
+ // apiFetch above: the API key, the base URL and their refusals.
300
+ registerMemoryTools(server, { apiFetch });
301
+ // Three named entry points to those tools (src/prompts.ts); they call nothing.
302
+ registerMemoryPrompts(server);
303
+ // One saved memory by id, memory://item/{memory_id} (src/resources.ts).
304
+ registerMemoryResources(server, { apiFetch });
1766
305
  // --- Start ---
1767
306
  /**
1768
307
  * Opening the stdio transport at import time is what made every user-visible