How It Works
Your MCP client sees Ultra as one server. Behind the scenes, Ultra connects to multiple upstream servers and merges their capabilities:Tool Namespacing
To avoid name conflicts when multiple servers provide similarly-named tools, the aggregator prefixes tool names with the upstream server name:filesystem server with a read tool and a github server with a read tool, they become:
filesystem__readgithub__read
Routing
When a tool call comes in, the aggregator:- Parses the namespaced tool name to identify the upstream server
- Routes the request through the pipeline for observability
- Forwards the call to the correct upstream server
- Returns the response back through the pipeline to the client
Connection Management
The aggregator handles the lifecycle of upstream connections:Stdio Servers
For command-based servers, the aggregator:- Spawns the process with configured command, args, and env vars
- Communicates over stdin/stdout
- Handles process lifecycle (start, restart, cleanup)
HTTP Servers
For URL-based servers, the aggregator:- Establishes HTTP/SSE connections, automatically detecting the correct transport type (SSE vs. Streamable HTTP)
- Manages connection health
- Handles authentication (including OAuth2 flows)
Server Probing and MCP Normalization
MCP servers are notoriously inconsistent. Some require--stdio flags, others need subcommands like server or serve, and many output help text instead of speaking the MCP protocol by default. Ultra handles all of this automatically so you don’t need a separate debugger tool.
Stdio Server Probing
When Ultra connects to a stdio server, it performs an MCP protocol handshake to verify the server responds with valid JSON-RPC. If the handshake fails because the server outputs non-JSON (help text, usage info, or error messages), Ultra automatically tries common argument patterns concurrently:--stdioserverserveserver --stdioserver --mcp-onlystart --stdio--mcp
ultra add so servers are validated before they’re added to your configuration.
HTTP Server Probing
For HTTP-based servers, Ultra probes the connection and detects authentication requirements:| Server Response | What Ultra Does |
|---|---|
| 200 / 204 | Connects directly, no auth needed |
| 401 | Checks for OAuth support (RFC 8414) and initiates the appropriate auth flow |
| 403 | Prompts for a bearer token or API key |
Auto-Reconnection
Connections drop. Servers restart. Networks hiccup. Ultra detects stale connections (EOF, broken pipe, connection reset) and transparently reconnects without interrupting your workflow. Each upstream server reconnects independently, so one flaky server doesn’t block the others.Actionable Error Messages
When a server can’t be connected or auto-fixed, Ultra provides context-specific guidance rather than a generic error:- Auth errors: Tells you whether the server needs OAuth or a token, with setup instructions
- Protocol errors: Suggests the server may need a specific flag, with a link to your config file
- Network errors: Distinguishes between “server unreachable” and “server timed out” with appropriate next steps
OAuth2 Support
The aggregator supports OAuth2 authentication for upstream servers that require it. When a server responds with a 401, Ultra can:- Initiate an OAuth2 PKCE flow
- Open a browser for user authorization
- Store and refresh tokens automatically
Built-in Tools
Ultra registers one built-in tool:| Tool | Description |
|---|---|
ultra_status | Returns Ultra’s health status, version, upstream count, and aggregated tool count |
Startup Flow
Whenultra start runs:
- Load configuration and validate upstream entries
- Initialize storage and observability
- Create the pipeline with interceptors
- Start the aggregator — connect to all enabled upstream servers
- Discover capabilities — list tools, resources, and prompts from each upstream
- Register aggregated capabilities — namespaced tools/resources/prompts on the MCP server
- Start the MCP server on stdio transport
- (Optional) Start Hub background sync