Big Bull (@BIGBULLapp) on X

What it claims

A post from the X account Big Bull (@BIGBULLapp) describes a GitLab MCP server written in Go. The server exposes two tools, find and execute, in front of 850+ GitLab actions, or 1,000+ on GitLab Enterprise. The author contrasts this with other GitLab MCP servers they have seen, which expose the whole API surface as tools and rely on the model to pick the right endpoint. The stated reason for the design is context cost: a two-tool list stays small enough to remain in context.

How it works

The assistant calls find to search for the GitLab action it wants, then calls execute to run it.

flowchart LR
  A[Assistant request] --> F[find: search actions]
  F -->|correct match| E[execute action]
  F -->|wrong match| W[plausible wrong action]
  W --> E
  E --> M{Mode}
  M -->|read-only| R[reads only]
  M -->|write enabled| X[writes and deletes possible]

How to use it

The repository is on GitHub under the account jmrplens. The post truncates the link to github.com/jmrplens/gitla…, so the full repository name has to be confirmed on GitHub. The server ships as a single Go binary, with no Python environment to maintain. It supports stdio and HTTP transports, and HTTP uses OAuth. A read-only mode connects an assistant to a GitLab instance without delete access. The author calls this the setup most teams want first.

Limits

The design depends on the find step. When find returns the wrong action, the result is a plausible-looking action that does the wrong thing. The author advises testing find rather than execute. Read-only mode limits the damage only while it is on. Once write access is enabled, a wrong find result can run a destructive action, and the post describes no safeguard for that case. The post gives no accuracy figures for find, no licence, no install command and no list of supported GitLab versions.