RFC: vMCP Core Interface — Splitting Domain Logic from Transport

[tgrunnagle]

Summary

Proposes extracting a small, identity-parameterized VMCP domain interface from the Virtual MCP Server, paired with New(cfg) -> VMCP to construct the core and Serve(ctx, VMCP, serverCfg) -> *Server to stand up the transport. Embedders can wrap the core with their own decorators to augment behavior — without reimplementing aggregation/routing/composition, and without coupling to the mcp-go SDK lifecycle, the HTTP middleware chain, or request-context contracts. The existing server.New(...) entry point is preserved as a thin wrapper over Serve(ctx, New(cfg), serverCfg), so current embedders are unaffected.

Key points

• Minimal VMCP interface exposing the MCP capability surface (list/call tools, list/read resources, list/get prompts, lookup) with identity as an explicit parameter — removing the auth.IdentityFromContext coupling on the domain path.
• New relocates (not rewrites) the collaborator wiring server.New does today; Serve owns all transport concerns (mcp-go, middleware chain, embedded AS, status, telemetry, health).
• Decoration is the supported domain-extension mechanism; list and call share one source of truth so a decorator cannot drift or widen access.
• No change to serialized config, CRD/YAML, data model, or incoming/outgoing auth strategies. server.New signature stays stable throughout; the split lands behind it across small, sequenced PRs.

🤖 Generated with Claude Code

[jerm-dro]

Looks good! Let 'er rip!