Skgate

What the skgate MCP server does

The skgate MCP server provides a single self-hosted gateway for MCP servers and LLM provider APIs. MCP upstreams can be remote services, REST APIs, GitHub repositories, npm packages, or PyPI packages. Managed sources run inside the gateway image using bundled tools such as Node.js, pnpm, Bun, Deno, Python, Go, .NET, and git in the latest image.

MCP clients can connect to one upstream at /mcp/<alias> or to an aggregate endpoint at /mcp. The aggregate includes upstreams marked for inclusion, subject to their lifecycle settings. The site root can also serve the aggregate for MCP requests while directing normal browser requests to the administration interface.

The gateway exposes an OpenAI-compatible API for configured providers. Supported provider examples include OpenAI, Anthropic, Gemini, Grok, Mistral, DeepSeek, Groq, OpenRouter, Ollama, LM Studio, and other compatible endpoints. Grok can use subscription sign-in instead of an API key. User-created aliases let applications send a stable model name while the administrator changes its target.

How it works

The skgate MCP server uses OIDC for administrator authentication and OAuth 2.1 for access to exposed MCP endpoints. Scripts and command-line clients can authenticate with keys created in the admin interface. Hosted connectors can use OAuth by leaving the client ID and secret empty where supported.

Managed MCP processes default to on-demand operation. A process starts when its individual endpoint receives a request and stops after ten minutes without requests. The first request after shutdown waits for startup. Administrators can choose an always-on lifecycle, and an imported configuration can set a different idle timeout. On-demand upstreams are not included in the aggregate endpoint, so clients must use their individual aliases.

For model access, applications use the gateway's /v1 base URL and a generated sk-... key. /api, /api/v1, and the bare host provide equivalent API base URL forms. Model aliases appear first in /v1/models and are translated to their configured target before the request reaches a provider.

Setup and configuration

A Docker deployment needs a persistent /data volume and an externally reachable PUBLIC_URL. The standard configuration also sets OIDC_ISSUER, OIDC_CLIENT_ID, and OIDC_CLIENT_SECRET for a confidential OIDC client. Start the container with Docker Compose, open /admin, and sign in through the identity provider.

After setup, add MCP upstreams from the administration interface. A managed process can be configured manually or imported from JSON. The Suggest configuration feature can inspect a source README and common manifests, then propose the command, arguments, installation step, and environment variables; the proposed values are not saved until reviewed and submitted. It requires the latest image and an available MCP helper model.

The slim image contains the proxy only. Use latest when the gateway must run managed MCP servers.

Tools and capabilities

The skgate MCP server supports:

• OAuth 2.1 protection for MCP endpoints
• OIDC-based administrator login
• Remote, OpenAPI, and managed MCP upstreams
• Package and Git repository based MCP process management
• Individual and aggregate MCP URLs
• On-demand and always-on process lifecycles
• OpenAI-compatible chat and model endpoints
• Virtual API keys and user-defined model aliases
• Provider configuration for subscription or API-key access

Limitations and notes

The administrator login requires an OIDC provider unless the bundled quickstart is used. The latest image is required for managed MCP servers and configuration suggestions; slim is proxy-only. On-demand startup adds wait time to the first request after a process has stopped. Empty environment values are not passed to managed servers, so required upstream settings must be supplied before saving the configuration.