MCP connection manager: persistent server lifecycle and connection pooling

[chubes4]

Summary

Data Machine should manage MCP server lifecycle so plugins don't spawn fresh servers per request. Start the server once, keep it running, provide a connection pool that any plugin can use.

Problem

Intelligence spawns a new npx @automattic/mcp-context-a8c process for every connect() call via proc_open. Each spawn takes ~90s (npx startup + MCP handshake through AutoProxxy). Old servers are left orphaned. This makes the CLI unusable.

Connection caching within a single PHP process helps (chubes4/intelligence@eac5fc5), but each studio wp invocation is a separate PHP process that pays the full 90s startup.

Proposed Solution

A DM-managed MCP connection layer:

1. Server lifecycle — Start MCP servers on first use, keep running as background processes. Track PID + connection state. Restart on crash.
2. Connection pool — Plugins register MCP server configs. DM manages connections. $client = datamachine_mcp_connect('context-a8c') returns a ready-to-use client.
3. Transport upgrade — When MCP servers support HTTP/SSE transport, DM can connect via cURL instead of proc_open, eliminating WASM spawn complexity entirely.

Why Data Machine

This is a platform concern, not Intelligence-specific:

• Any plugin using MCP servers needs the same lifecycle management
• DM already manages auth providers, jobs, agents — MCP connections fit naturally
• The OAuth callback filter hook (Add filter hook for OAuth callback URL in BaseAuthProvider #1041) is related — auth + connections are tightly coupled

Related

• chubes4/intelligence#19 — Intelligence-side tracking
• chubes4/intelligence#17 — Full investigation trail
• Add nativeSpawn option to RunCLIArgs for host process spawning WordPress/wordpress-playground#3481 — proc_open native spawn PR
• run() then cli() crashes with WASM function table corruption in asyncify mode WordPress/wordpress-playground#3482 — WASM glue VFS cwd fix