Skip to main content
Uplink exposes an MCP server running on any machine as a regular Smithery connection. The CLI holds a secure tunnel open and forwards every request from Smithery to the local process, so agents and apps reach it through the same REST surface as any hosted server. Uplink is useful when:
  • You’re developing an MCP server and want to test it against a real agent before publishing.
  • The server needs something only a specific machine can reach — a browser, a local database, an SSH key, a code editor.
  • You want to run a private tool for yourself or your team without hosting it.

Quick Start

Uplink uses smithery mcp add. If the URL resolves to localhost (or 127.0.0.1), or you pass a command in place of a URL, the CLI opens an uplink tunnel in the background and registers the connection against your namespace.
# Point at an MCP server already running locally
smithery mcp add http://localhost:9090/mcp --id chrome
The CLI stays running and prints live status:
Uplink connected → my-app/chrome (status: connected)
While the CLI is running, my-app/chrome behaves like any other Smithery connection.

Call it like any other connection

Reach the uplinked server through the standard Smithery surface — no special transport handling required:
smithery tool list chrome
smithery tool call chrome navigate '{"url": "https://smithery.ai"}'

How it works

When smithery mcp add sees a localhost URL or a trailing command, it:
  1. Registers a connection on your namespace marked as uplink-backed.
  2. Opens a persistent WebSocket to Smithery scoped to that connection.
  3. Connects to your local HTTP server, or spawns the command as a subprocess, and bridges JSON-RPC between the WebSocket and the local process.
Incoming requests flow over the WebSocket to your local MCP server and back. The tunnel is transparent to the MCP spec: stateful sessions, progress notifications, server-initiated messages (sampling, elicitation, roots), and streamed responses all pass through. Auth, permissions, service tokens, and session handling are identical to hosted connections — uplink is a transport detail underneath the existing surface.

Connection lifecycle

An uplink connection reports one of:
StatusDescription
connectedTunnel is live; requests are being forwarded
disconnectedNo CLI is attached (never paired, exited, or lost its WebSocket). Cached tool lists are dropped
errorThe tunnel or the local process errored
When the CLI exits, the connection stays in the namespace but its serverInfo is cleared, so callers don’t see a stale tool list. Re-running smithery mcp add with the same --id reattaches the tunnel.

One tunnel per connection

Each connection can carry only one live tunnel at a time. Running smithery mcp add for the same --id from a second machine fails with a conflict. Pass --force to take over:
smithery mcp add http://localhost:9090/mcp --id chrome --force
Use --force deliberately — the previous CLI is disconnected immediately, and any requests it was mid-handling fail.

Security

  • Traffic is end-to-end TLS from Smithery to the CLI. The local MCP server speaks plain stdio or loopback HTTP to the CLI as it normally would.
  • Uplink forwards arbitrary traffic to a process on the host machine. Only uplink servers you trust, and treat any trailing command as you would any other local executable.

Limitations

  • One tunnel per connection. See above.
  • Availability follows the host. If the CLI is offline, the connection reports disconnected and calls fail fast. Uplink is a development and personal-automation primitive, not a hosting solution — publish your server to Smithery when you’re ready for production.
  • Latency includes your network. Every request makes a round trip to the host machine.