server

Overview ¶

bearerguard.go authenticates OAuth-mode requests before the SDK's bearer middleware runs.

The SDK's auth.RequireBearerToken is kept in the chain — it is the only thing that can populate the token info the streamable handler reads, since its context key is unexported — but it is not enough on its own. It relays every attempt straight upstream, it answers in plain text rather than the JSON-RPC shape the rest of this endpoint uses, and its challenge carries neither the RFC 6750 error code a client needs to tell "re-authenticate" apart from "ask for more scope", nor any way to say "this was not about your token at all".

The guard runs first and answers those cases itself. A request it lets through reaches the SDK middleware, whose own verification is a hit on the cache this guard just populated, so the upstream cost is one call either way.

envoverlay.go applies environment variables underneath the HTTP-mode flags.

HTTP mode built its configuration purely from flags, so every documented HTTP environment variable was inert: the flag default won even when the operator had exported a value and passed no flag. Precedence is now the one the reference documents — an explicitly passed flag, then the environment, then the built-in default.

The request surface is unchanged and stays narrow: only the GitLab token and, when --gitlab-url was omitted, the GITLAB-URL header are client-controlled. Nothing here is reachable per request, so a client cannot influence any of it for itself or for anyone else.

instructions.go builds the MCP handshake instructions, the text every client injects into its model's system prompt. Because the same operation is named differently on each tool surface, the guidance is assembled per surface rather than written once: a single hardcoded text would name individual-mode tools to a dynamic-mode model that cannot see any of them.

Command server is the MCP server entry point for gitlab-mcp-server. In stdio mode, configuration comes from environment variables (.env / exports). In HTTP mode, configuration comes from CLI flags; no GITLAB_TOKEN is required at startup — each client provides its own token per-request. The --shutdown flag terminates running instances before external updaters replace the binary on disk.

Modes ¶

Stdio mode creates one MCP server from environment configuration and serves JSON-RPC over standard input and output. HTTP mode creates a streamable HTTP handler backed by a server pool so each token and GitLab URL pair receives an isolated MCP server configuration.

Startup Flow ¶

The command validates configuration, registers tools, resources, prompts, completions, progress, and elicitation support, then starts the selected transport:

server
    |
    v
configuration and auto-update setup
    |
    v
MCP capability registration
    |
    v
stdio or HTTP transport