Theme F — Mempalace MCP Integration Pattern: Direct vs Wrapped

Status: Investigation complete — awaiting Liam ratification Last verified: 15/05/2026 (S240 WP3) Scope: Mempalace direct vs wrapped in KH MCP. Unblocks docs/plans/phase-0-investigation/architecture/06-mcp-tooling.md. Non-blocking on Wave 2 split sub-docs (02-data-flow.md + 05-qa-flow.md). Classification: Research-only — no code changes. Output teed up for Liam pre-decision.

1. The Question

Q4.5 (Finding 03 §6, feedback-findings-review.md §5.1 Theme F): Are we using the mempalace MCP server directly (Claude calls it as a separate plugin alongside KH MCP), or should KH MCP wrap mempalace tools — exposing them through the KH tool surface?

The third option — “ignore mempalace entirely from KH MCP” — is not under consideration: both already coexist and the decision-graph confirms adoption (Q4.1 Shape A temporal columns confirmed; Q4.5 Shape C wing-mapping confirmed; mempalace plugin live in ~/.claude/settings.json enabledPlugins). The question is solely about call topology.

2. Context

2.1 What is mempalace?

Mempalace is the canonical memory system for KH, replacing the auto-memory file system on 10/05/2026. It runs as an Anthropic plugin (mempalace@mempalace v3.3.5) enabled in ~/.claude/settings.json enabledPlugins. Stop and PreCompact hooks fire automatically each session — no manual ingest needed. (CLAUDE.md “Memory (Mempalace)” section.)

Mempalace organises memory into wings (one per worktree), rooms, and drawers. As of S43: knowledge-hub wing holds ~75,878 drawers; total ~128k drawers across 12 wings. The MCP tool surface is mempalace-namespaced: mempalace_status, mempalace_list_wings, mempalace_kg_stats, mempalace_kg_query, mempalace_diary_write, mempalace_diary_read, mempalace_search (partial — wing-filter still errors as of v3.3.5; workaround: search default, filter client-side by wing field).

Known production limitation: mempalace_search with a wing parameter errors with Error executing plan: Internal error: Error finding id. Workaround in place: search without wing filter, filter client-side. This is tracked as OQ-Q45-A and classified as non-issue for KH schema — production-readiness track item. (CLAUDE.md “Memory (Mempalace)” §mempalace_search; feedback-findings-review.md §2.3 OQ-Q45-A.)

KH-to-mempalace tenant mapping: S229 S3 spike confirmed Shape C: mempalace wing parameter maps 1:1 to KH workspace_id. No schema change needed — every KH-side mempalace call must pass wing: <workspace_id>. Wire-up checklist lands in architecture/06-mcp-tooling.md. (finding 03 §6, 0.9-decision-graph.md Q4.5.)

2.2 What is KH MCP?

KH MCP is the Knowledge Hub’s own MCP server, exposed via Streamable HTTP transport at /api/mcp/mcp (Vercel-hosted). It registers 58 tools across 16 category files (lib/mcp/tools/), 12 resources, and 7 prompts. Entry point: app/api/mcp/[transport]/route.ts. Plugin bundle at lib/mcp/plugin-bundle.ts (auto-generated base64 ZIP, ~9 lines of committed source). Full inventory: docs/generated/mcp-inventory.md.

All 58 tools use per-user Supabase clients via createMcpClient(extra.authInfo) — OAuth bearer token passed as Authorization: Bearer header so Supabase RLS policies apply per authenticated user. Write tools additionally call checkMcpRole(extra.authInfo, ['admin', 'editor']). (lib/mcp/auth.ts; lib/mcp/CLAUDE.md.)

KH MCP is deliberately prefix-free on tool names (see tools/index.ts comment: “Tool naming: names intentionally omit a service prefix (e.g. kb_). The Knowledge Hub MCP server is designed as a single-purpose connector — users won’t have multiple KB servers”).

2.3 Why this decision matters

The mempalace direct vs wrapped decision gates architecture/06-mcp-tooling.md — the one remaining STILL-OPEN sub-doc in the 9-way architecture split. All 8 other sub-docs are READY-TO-DRAFT as of S236 close. Theme F is the lone blocker. It is explicitly flagged at:

