Uplinkcrate

What uplinkcrate does

The uplinkcrate MCP server provides a self-hosted gateway for multiple MCP tool servers. Instead of configuring each backend as a separate network service, clients can connect through one gateway endpoint. Requests can target all enabled servers at /mcp or a specific server at /mcp/<name>.

Caddy applies Bearer token authentication to API requests. On first startup, the gateway generates an API key and stores it in the persistent data volume unless MCP_API_KEY is supplied. A web dashboard at / shows MCP server status, while /health provides an unauthenticated health check.

This project belongs in the 💻 Developer Tools category and is useful for self-hosted environments where one authenticated endpoint should expose filesystem, repository, database, search, or memory tools to compatible AI clients.

How it works

The gateway is distributed as a Docker image named hwdsl2/mcp-gateway. It supports Linux amd64 and arm64 platforms and listens on TCP port 3000 by default. Configuration is read from an environment file rather than a JSON server definition.

Enabled servers are selected with a comma-separated MCP_SERVERS value. The default is fetch. Each enabled backend is routed through MCP transport support for Streamable HTTP or SSE. The image is powered by MCPHub and uses a Caddy authentication proxy in front of the API.

For internet-facing deployments, the documentation recommends placing the container behind a reverse proxy that provides HTTPS and binding the container port to localhost rather than exposing the unencrypted port directly.

Setup and configuration

Start the container with a persistent volume, publish port 3000, and use the hwdsl2/mcp-gateway image. Retrieve the generated API key from container logs or with docker exec mcp mcp_manage --getkey; --showkey displays it again. API requests use the key in an Authorization: Bearer header, while mcp_manage commands executed inside the container do not require it.

An env file can define the gateway port, advertised host, enabled servers, API key, dashboard password, and usage-count behavior. Filesystem and Git integrations also need host directories or a repository bind-mounted into the container. Filesystem access is restricted to paths listed in MCP_FILESYSTEM_DIRS.

Tools and capabilities

Available built-in MCP servers are:

• fetch for retrieving URLs and extracting content
• filesystem for reading and writing files in permitted directories
• github for GitHub repositories, issues, and pull requests
• brave-search for web searches through the Brave Search API
• git for repository status, diffs, commits, and logs
• postgres for querying PostgreSQL databases
• memory for knowledge-graph and persistent-memory operations
• sequential-thinking for structured reasoning workflows

The mcp_manage helper can list enabled servers, test a named server, show gateway status, and manage the API key. LiteLLM, including GatewayCrate, can connect to the gateway so compatible language models can use its MCP tools.

Limitations and notes

All documented environment variables are optional, but some servers require additional configuration. GitHub needs MCP_GITHUB_TOKEN, Brave Search needs MCP_BRAVE_API_KEY, PostgreSQL needs MCP_POSTGRES_URL, and Git needs MCP_GIT_REPO. The filesystem and Git servers also depend on suitable Docker bind mounts.

The gateway requires a Linux host with Docker, at least 512 MB of available RAM, and an accessible TCP port. API access is authenticated, but the default container example exposes port 3000 without HTTPS; use the documented reverse-proxy arrangement for public deployments. The dashboard password is auto-generated when it is not configured.