| FMRS | 60 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 9 / 20 | 12 / 20 |
|---|
| Security and permissions | 11 / 20 | 18 / 20 |
|---|
| Maintenance | 11 / 20 | 16 / 20 |
|---|
| Documentation | 16 / 20 | 18 / 20 |
|---|
| Setup experience | 13 / 20 | 15 / 20 |
|---|
| Best for | - Teams that want AI clients to operate GitLab project-management and collaboration workflows.
- Users working with GitLab.com and self-managed GitLab instances.
- Deployments needing read-only mode, toolsets, individual tool filters, or deny patterns.
- Developers needing local stdio or remote HTTP MCP access.
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Projects that do not use GitLab or need GitLab API operations.
- Static code-reading scenarios where GitLab credentials should not be granted.
- Deployments that require REMOTE_AUTHORIZATION together with SSE.
- Environments unable to securely manage personal, OAuth, cookie, or remote authorization credentials.
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - GITLAB_PERSONAL_ACCESS_TOKEN is required unless another supported authentication method is used.
- The token should have scopes required by the selected tools, such as api or read_api.
- Write, delete, pipeline, and project-management tools require corresponding GitLab permissions.
- GITLAB_READ_ONLY_MODE can expose only read-only tools.
- Access can be constrained with GITLAB_ALLOWED_PROJECT_IDS, GITLAB_TOOLSETS, GITLAB_TOOLS, and GITLAB_DENIED_TOOLS_REGEX.
- Wiki tools require USE_GITLAB_WIKI or the relevant toolset to be enabled.
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - Tokens with the api scope or write tools may permit creating, changing, merging, or deleting GitLab resources.
- Personal access tokens, job tokens, cookies, and OAuth tokens are sensitive credentials and should not be exposed in logs or shared configuration.
- NODE_TLS_REJECT_UNAUTHORIZED=0 weakens TLS certificate validation and should only be used intentionally for invalid or self-signed certificates.
- Remote HTTP deployments require correctly configured authentication, sessions, origins, hosts, and proxy trust settings.
- download_job_artifacts and other download tools may save content to local paths.
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Code, VS Code, GitHub Copilot, Codex, Cursor, Cline, Roo Code, Kilo Code, Amp Code, Claude.ai, OpenCode, Factory AI Droid, OpenClaw | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 100 | 0 |
|---|