feedback-findings-review.md §5.1 Theme F (“STILL-OPEN — outside prereq scope. Operational decision.”)
00-synthesis-v2.md §5.2 row 1 (“Mempalace direct vs wrapped in KH MCP — operational. Required to unblock WP4 06-mcp-tooling.md.”)
0.9-decision-graph.md §11.4.2 row 1 (“Lone STILL-OPEN gate blocking WP4 06-mcp-tooling.md.”)
INV-architecture-split-readiness.md §5 (“Liam pre-decision needed: 06-mcp-tooling (Theme F MCP-action review pass) — 1 gate, 1 sub-doc blocked.”)

3. Pattern Definitions

Before assessing each pattern, a precise definition prevents ambiguity:

Direct pattern: Claude has two MCP servers in its context simultaneously — KH MCP (at api/mcp/mcp) and mempalace (as Anthropic plugin). Claude calls mempalace_search, mempalace_diary_read, etc. directly. KH MCP has no knowledge of mempalace and no adapter code. The two servers are independent processes. Claude is responsible for coordinating calls across both.

Wrapped pattern: KH MCP exposes KH-namespaced tool wrappers (e.g. memory_search, memory_record_session) that internally call the mempalace MCP server. Claude calls one server. KH MCP acts as a proxy/adapter layer. Claude never calls mempalace directly.

A hybrid variant is also possible (discussed in §8 below): Direct for dev-workflow memory (session hooks, diary, status), Wrapped for tenant-scoped KB memory operations (workspace-search, KG queries). This is assessed as part of the recommendation.

4. Direct Pattern — Assessment

4.1 Robustness

Failure modes. If mempalace MCP crashes (plugin unavailable, v3→v4 upgrade in progress, or the known mempalace_search wing-filter bug surfaces as a full outage), KH MCP is entirely unaffected. Tools in KH MCP continue to operate normally. Claude loses memory access but gains no new failure surface. The failure blast radius is narrow and owned by the mempalace plugin, not KH.

Inference: because KH MCP has zero coupling to mempalace in this pattern, there is no cascade risk. KH MCP failures are similarly isolated from mempalace. This is the maximum fault-isolation configuration.

Upgrade/version coupling. Mempalace v3.4 or v4 ships: Liam updates ~/.claude/settings.json to the new plugin version; KH MCP is unchanged. Zero adapter maintenance. Downside: if mempalace changes tool names or parameter shapes, Claude’s call patterns break silently — but this is a Claude-prompt-update problem, not a KH code change.

Latency. No extra hop. Claude calls mempalace directly over the plugin transport. KH MCP calls go to Vercel. Two independent transports, neither adding overhead to the other.

Auth/permissions. Two distinct auth surfaces. KH MCP auth: OAuth bearer token enforcing Supabase RLS per user (see lib/mcp/auth.ts). Mempalace auth: plugin-level, controlled by ~/.claude/settings.json. There is no mechanism for KH MCP to gate or restrict mempalace access based on KH workspace membership or KH roles. Any user with the plugin enabled can call any mempalace tool. If KH eventually has users who should have limited memory access (e.g. read-only roles should not write diary entries), direct provides no enforcement point.

For the current single-tenant Phew deployment, this gap is not yet load-bearing. Inference: for multi-tenant v1.x, the absence of role-based enforcement on memory writes becomes a concern.

4.2 Extensibility

New mempalace features. When mempalace ships a new MCP tool (e.g. mempalace_kg_timeline — already in the system-reminder tool list), it becomes available immediately in Claude’s context without any KH code change. This is a significant advantage in the short term while mempalace is actively developing.

KH-specific extensions. Direct makes it structurally impossible for KH to inject context into mempalace calls. The wire-up checklist requires that every mempalace MCP call passes wing: <workspace_id> (finding 03 §6.3). In the direct pattern, Claude must remember to pass wing: <workspace_id> on every call. This is not guaranteed — Claude prompting discipline is not equivalent to code enforcement. If a tool call omits wing, the memory operation falls to the default wing (the agent’s personal wing), silently contaminating or failing to scope the operation.

