server

Overview ¶

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