feat(unstable): make MCP-over-ACP request-scoped

[benbrandt]

Draft: MCP 2026-07-28 only

Replace the connection-oriented MCP-over-ACP proposal with the request-scoped design exercised by the Rust SDK. No legacy MCP compatibility mode is planned. Supersedes the design/audit checkpoint in #2222.

Companion implementation: agentclientprotocol/rust-sdk#376

Wire contract

• Server-addressed MCP requests carry a stable logical request ID, method, and per-request parameters/metadata.
• Requests go agent-to-provider; provider-to-agent notifications belong to an active request. Remove connect/disconnect, MCP connection IDs, and reverse request variants.
• Outer ACP IDs remain hop-local; cancellation uses ACP's existing best-effort mechanism without introducing a stronger support requirement.
• Successful ACP responses carry exactly one inner MCP result or error. Preserve opaque results, explicit null data, and error extensions without assigning ACP meaning to MCP error codes.
• ACP v1 and v2 define independent response/error carrier types, following the repository versioning convention. Separating these Rust types does not change their generated wire schemas; only unstable schemas differ from main.

RFD

The proposal now distinguishes reusable application services from individual owned operations, defines registration identity/lifetime and error domains, and makes cleanup and resource admission explicit. The logical ID remains admitted until owned cleanup finishes. It preserves modern discovery, MRTR, and subscription semantics without an MCP handshake.

The HTTP section describes a new local endpoint re-exporting native tools: one authenticated connection listener, no hidden descriptor lookups, and schema-aware removal of HTTP-only parameter-header annotations. It does not claim to preserve another gateway's authorization policy.

The reference implementation includes a deterministic cleanup regression for both mutable and concurrent tools: pause the runner while ACP continues dispatching, prove cancellation cannot settle or release its logical ID, then allow cleanup and reuse the ID. Real rmcp tests cover native and HTTP workflows; transport tests cover bounded queues, retained replies, cancellation, and EOF draining.

Latest review follow-ups

• Keep the v1 and v2 outcome/error definitions independent so they can evolve separately. This refactor leaves their generated wire schemas unchanged.
• Keep one outer mcp/message name. JSON-RPC message kind and direction distinguish requests from notifications; the inner MCP method remains unchanged. The companion SDK now has three regression tests for outer-ID discrimination, separate v1/v2 method enums, and rejection of malformed request IDs without notification fallback.
• Cancellation reuses ACP's existing mechanism with best-effort semantics. The RFD no longer makes stronger cancellation support a condition of advertising this transport; providers may finish normally if cancellation is unavailable or completion wins the race.
• The latest follow-up passed protocol npm run check, the targeted SDK deserialization tests, and strict workspace Clippy.

Validation

• Schema generation passed; stable JSON schemas remain unchanged. The generator also corrects the documentation rendering of unconstrained JSON values.
• npm run check passed: schema/generator tests, doctests, Clippy, formatting, and spellcheck.
• All eight RFD JSON examples parse.
• Companion SDK passes its full test suite, strict Clippy, MSRV 1.88 checks, and targeted real-rmcp workflows.

Release gates

This remains an unstable protocol draft, not certification of every optional MCP/HTTP feature. The Rust SDK's cancellation and joined-cleanup safeguards are implementation behavior, not an additional requirement for advertising the transport. The SDK currently pins schema revision e5c36d2671fd355f983533bc83b5feb7981d25a6; release the matching schema and coordinate dependent SDK major versions before replacing that pin and publishing packages. No packages were published.