Module gateway 

Thin, product-neutral projections onto soma-gateway, the canonical upstream-MCP connection/routing engine (plan section “Upstream MCP decision”).

Two independent pieces live here:

• UpstreamMcpProvider: a per-manifest ad-hoc “connect to one upstream MCP server and proxy a tool call” provider, migrated from the soma-service mcp provider kind that predated soma-gateway.
• project_gateway_action_catalog: a pure function that projects soma-gateway’s own admin action catalog (soma_gateway::gateway::catalog::GatewayActionCatalog) into a soma_provider_core::ProviderCatalog, so a host can expose gateway administration as a drop-in-shaped provider surface.

Deviation: transport is not yet pooled through soma-mcp-client

UpstreamMcpProvider still opens its own per-call rmcp session with the raw TokioChildProcess / StreamableHttpClientTransport transports rather than routing through soma-mcp-client’s pooled UpstreamPool. That would be the fuller reconciliation the plan calls for (acceptance: “no second upstream MCP transport stack”), but it is a genuinely cross-cutting change, not a mechanical swap:

• UpstreamPool/UpstreamConfig (crates/shared/mcp/client/src/config.rs) currently support only a single bearer_token_env for HTTP auth, while this provider’s manifest contract (provider.meta.mcp.http.headers) supports arbitrary, ${VAR}-interpolated custom headers with no test coverage proving that capability is unused. Narrowing it silently to single-bearer-token auth risks a real, undetectable behavior regression.
• UpstreamConfig::validate() runs SpawnGuard command validation and a restricted name character set that this provider’s manifest-driven stdio commands have never been checked against; migrating without reconciling those rules risks rejecting previously-working manifests.
• UpstreamConfig has no per-upstream timeout field equivalent to provider.meta.mcp.timeout_ms.
• UpstreamPool is a registered, stateful pool (register_config then ensure_connected/call_tool); this provider is stateless per ProviderCall today and has no “register once” phase to hook into.

Tracked as its own scoped follow-up: bead rmcp-template-fnz0. This adapter is still a real improvement over the pre-PR10 state: it is physically consolidated into the shared, product-neutral adapters crate (no soma-service dependency), and it is the only upstream-MCP transport implementation outside soma-mcp-client/soma-gateway in the workspace.

Structs

UpstreamMcpProvider

Functions

project_gateway_action_catalog

Projects soma-gateway’s own admin action catalog into a soma_provider_core::ProviderCatalog, so a host can advertise gateway administration (list/add/remove/reload upstreams, OAuth lifecycle, …) through the same drop-in-provider-shaped surface as every other adapter in this crate.