MCP Gateway

​

What the MCP gateway does

• One endpoint, one key. Clients connect to https://your-gateway/mcp with a GoModel API key. They never hold upstream MCP credentials; the gateway injects each server’s headers itself.
• Aggregation with namespacing. Tools and prompts from every configured server appear in one catalog as {slug}_{name} (for example github_create_issue), in a stable, deterministic order.
• Least-privilege discovery. A server can be scoped to user_paths and carved out with disallowed_user_paths; hidden callers do not merely get errors — the tools never appear in their tools/list at all. Operator-level allowed_tools / disallowed_tools filters trim noisy servers, which keeps agent context small.
• Observability. Every tool call becomes a usage entry (server, tool, duration, sizes, error flag, labels, user path) and MCP requests appear in the audit log and request log like any other model traffic — labelled with the JSON-RPC method, and with the tool or prompt name for calls, so a tools/call row reads github_create_issue, not a bare path. With LOGGING_LOG_BODIES=true the JSON-RPC request and response frames are recorded on the audit entry as well (tool arguments and results included), subject to the same 1 MB capture cap as other endpoints. User-path rate limits and budgets gate MCP requests too.

​

Connect a client

{
  "mcpServers": {
    "gomodel": {
      "type": "http",
      "url": "https://your-gateway/mcp",
      "headers": {
        "Authorization": "Bearer sk-your-gomodel-key"
      }
    }
  }
}

• /mcp — everything the key’s user path may see, namespaced.
• /mcp/{slug} — a single server with its original tool names.
• X-MCP-Servers: github,jira header — a comma-separated subset on /mcp.

​

Search tools instead of listing them

• search_tools takes keywords (or an exact tool name) and returns the matching tools with their descriptions and input schemas.
• call_tool runs a found tool by name with its arguments.

mcp:
  tool_discovery: search # env: MCP_TOOL_DISCOVERY; default: off

{
  "mcpServers": {
    "gomodel": {
      "type": "http",
      "url": "https://your-gateway/mcp",
      "headers": {
        "Authorization": "Bearer sk-your-gomodel-key",
        "X-MCP-Tool-Discovery": "search"
      }
    }
  }
}

​

Declare servers

​

Add a server from the dashboard

• Name — human-facing; you can rename it later.
• Transport — http (streamable HTTP, default) or sse (legacy).
• URL — the upstream MCP endpoint.
• Headers — upstream credentials (for example Authorization: Bearer …); saved values are shown redacted afterward.
• Tools — check the tools clients may use; see Choose which tools each server exposes.
• Optional user paths and excluded user paths under Advanced; see Limit who can see a server.

• Name is human-facing, accepts Unicode, and can be edited later.
• Slug is derived from the name by default. It uses lowercase ASCII letters, numbers, hyphens, and underscores, and can be adjusted while creating the server. It becomes immutable after creation because it is used in /mcp/{slug}, X-MCP-Servers, and aggregated tool names.

mcp:
  enabled: true # default; MCP_ENABLED=false disables the endpoints
  servers:
    github:
      url: https://api.githubcopilot.com/mcp
      headers:
        Authorization: "Bearer ${GITHUB_PAT}"
      user_paths: ["/engineering"] # optional visibility scope
      disallowed_user_paths: ["/engineering/contractors"] # carve-out; wins over user_paths
      disallowed_tools: ["delete_repo"]
    local-files:
      transport: stdio # declarative-only; see security notes
      command: npx
      args: ["-y", "@modelcontextprotocol/server-filesystem", "/data"]

MCP_SERVERS='{"github":{"url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer ${GITHUB_PAT}"}}}'

​

Run stdio servers with Docker

services:
  mcp-files:
    image: supercorp/supergateway
    command:
      - --stdio
      - npx -y @modelcontextprotocol/server-filesystem /data
      - --outputTransport
      - streamableHttp
      - --port
      - "8000"
    volumes:
      - ./files:/data

  gomodel:
    image: enterpilot/gomodel
    ports: ["8080:8080"]
    environment:
      GOMODEL_MASTER_KEY: change-me
      MCP_SERVERS: '{"files":{"url":"http://mcp-files:8000/mcp"}}'
    depends_on: [mcp-files]

FROM node:22-slim
COPY --from=enterpilot/gomodel /gomodel /gomodel
COPY --from=enterpilot/gomodel /app /app
RUN chown -R node:node /app
USER node
WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["/gomodel"]

​

Health and lifecycle

​

Choose which tools each server exposes

mcp:
  servers:
    github:
      url: https://api.githubcopilot.com/mcp
      disallowed_tools: ["delete_repository", "merge_pull_request"]

​

Limit who can see a server

​

Inspect a server’s catalog

​

Security notes

• Credential boundary. The MCP spec forbids token passthrough; GoModel terminates the client’s bearer token and injects per-server credentials from configuration. Client keys never reach an upstream, and configured upstream headers are not sent across cross-origin redirects.
• Browser origins are denied by default. MCP clients are not web pages, so /mcp refuses any request carrying browser fetch metadata (Origin or Sec-Fetch-Site) unless it comes from an origin listed in mcp.allowed_origins (MCP_ALLOWED_ORIGINS). Write entries as a browser serializes them — https://console.example.com, no trailing slash, default ports optional. An allowlisted origin gets a whole session, including the GET notification stream, which browsers send without an Origin header. This is what blocks browser-based DNS rebinding: rebinding changes only which address a hostname resolves to, so a rebound page’s Origin and Host still agree with each other and the browser still reports Sec-Fetch-Site: same-origin — comparing them proves nothing, and only an explicit allowlist tells your origin apart from an attacker’s. Set allowed_origins only if you serve an MCP web client from a known origin; "*" trusts every origin, disables the defense, and is warned about at startup.
• stdio is declarative-only. stdio servers spawn subprocesses on the gateway host, so they can only be declared in config.yaml / MCP_SERVERS. The admin API and dashboard reject them — a dashboard login must never be equivalent to code execution on the gateway.
• stdio subprocesses get a minimal environment. Only PATH, HOME, TMPDIR, USER, and LANG are inherited — never the gateway’s provider API keys or master key. Pass anything else explicitly via the server’s env: map (values support ${VAR}).
• Dashboard-managed credentials live in the gateway database. Headers of admin-created servers are stored in the configured storage backend (they are only redacted at the API/UI layer). If your threat model excludes secrets in the database, declare those servers in config.yaml / MCP_SERVERS instead — ${ENV} references keep the secret in the environment, and declarative servers never touch the store.
• Remote URLs are server-side egress. Dashboard-managed HTTP/SSE servers deliberately support private and loopback endpoints. Protect admin write access and enforce your deployment’s egress policy so untrusted operators cannot use the gateway to probe internal services.
• Sessions are not authentication. Every request is bearer-authenticated, and a session is additionally bound to the managed auth-key identity, user path, and pinned endpoint that initialized it; presenting a leaked session ID under another identity returns 404.
• Secret header values are shown redacted (***) in the admin API and dashboard; saving a form with *** preserves the stored secret.

​

Protocol coverage