Skip to main content

Overview

UMCP acts as a transport bridge, allowing you to connect to MCP providers that use different transport protocols and expose them all through a single unified interface. This means downstream clients only need to connect to UMCP using one transport type, while UMCP handles the complexity of connecting to providers via their native transports.

Supported Transports

UMCP supports three MCP transport protocols:
  1. stdio - Standard input/output (process-based)
  2. sse - Server-Sent Events (HTTP-based)
  3. streamable-http - Streamable HTTP (modern HTTP-based)
From config.ts:11:

How Transport Bridging Works

Upstream Connections

Each provider in your configuration specifies its transport type. UMCP creates the appropriate client connection based on the transport field:

Downstream Interface

UMCP exposes a single downstream interface that clients connect to. You choose the downstream transport when starting UMCP:

Transport-Specific Configuration

stdio Transport

For stdio providers, you must specify a command and optionally args. From config.ts:46-52:
Example configuration:

HTTP Transports (sse & streamable-http)

For HTTP-based transports, you must specify a url. From config.ts:54-61:
Example configuration:

Downstream Server Implementation

UMCP’s serve.ts module handles both stdio and HTTP downstream connections.

stdio Server

The stdio server uses StdioServerTransport from the MCP SDK. From serve.ts:109-114:

HTTP Server

The HTTP server uses StreamableHTTPServerTransport and handles multiple HTTP methods. From serve.ts:116-177:

Server Setup Flow

The main runServe function orchestrates the entire server setup. From serve.ts:179-209:
Key steps:
  1. Load configuration
  2. Create environment pool (for round-robin rotation)
  3. Create provider manager (handles upstream connections)
  4. Create MCP server
  5. Discover and register tools
  6. Start appropriate transport (stdio or HTTP)

HTTP Request Handling

The HTTP server supports GET, POST, and DELETE methods, matching the MCP protocol requirements:
  • GET: Typically used for session management
  • POST: Used for tool calls and other operations
  • DELETE: Used for session cleanup
From serve.ts:138-149:

Request Body Parsing

For POST requests, UMCP reads and parses JSON bodies with size limits. From serve.ts:30-51:

Path Normalization

HTTP endpoint paths are automatically normalized to start with a forward slash. From serve.ts:26-28:

Use Cases

Local Development

Connect to local stdio tools and expose them via HTTP:
Now local AI clients can connect to http://localhost:3000/mcp instead of managing multiple stdio processes.

Centralized Gateway

Create a single HTTP endpoint that aggregates tools from multiple sources:
  • Local stdio tools (file system, shell commands)
  • Remote HTTP services (cloud APIs)
  • Legacy SSE providers

Cloud Deployment

Deploy UMCP as an HTTP service that bridges to stdio tools running in containers:
Start UMCP with:

Best Practices

  1. Choose the right downstream transport: Use stdio for local development and HTTP for networked access
  2. Secure HTTP deployments: Use reverse proxies (nginx, Caddy) to add TLS and authentication
  3. Monitor provider health: Watch logs for upstream connection failures
  4. Set appropriate timeouts: Consider network latency when connecting to remote HTTP providers

Graceful Shutdown

UMCP handles shutdown signals to cleanly close all connections. From serve.ts:53-81:
Signals handled:
  • SIGINT: Ctrl+C in terminal
  • SIGTERM: Standard termination signal
  • stdin close: When stdin pipe closes (stdio mode only)