Support SSE and HTTP transports in Neo.ai.mcp.client.Client

Context

While evaluating the integration test architecture for the MCP stack, it was noted that our internal wrapper (Neo.ai.mcp.client.Client) currently hardcodes the StdioClientTransport. This couples the client strictly to local process spawning, preventing it from connecting to already-running MCP servers over HTTP/SSE.

The Problem

Neo.ai.mcp.client.Client is currently optimized for the "Application Client" role (spawning local servers via command and args in config.mjs). It lacks the flexibility to act as an "External Network Client", which forces integration tests to bypass the wrapper and use the raw @modelcontextprotocol/sdk to test HTTP endpoints (e.g., StreamableHTTPClientTransport).

The Architectural Reality

In ai/mcp/client/Client.mjs -> initAsync(), the transport property is hardcoded to a new StdioClientTransport. It relies exclusively on the presence of me.command and me.args loaded from ClientConfig.

The Fix

Extend Neo.ai.mcp.client.Client and ai/mcp/client/config.mjs to abstract the transport layer configuration. It should cleanly support SSEClientTransport or StreamableHTTPClientTransport when connecting to a remote or containerized server endpoint.

Contract Ledger Matrix

Acceptance Criteria

• Neo.ai.mcp.client.Client supports configuring and utilizing SSEClientTransport / StreamableHTTPClientTransport.
• ai/mcp/client/config.mjs schema is extended to support configuring transport types and endpoint URLs.
• Existing local Stdio server connections remain unbroken (backward compatibility).

Out of Scope

• Rewriting all existing integration tests to use the wrapper immediately (this ticket is for capability support only; adoption can be phased).

Origin Session ID

Origin Session ID: 0318c07d-eb0c-4ef9-9c7a-896dc52e9a14

Retrieval Hint: SSEClientTransport support Neo.ai.mcp.client.Client integration tests