Комментарии 2
Хороший практический разбор, особенно часть про self-hosted GitLab и про то, что read-only режим должен быть дефолтом. Это, кажется, главный момент, который часто недооценивают: MCP для GitLab - это не “магия”, а фактически выдача агенту программного доступа к GitLab API, поэтому поверхность инструментов, scopes токена и режим записи важнее, чем сам факт подключения.
У меня был похожий опыт с GitLab MCP, но мы пошли чуть дальше и сделали отдельный open-source сервер под GitLab-сценарии: @yoda.digital/gitlab-mcp-server (https://opensource.yoda.digital/ru/projects/mcp-gitlab-server/)
Не как “единственно правильный вариант”, а скорее как ещё один практический референс для тех, кому нужно больше GitLab-поверхности: проекты, MR, issues, CI/CD, wiki, releases и т.д. Плюс есть read-only режим, потому что давать агенту write-доступ по умолчанию — это уже не автоматизация, а призыв древних богов через API-токен.
Было бы интересно сравнить его с @zereight/mcp-gitlab именно на self-hosted GitLab: покрытие tools, поведение схем, transport, стабильность в Claude Code / Cursor / Codex / Gemini и т.п.

MCP для GitHub + GitLab: инженерный гайд 2026