Cross-tool composition. The decision-graph notes Q4.2 (Shape B strict-extract mode) and Q4.10 (replacing get_reorientation with mempalace per-user memory). In the direct pattern, composite “search Q&A pairs + relevant memories” flows require Claude to make two separate calls to two separate servers and synthesise the results itself. There is no single tool that can return both KB search results and relevant memories together. Claude coordination works but is more brittle: if Claude’s context window is constrained, two-step multi-server tool use is more likely to be abbreviated.

4.3 Operational Implications

Plugin distribution. KH already distributes a plugin bundle (lib/mcp/plugin-bundle.ts — auto-generated base64 ZIP, committed, ~9 lines). In the direct pattern, users need BOTH the KH plugin AND the mempalace plugin enabled. This is already the production state for the dev workflow. However, if KH is used in Claude.ai or Claude Desktop by non-dev users, requiring two separate plugin enablements adds friction. The KH plugin bundle is already deployed via the Vercel endpoint; mempalace is distributed separately by the mempalace project.

Observability. KH has telemetry via logBestEffortWarn (Sentry breadcrumb + structured logger) used in lib/mcp/tools/content.ts, review.ts, guides.ts. The audit_log table records platform operations. Op_id propagation is resolved (N7, RESOLVED-S236): trigger-driven for platform-wide audit cohesion + cocoindex per-flow op_id. In the direct pattern, mempalace operations are entirely outside this telemetry surface. A memory write that corrupts a wing is invisible to KH’s audit trail. Memory reads that fail (e.g. the wing-filter bug) surface only in Claude’s chat output, not in any KH-side log.

Tenant scoping. KH is nominally multi-tenant (4 prod workspaces; workspaces table with workspace_id as tenant scope; Supabase RLS per workspace). Mempalace organises memory by wing — and the confirmed mapping is wing ↔ workspace_id (Q4.5, Shape C). In the direct pattern, enforcement of this mapping depends entirely on Claude’s prompt discipline. Code cannot enforce it. With a single tenant (Phew) this is tolerable; with multiple tenants, cross-tenant memory contamination is a real risk if Claude omits the wing parameter.

Auth (multi-server). Claude Desktop / Claude.ai authenticate at the MCP server level. Two servers = two authentication surfaces to manage and audit. For the current single-user/single-org scenario this is invisible, but as KH scales toward multiple end-user organisations (each with potentially different mempalace wings), maintaining two separate trust relationships becomes an operational surface.

4.4 Architecture Coherence

“One record, many views” principle (CLAUDE.md Key Product Design Principles). Memory is, by this principle, a record like any other — it should have a single authoritative store with multiple consumers. In the direct pattern, memory operates as a parallel, independent record store with no integration into KH’s data model. The principle implies that KH should have a coherent view of all data relevant to a workspace — memory included. Direct violates the spirit of this principle, though not any hard rule.

“AI is invisible infrastructure” principle (CLAUDE.md). Direct exposes the mempalace tool surface verbatim to Claude — tool names like mempalace_status, mempalace_list_wings, mempalace_diary_write. These are mempalace-branded tools visible in Claude’s context. Any user exploring available tools sees both search_knowledge_base (KH-namespaced) and mempalace_search (mempalace-namespaced). This dual-surface fragmentation means the AI infrastructure is partially visible as a seam, which is contrary to the “invisible infrastructure” design principle.

Tool namespace coherence. The tools/index.ts comment explicitly states KH MCP is “designed as a single-purpose connector” without service prefixes because “users won’t have multiple KB servers.” The direct pattern introduces a second server with a mempalace namespace, creating exactly the multi-server namespace collision the naming convention was designed to avoid.

