[JxnLexn]

Summary

• add a complete, canonical MCP lifecycle for Contextual Content Retrieval (CCR): store, retrieve, inspect, list, delete, and stats
• keep CCR data principal-scoped and in memory while adding TTLs, metadata, LRU eviction, pagination, and bounded block/principal/global memory usage
• cap full MCP retrieval responses at 256 KiB and guide callers toward head, tail, lines, grep, or stats for larger blocks
• register the CCR schemas and read/write scopes in the canonical MCP catalogs and include compression-only tools in the runtime tool count
• keep compression fail-open when CCR storage cannot accept a block, including fuzzy session deduplication and ionizer paths

Motivation

CCR previously exposed retrieval only and used an entry-count-only in-memory map. MCP clients could not manage the full content lifecycle, inspect stored metadata, or understand capacity and expiration behavior. The retrieve tool was also absent from the canonical schema and scope maps, which made discovery and authorization metadata incomplete.

This change turns CCR into a bounded, caller-isolated MCP context store without adding persistence or local client hooks.

Behavior and limits

• storage remains in memory and is cleared on restart
• maximum block size: 2 MiB UTF-8
• maximum storage per principal: 16 MiB
• maximum global storage: 64 MiB
• default TTL: 24 hours; maximum TTL: 7 days
• full MCP retrieval limit: 256 KiB
• audit entries contain hashes and size/type/TTL metadata, never stored content

Validation

• npm run lint
• npm run typecheck:core
• 63 targeted Node tests covering CCR compatibility, principal isolation, TTL, LRU, byte limits, ranged retrieval, and MCP registration
• 6 targeted Vitest MCP/tool-search tests
• Prettier checks and git diff --check
• npm run check:docs-all (passes hard gates; existing soft documentation drift warnings remain outside this change)

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request introduces six new canonical Caller-isolated Content Retrieval (CCR) lifecycle tools to the MCP server, increasing the total unique tool count to 104. The underlying CCR engine has been refactored to support LRU eviction, TTLs, and strict memory limits (per-block, per-principal, and global). The review feedback focuses on critical performance optimizations on hot paths, specifically recommending a lazy expiration strategy via a new getActiveEntry helper to avoid O(N) full-map scans on every read, maintaining a principalBytesMap to reduce principal byte calculations to O(1), optimizing array copying in listCcrBlocks, and removing redundant purges.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[diegosouzapw]

Thanks for this — the CCR lifecycle work is thorough and well-tested. Ran the full targeted suite in an isolated worktree: all 29 Node tests + the 4 Vitest catalog tests pass, ESLint is clean on every touched file, and the principal-isolation / audit-no-content guarantees check out exactly as described (cross-tenant retrieve/inspect/list all correctly return empty/not-found for a different caller, and the store audit input never carries raw content).

Two small non-blocking follow-ups we'll likely fold in before/at merge:

• docs/diagrams/mcp-tools-94.mmd/.svg are now orphaned since the embed was removed from docs/frameworks/MCP-SERVER.md — worth deleting or regenerating for the 104-tool count, and touching up the docs/diagrams/README.md row.
• The zh-CN translation of MCP-SERVER.md still shows the old 94-tool diagram/count — pre-existing i18n-doc-sync debt, not something this PR needs to fully close, but flagging it.

One perf nit for a future PR (not this one): purgeExpired in ccr/index.ts still does a full map scan on every tryStoreBlock/listCcrBlocks/getCcrStoreStats call — the point-read paths got the O(1) getActiveEntry treatment but the write/list paths didn't. Bounded at 5,000 entries so it's not urgent, just noting it mirrors the open comment from the automated review.

Nothing here blocks merge — great work.

[diegosouzapw]

Thanks @JxnLexn! Merged into release/v3.8.49 after combined merge-train validation (static gates + tests + vitest green on the merged tree). Where quality gates flagged growth we decomposed/extracted inside your branch keeping you as author — including renumbering the reasoning-routing migration slot and the ProviderDetailPageClient rebaseline annotation.