Upgrade the full MCP service: compatibility, typed APIs, resources, providers, and shared daemon access

[Lauritz-Timm]

Summary

Upgrade ICM's complete MCP service as one coordinated program: protocol compatibility, tool registration and dispatch, typed outputs, project context resources, provider integration, and shared-daemon access.

The work is delivered through focused phase branches/PRs. Phases 3, 4, and 6 depend on Phase 2 and are intentionally maintained as sibling branches from that prerequisite. Phase 5 remains standalone. The post-integration HTTP/MCP parity fixes are carried by the combined mcp-integration branch after the phase PRs.

Phase and branch plan

Phase	Fork branch	PR	Base / dependency	Status
1 — Isolated compatibility/evaluation suite	feat/mcp-phase-1-evaluation	#7	develop (standalone)	In progress in fork
2 — MCP protocol core and canonical tool service	feat/mcp-phase-2-core	#8	develop	In progress in fork
3 — Typed MCP tool outputs	feat/mcp-phase-3-typed-outputs	#9	feat/mcp-phase-2-core / Phase 2	In progress in fork
4 — Active-project context resource	feat/mcp-phase-4-project-context	#10	feat/mcp-phase-2-core / Phase 2	In progress in fork
5 — Safe trusted-provider configuration	feat/mcp-phase-5-trusted-providers	#11	develop (standalone)	In progress in fork
6 — Shared-daemon HTTP transport and stdio proxy	feat/mcp-phase-6-http-proxy	#12	feat/mcp-phase-2-core / Phase 2	In progress in fork

The fork PRs above are the current working targets for these phases.

Scope

This issue covers the full MCP service boundary:

• protocol negotiation, connection lifecycle, JSON-RPC behavior, and framing;
• tool discovery, schemas, annotations, availability, and execution;
• legacy and modern response formats;
• MCP resources for active-project context;
• configuration for supported MCP providers;
• stdio and authenticated HTTP transport through the shared daemon; and
• compatibility, isolation, security, and performance verification.

Phase 1 — Isolated compatibility and evaluation suite

Create a fully self-contained evaluation suite for the MCP service. It must not read or modify real ICM state, provider configuration, credentials, external services, or the network.

Phase 2 — MCP protocol core and canonical tool service

Unify the MCP protocol and tool service behind one consistent contract while preserving the 2024 projection and supporting the initialized 2025 revisions and per-request 2026 revision. Define every tool once and keep behavior independent of transport metadata.

Phase 3 — Typed MCP tool outputs

Add compact structured results and accurate schemas for modern clients while retaining legacy text, ordering, identifiers, timestamps, scores, null/empty behavior, and error compatibility. Depends only on Phase 2.

Phase 4 — Active-project context resource

Expose one bounded, deterministic, exact-scope resource for active-project context without leaking unrelated projects, global preferences, embeddings, or internal paths. Depends only on Phase 2.

Phase 5 — Safe trusted-provider configuration

Add explicit opt-in, lossless, crash-safe trusted configuration for Codex, Claude Code, Cursor, OpenCode, and Zed. Never weaken stricter existing restrictions and track ICM-owned values. Standalone.

Phase 6 — Shared-daemon MCP transport and proxy

Add authenticated warm HTTP MCP access and a stdio proxy with independent sessions, safe retries, bounded responses, credential isolation, loopback restrictions, and preserved project scope. Depends only on Phase 2.

Post-phase integration

The local mcp-integration branch contains the reviewed convergence of Phases 2, 3, 4, and 6 plus shared transport-neutral memory operations and HTTP/MCP parity fixes. Those follow-up changes include:

• shared store/recall semantics for deduplication, auto-linking/backrefs, consolidation, filtering, graph expansion, and access refresh;
• HTTP Accept and modern protocol negotiation validation;
• explicit unsupported GET behavior for the request/response-only HTTP endpoint; and
• strict proxy notification acknowledgement handling.

This convergence is intentionally separate from the phase branches so each phase remains reviewable and mergeable.

Compatibility and security outcomes

The completed upgrade must preserve existing MCP behavior, provide revision-correct modern behavior, prevent malformed requests from selecting the wrong mode or affecting another connection, avoid exposing embeddings/secrets/unrelated memories, protect provider restrictions, and keep all evaluations isolated.

Completion criteria

The current phase review targets are the fork PRs below:

• Phase 1 fork PR #7 — isolated compatibility/evaluation suite — merged
• Phase 2 fork PR #8 — MCP protocol core and canonical tool service — merged
• Phase 3 fork PR #9 — typed tool outputs — merged after Phase 2
• Phase 4 fork PR #10 — active-project context resource — merged after Phase 2
• Phase 5 fork PR #11 — trusted provider lifecycle — merged independently
• Phase 6 fork PR #12 — shared HTTP proxy — merged after Phase 2
• Post-phase mcp-integration convergence reviewed and merged
• Existing compatibility and modern protocol/resource/provider/proxy behavior covered by isolated evaluation
• Repository remains buildable after each phase merge

[Lauritz-Timm]

@pszymkowiak could I get your opinion on this before I do more work on it?

I’ve implemented a clean-room MCP evaluation suite and run the full candidate evaluation across two isolated roots - one with spaces and one with Unicode. The candidate passed all 294/294 scenarios in both roots, with identical normalized results.

If this direction fits ICM, I’d like to integrate the evaluator into the main src tree so it exercises the actual MCP implementation rather than maintaining a parallel implementation under `cleanroom/eval. This should reduce duplication and keep the evaluation aligned with ICM’s current behavior.

The evaluator itself passed 44/44 checks. The baseline distribution was:

• 62 PASS
• 21 FAIL
• 211 UNSUPPORTED_BASELINE

I also ran a 300-iteration efficiency comparison with 20 warmup iterations.

The implementation preserved recall relevance, ordering parity, and required-field coverage at 100%, including Hit@3, Recall@3, and nDCG@3.

The estimated wire-token changes were:

• modern tools/list: -15.9%
• modern stats: -10.8%
• modern recall: -56.1% (1,411 → 619 tokens)
• modern feedback search: -36.7%
• modern transcript stats: -31.3%
• resources/list: -36.9%

I have provisional PRs open in my fork, but I’m still working through them to remove duplicate code, correct patterns, and tighten the phase boundaries.

The implementation was written using Codex. If you think this direction fits ICM, I’ll go through the implementation and rewrite or restructure anything needed to align it with the project’s patterns and expectations.

I’d appreciate your thoughts before I continue refining it.