Q4.10 “Replace reorient with mempalace per-user memory” (PROVISIONAL, decision-graph §3.B). This item presupposes that at some point, the get_reorientation tool (currently tool #7 in the inventory, CLAUDE.md comment “Q4.10 gated on MCP-action review pass”) is replaced or augmented by mempalace per-user memory. In the direct pattern, this is structurally awkward: get_reorientation is a KH MCP tool; mempalace is a separate server. The tool cannot call mempalace internally. Instead, the reorientation pattern requires Claude to call both get_reorientation (KH MCP) AND mempalace_diary_read/mempalace_search (mempalace) to construct a full context picture.

5. Wrapped Pattern — Assessment

5.1 Robustness

Failure modes. If mempalace crashes while KH MCP wraps it, memory operations within KH MCP return errors — but KH MCP itself remains up. The blast radius is wider than direct: a mempalace crash takes down not just memory access but also any composite KH tools that mix KB search and memory. However, tool failures in MCP are recoverable — Claude receives an error response and can proceed without memory. The critical risk is KH MCP crashing because of mempalace. If wrapping is done naively (synchronous proxy with no circuit-breaker), a mempalace timeout during a KH MCP call can cause the KH MCP request to hang. This is an implementation risk, not a structural inevitability — proper circuit-breaking and timeout handling removes it.

Upgrade/version coupling. Mempalace v3.4 ships with changed tool signatures: KH MCP’s adapter layer must be updated before memory tools work again. This is the primary maintenance burden of wrapping. The adapter cost is bounded if wrapping is thin (pass-through with context injection), but every mempalace API change becomes a KH code change + test + deploy cycle before users see the benefit. For a rapidly evolving plugin like mempalace (v3.3.5 with active PR activity per CLAUDE.md notes on PR #1396), this coupling is materially significant.

Inference: mempalace v4-alpha with PG backend (Q4.6 DEFERRED-POST-LAUNCH, PRs #665 + #1337) is a larger structural change that would require a significant wrapper rewrite if KH wraps v3.3.5 semantics.

Latency. One extra hop: Claude → KH MCP → mempalace plugin transport → mempalace server. The inner hop is a local plugin call (not a network round-trip in the same sense), so the overhead is small in practice. However, Vercel function cold starts add latency to every KH MCP call already (mitigated by lazy imports in tools/shared.ts). Adding mempalace calls to KH MCP tool handlers increases the cold-start-adjacent surface slightly.

Auth/permissions. Single auth surface: KH MCP’s OAuth bearer token enforces Supabase RLS. Wrapping allows KH MCP to apply KH role checks before delegating to mempalace. An editor-only mempalace write operation is enforced by checkMcpRole(extra.authInfo, ['admin', 'editor']) before the inner mempalace call. This is strictly more capable than direct from a role-based access perspective.

5.2 Extensibility

New mempalace features. Every new mempalace MCP tool requires a corresponding KH MCP wrapper before Claude can access it. If mempalace ships 3 new tools in a release, KH must write 3 new wrapper tools, run tests, and deploy before users benefit. This is the primary extensibility cost. For a memory system with active development, this is a real maintenance burden.

KH-specific extensions. Wrapping makes it straightforward to inject KH context. The wire-up checklist requirement — “every mempalace MCP call from KH must pass wing: <workspace_id>” (finding 03 §6.3) — becomes code-enforced rather than prompt-discipline-enforced. The handler signature receives workspace_id from the KH auth context (via extra.authInfo), passes it as wing to the inner mempalace call. Claude never needs to pass wing explicitly — it is injected transparently. This eliminates the cross-tenant contamination risk at the code level.

Concrete example of KH-specific extension wrapping enables: a memory_search tool that (a) accepts query + optional workspace_id, (b) injects the authenticated user’s active workspace as wing if omitted, (c) applies the client-side wing-filter workaround transparently (hiding the v3.3.5 bug from Claude), and (d) returns results already filtered to the correct workspace. Claude calls one tool; KH MCP handles all the plumbing.

Cross-tool composition. The decision-graph Q4.10 item (replace get_reorientation with mempalace per-user memory) becomes natural in the wrapped pattern: get_reorientation (tool #7) can internally call mempalace memory search to augment its output with session context. The composite result is returned in a single MCP response. No multi-server coordination required by Claude.

Similarly, a “bid context” tool could call search_knowledge_base, get_bid_detail, AND memory_search in a single handler, returning a unified context block. This pattern is impossible in direct.

5.3 Operational Implications

Plugin distribution. Users need only the KH plugin. If KH wraps mempalace, the mempalace plugin does not need to be separately enabled. This is a significant simplification for non-dev users of the KH Claude integration. For the current single-user Phew deployment it makes no practical difference, but it is materially relevant for any future expansion to additional users.

However: wrapping requires that KH MCP can call the mempalace plugin from within its server-side TypeScript code. Mempalace is an Anthropic plugin running in the Claude Desktop/Claude.ai plugin runtime — it is not a standalone HTTP server that arbitrary TypeScript code can call. This is the critical implementation-feasibility question for the wrapped pattern. See §6 (Comparison Matrix) for assessment.

Observability. Memory operations flow through KH MCP’s telemetry surface. logBestEffortWarn in lib/supabase/telemetry.ts (Sentry + structured logger) can be called on mempalace call failures. audit_log operations can include a memory.search or memory.write event category. Op_id propagation (N7 RESOLVED-S236) means memory operations could carry the same op_id as the KH pipeline operation that triggered them, enabling end-to-end correlated traces. This is not achievable in the direct pattern.

Tenant scoping. The wing: <workspace_id> injection is code-enforced. No cross-tenant contamination risk, even across multiple tenants. The KH auth context provides workspace_id; the wrapper passes it unconditionally. This is a clean multi-tenant architecture.

Deployment. KH MCP is deployed on Vercel (Next.js App Router, serverless functions). A wrapper that calls mempalace from within a Vercel function requires that the mempalace plugin be accessible as an HTTP endpoint or library from within the Vercel runtime. Inference: Anthropic plugins run in the Claude Desktop / Claude.ai runtime, not as standalone services. This means a KH MCP tool running on Vercel cannot call the mempalace plugin directly — the plugin only exists in Claude’s local plugin runtime. This is a structural barrier to the wrapped pattern as typically conceived.

5.4 Architecture Coherence

“One record, many views” principle. Wrapping brings memory into the KH tool surface and makes it a first-class part of the KH data model from Claude’s perspective. Memory is accessed through KH-namespaced tools; KH has visibility into and control over all memory operations on its data. This is coherent with the principle.

“AI is invisible infrastructure” principle. Wrapped tools would be named with KH conventions — memory_search, memory_record, memory_status — not mempalace_search, mempalace_diary_write. The mempalace brand is invisible. The infrastructure seam disappears. This is coherent with the principle.

Tool namespace coherence. All tools in Claude’s context are KH-namespaced. The single-server design intent of tools/index.ts is preserved. No competing namespaces.

Q4.10 reorientation replacement. get_reorientation can delegate to memory internally. The replacement of static reorientation with session-aware memory is an implementation detail inside one tool handler, transparent to Claude.

6. Structural Barrier: Wrapped Pattern Feasibility

Before concluding, the key feasibility constraint must be examined explicitly.

The problem: The wrapped pattern assumes KH MCP server-side TypeScript code (running on Vercel serverless functions) can call the mempalace MCP plugin. However, mempalace is an Anthropic plugin — it runs in the Claude Desktop or Claude.ai plugin runtime. It is NOT a standalone HTTP service that can be called from arbitrary TypeScript code on Vercel.

Consequence: A naive implementation of wrapping — where a KH MCP tool handler calls fetch("http://mempalace-plugin-endpoint/...") — does not work. The mempalace plugin endpoint exists only within Claude’s local plugin runtime, not as a public HTTP API.

Possible resolution paths:

Mempalace as a standalone MCP HTTP server (not just a plugin): If mempalace v4 or a separately deployed instance of mempalace runs as a standalone HTTP MCP server (not just a plugin), then KH MCP could call it from Vercel using the MCP client SDK. This depends on mempalace’s deployment model, which is DEFERRED-POST-LAUNCH (Q4.6, PG backend PRs #665 + #1337).
Client-side wrapping (MCP gateway pattern): Rather than Vercel-side wrapping, a lightweight local gateway process runs alongside Claude Desktop, forwarding calls from KH MCP to mempalace. This is architecturally complex and introduces a new operational component.
SDK-level wrapping within Claude’s context: Not applicable — KH MCP tools run on Vercel, not in Claude’s local runtime.
Partial wrapping — server-side context injection only: KH MCP does not wrap mempalace tools but does inject KH context into Claude’s system prompt (e.g. “always pass wing: <workspace_id> when calling mempalace tools”). This is prompt-discipline enforcement, not code enforcement — closer to the direct pattern with guardrails.

Assessment: Full wrapping (KH MCP server calls mempalace) is not feasible in the current architecture unless mempalace is deployed as a standalone HTTP server. This is a near-term constraint that may lift with v4-alpha PG backend, but that is DEFERRED-POST-LAUNCH.

The feasibility barrier does not eliminate all wrapping options — it specifically rules out server-side wrapping. Client-side or prompt-side approaches are available but are weaker guarantees.

7. Comparison Matrix

Axis	Direct	Wrapped (full, server-side)	Wrapped (partial — prompt injection)
Failure isolation	Maximum — KH MCP unaffected by mempalace crash	Moderate — mempalace timeout can hang KH MCP tool (mitigated by circuit-breaker)	Same as direct
Upgrade coupling	None — mempalace upgrades invisible to KH	High — every API change = KH code change + deploy	None — same as direct
New mempalace tools	Auto-available immediately	Requires KH wrapper per tool	Auto-available immediately
KH context injection (`wing: workspace_id`)	Prompt-discipline only (unreliable)	Code-enforced (reliable)	Partially enforced via system-prompt guardrails (better than direct, worse than code)
Cross-tenant safety	Prompt-discipline only	Code-enforced	Partially enforced
Composite tools (KH + memory)	Requires Claude multi-server coordination	Single KH tool handler	Requires Claude multi-server coordination
Observability (audit trail)	Memory ops invisible to KH	Full KH telemetry coverage	Memory ops invisible to KH
Plugin distribution (users)	Two plugins needed	One plugin needed	Two plugins needed
Auth enforcement	Two surfaces; no KH role gating on memory	Single surface; KH role gating possible	Two surfaces; no KH role gating on memory
Latency	No extra hop	One extra hop (small)	No extra hop
Namespace coherence	Dual namespace (KH + mempalace)	Single KH namespace	Dual namespace
”AI invisible infra” principle	Violated — mempalace brand visible	Preserved — KH-named tools	Violated — mempalace brand visible
”One record many views” principle	Partially violated — memory is a parallel silo	Preserved — memory within KH surface	Partially violated
Feasibility (current architecture)	Yes — already live	No for Vercel-side; requires mempalace as standalone HTTP server	Yes — prompt/system-prompt injection
Maintenance burden	Low — zero adapter code	High — adapter per tool + upgrade cadence	Low — prompt maintenance only
Multi-tenant readiness	Weak — no code-enforced wing scoping	Strong — code-enforced	Moderate — relies on prompt discipline

8. Recommendation

Recommended approach: Direct (immediate), with a structured migration path to wrapped once mempalace is deployable as a standalone MCP HTTP server.

Rationale follows.

8.1 Why direct now

The wrapped pattern’s most valuable properties — code-enforced wing: <workspace_id> injection, role-based access control on memory operations, unified observability, composite tools — all depend on KH MCP server-side code being able to call mempalace. As established in §6, this is not feasible in the current architecture: mempalace runs as an Anthropic plugin in Claude’s local runtime, not as a standalone HTTP server callable from Vercel. Full server-side wrapping requires mempalace v4 PG-backend deployment as a standalone service, which is DEFERRED-POST-LAUNCH (Q4.6).

Given this structural barrier, recommending wrapped now would be recommending an architecture that cannot be implemented. Direct is not a compromise — it is the only pattern that is feasible without a prerequisite deployment change outside KH’s control.

Separately, the direct pattern has genuine strengths for the current deployment:

Upgrade resilience. Mempalace is under active development (PR #1396, v3.3.5, v4-alpha activity). Direct means KH does not need to track mempalace’s API surface. At v3.3.5 with known mempalace_search wing-filter issues, the last thing KH needs is coupling its deployment to mempalace’s release cadence.
Auto-availability of new tools. The mempalace tool list in the system-reminder includes mempalace_kg_timeline, mempalace_memories_filed_away, mempalace_reconnect, and others that are deferred tools. As mempalace ships these, direct makes them immediately available. This matters while the memory system is maturing.
Failure isolation. The current production context (single-tenant Phew, v3.3.5 with known partial failures) benefits maximally from the isolation the direct pattern provides. If mempalace fails, KH MCP keeps serving.

8.2 What direct requires to be safe

Direct is not a “do nothing” option. To be safe at v1, direct requires the following guardrails:

System-prompt enforcement of wing: <workspace_id>. The wire-up checklist (finding 03 §6.3) must be surfaced as a KH-side system-prompt instruction in every context where Claude calls mempalace on behalf of a workspace. This is the strongest enforcement available without server-side code. Claude will be instructed: “Every mempalace MCP call that operates on workspace data MUST pass wing: <workspace_id> where workspace_id is the active workspace context. Calls without wing are banned in workspace contexts.”
Wing-filter workaround documented. The mempalace_search wing-filter bug (OQ-Q45-A) and its client-side workaround must be documented in 06-mcp-tooling.md as a known limitation with a workaround, not as a silent failure mode.
Reorientation tool transition documented. Q4.10 (PROVISIONAL — replace get_reorientation with mempalace per-user memory) is explicitly gated on the MCP-action review pass. In the direct pattern, this becomes: get_reorientation (tool #7) remains as-is for v1; Claude is additionally instructed to call mempalace_search or mempalace_diary_read for session context if needed. The static get_reorientation and the mempalace per-session memory coexist. This is a short-term duality that resolves when the Q4.10 PROVISIONAL becomes a concrete decision.

8.3 Migration path to wrapped (when mempalace v4 lands as standalone)

When mempalace is deployable as a standalone MCP HTTP server (Q4.6 condition: v4-alpha PG backend reaches production-stable), the case for wrapped strengthens materially. At that point:

KH MCP can call mempalace via @modelcontextprotocol/sdk client from within Vercel functions.
wing: <workspace_id> injection becomes code-enforced rather than prompt-enforced.
Composite tools (get_reorientation + memory, search_knowledge_base + memory) become feasible in single-handler form.
The mempalace brand disappears behind KH-namespaced tools.
The audit trail covers memory operations.

The migration at that point is additive: KH wraps the tools it needs to intercept (memory_search, memory_record for workspace-scoped operations), while retaining direct access for dev-workflow tools (mempalace_status, mempalace_list_wings, mempalace_diary_read for agent session context). A hybrid is viable: wrapper for tenant-scoped tools, direct for dev-workflow tools.

Escape-hatch clause: If Liam decides that the namespace incoherence and observability gap of direct are unacceptable today — and is willing to accept the maintenance burden of an adapter layer AND the feasibility constraint means implementing a lightweight proxy process rather than server-side wrapping — the hybrid partial-wrap (prompt-injection for wing scoping + proxy for composite tools) is viable. The recommendation above assumes Liam prefers minimal maintenance burden and maximum upgrade resilience for v1.

8.4 Implications for `06-mcp-tooling.md`

The 06-mcp-tooling.md sub-doc can now be drafted with the following confirmed decisions:

Pattern: Direct (v1). Mempalace called as separate plugin alongside KH MCP. No KH MCP adapter code.
Wire-up checklist: Every mempalace call in workspace context MUST pass wing: <workspace_id>. Enforced via system-prompt instruction and documented in 06-mcp-tooling.md. Code enforcement deferred to v4 migration.
Wing-filter bug workaround: Documented. Search default (no wing param), filter client-side by wing field.
Q4.10 reorientation: PROVISIONAL remains provisional. get_reorientation (tool #7) stays for v1; mempalace per-session memory is additive, not a replacement. Revisit at v1.1 or when mempalace v4 lands.
Q4.8 kg_invalidate RPC: Gated on Q4.1 Shape A temporal columns — add to 06-mcp-tooling.md as a pending action item.
Migration trigger: Document the condition for migrating from direct to wrapped: “when mempalace v4 PG-backend reaches production-stable and is deployable as a standalone MCP HTTP server (Q4.6 gate), evaluate wrapping workspace-scoped tools.”

9. What Liam Needs to Ratify

One-line decision statement:

Adopt direct pattern for v1: mempalace called as a separate Anthropic plugin alongside KH MCP, with system-prompt enforcement of wing: <workspace_id> for all workspace-scoped memory calls; document migration path to wrapped once mempalace v4 is deployable as a standalone MCP HTTP server.

If Liam agrees, this unblocks architecture/06-mcp-tooling.md for drafting.

If Liam disagrees and prefers wrapped now, the follow-on question is: wrapped via what mechanism? The options are (a) accept that full server-side wrapping is not feasible until mempalace v4; (b) implement a lightweight local proxy process (new operational component); or (c) prompt-injection wrapping only (closer to direct with guardrails). A second investigation pass would be needed to scope (b).

Appendix: Source Citations

Claim	Source	Location
Mempalace plugin v3.3.5 enabled in `enabledPlugins`	`CLAUDE.md`	”Memory (Mempalace)” section
`mempalace_search` wing-filter bug	`CLAUDE.md`	”Memory (Mempalace)” `mempalace_search` ⚠ PARTIAL
Shape C confirmed (wing ↔ workspace_id 1:1)	`0.9-decision-graph.md` Q4.5	§3.B
Theme F STILL-OPEN	`feedback-findings-review.md`	§5.1 Theme F + §5.2.3 Q4.5 row
Theme F STILL-OPEN (synthesis)	`00-synthesis-v2.md`	§5.2 row 1
Theme F STILL-OPEN (decision graph)	`0.9-decision-graph.md`	§11.4.2 row 1
`06-mcp-tooling` lone STILL-OPEN gate	`INV-architecture-split-readiness.md`	§5 (per-sub-doc gates table)
Wire-up checklist requirement	`finding 03 §6.3`	`10-feedback-investigation-findings/03-q113-q55-q311-q45-workspace-types.md`
Q4.10 replace reorientation (PROVISIONAL)	`0.9-decision-graph.md`	§3.B Q4.10
Q4.6 v4 PG backend DEFERRED-POST-LAUNCH	`0.9-decision-graph.md`	§3.C Q4.6
Q4.8 kg_invalidate RPC	`0.9-decision-graph.md`	§3.B Q4.8
KH MCP 58 tools, per-user Supabase client	`lib/mcp/tools/index.ts` + `lib/mcp/auth.ts`	Lines 1-29 (index); Lines 1-60 (auth)
KH MCP tool naming — no service prefix	`lib/mcp/tools/index.ts`	Lines 26-28
`defineTool` annotation enforcement	`lib/mcp/tools/shared.ts`	Lines 54-80
Telemetry — `logBestEffortWarn`	`lib/supabase/telemetry.ts`	Lines 1-50
N7 op_id RESOLVED-S236 (trigger-driven)	`00-synthesis-v2.md`	§2.3 N7 row
Plugin bundle 9 lines, base64 ZIP	`lib/mcp/plugin-bundle.ts`	Line 1-9
”AI is invisible infrastructure” principle	`CLAUDE.md`	”Key Product Design Principles"
"One record, many views” principle	`CLAUDE.md`	”Key Product Design Principles”

End of investigation. 15/05/2026. S240 WP3 Theme F.

Theme F — Mempalace MCP Integration Pattern: Direct vs Wrapped

Theme F — Mempalace MCP Integration Pattern: Direct vs Wrapped

1. The Question

2. Context

2.1 What is mempalace?

2.2 What is KH MCP?

2.3 Why this decision matters

3. Pattern Definitions

4. Direct Pattern — Assessment

4.1 Robustness

4.2 Extensibility

4.3 Operational Implications

4.4 Architecture Coherence

5. Wrapped Pattern — Assessment

5.1 Robustness

5.2 Extensibility

5.3 Operational Implications

5.4 Architecture Coherence

6. Structural Barrier: Wrapped Pattern Feasibility

7. Comparison Matrix

8. Recommendation

8.1 Why direct now

8.2 What direct requires to be safe

8.3 Migration path to wrapped (when mempalace v4 lands as standalone)

8.4 Implications for 06-mcp-tooling.md

9. What Liam Needs to Ratify

Appendix: Source Citations

8.4 Implications for `06-mcp-tooling.md`