Think inside your AI world.

GitLab through Unl

GitLab's MCP server will show you exactly which job in a pipeline failed and why, log line and all. Whether an allow-failure override on that job should still let a merge through is a call your own rule makes.

GitLab through Unl reads a merge request's latest pipeline and job outcomes against the merge-safety rule you have ratified, so 'did this pipeline actually pass clean?' comes back held with the condition it hasn't met.

What GitLab holds

Ask GitLab's MCP server about a merge request or pipeline and it retrieves:

  • detailed information about a specific issue or merge request
  • commits, diffs, and notes attached to a merge request
  • pipelines triggered by a merge request, and the jobs within them
  • the trace log output for a specific CI/CD job
  • search across issues, labels, and code in the instance

What the naked read gives you

GitLab's MCP server retrieves a merge request's details, its commits and diffs, the pipelines it triggered, and the jobs and logs inside those pipelines. It can also search issues, labels, and code across an entire instance. It reports precisely which jobs ran, passed, failed, or were skipped, without weighing in on whether that outcome is one that should let a merge request through.

The frame judges the data it is given; it does not verify the source’s accuracy.

What changes when GitLab is read measured

A release manager at a fintech engineering team ratified a merge-safety rule in Unl: no merge request reaches main unless its latest pipeline shows every job passed with no security-scan job marked allow_failure, because a merge once went through on a pipeline where the SAST job had silently failed under an allow-failure override.

'Did this pipeline actually pass clean?' returns, measured: not yet - the pipeline read shows the security-scan job failed and is flagged allow_failure, letting the overall pipeline show green regardless. GitLab supplied the job outcome; your ratified rule supplied the merge-safety bar.

And back again

Fixing the security-scan job itself - not silently marking it allow_failure - is what changes this. The next pipeline read comes back green for the right reason, and GitLab through Unl folds that straight into the existing page.

The answer comes back measured against what you already decided, and why.

The lane is live and open to this tool today: one box, paste anything. If it speaks MCP, Unl can reach it. Readings arrive unprompted, the data beside the criterion; Unl is a courier, not a warehouse, and keeps only your keys and the frame.

Questions people ask

What would clear this merge request?

The security-scan job passing on its own merit, with the allow_failure override removed. The same ratified rule reads the clean job outcome and clears the merge.

How do I connect GitLab to Claude?

Enable the GitLab MCP server on your instance and connect over HTTP transport directly, or use stdio with mcp-remote as a proxy, authenticating via OAuth 2.0 Dynamic Client Registration - Unl's reads run through that same connection.

Does Unl write to my repository?

No. Unl calls GitLab's get_merge_request, get_pipeline_jobs, get_job_log, and search tools to see current state; it merges nothing and reruns no pipeline. Any fix, you push yourself.

What this is

Think inside your AI world — you stay in command

Unlimitless (Unl to friends) holds what you've settled, reads what your tools are showing, and catches what's changed out in the world — and hands your AI whatever bears on the work, the moment it's needed, without you asking. The right thing, in front of the model, unprompted, with you in command of the call. So you keep moving toward what you set out to build, on top of everything you've already decided.

It plugs into Claude, Claude Code, ChatGPT and Cursor as an MCP connector. Quick to connect, in a couple of steps.

Unlimitless is open now to invited Alpha. Apply for the Beta waitlist to come in ahead of the full launch:

Alpha is invite-only · free at launch.