# gitlab > Endpoint MCP de GitLab alojado y gratuito, sin más cuenta que tu propio token de gitlab.com, que nunca se escribe en disco. Más de 700 operaciones. > Esta página en markdown. Índice: https://mcp.jmrp.io/llms.txt Canonical: https://mcp.jmrp.io/es/servers/gitlab/ Language: es Alternate: https://mcp.jmrp.io/servers/gitlab/index.md Updated: 2026-10-10T10:20:05+02:00 License: https://mcp.jmrp.io/es/license/ ## Resumen - Endpoint: `https://mcp.jmrp.io/gitlab` (solo POST; un GET responde 401) - Transporte: HTTP streamable, JSON-RPC 2.0 sin estado - Versión: 3.2.0 - Autenticación: `Authorization` - Salud: `https://mcp.jmrp.io/gitlab/health` - Repositorio: https://github.com/jmrplens/gitlab-mcp-server - Documentación: https://jmrp.io/docs/gitlab-mcp-server ## Conectarlo a tu cliente ### Entrar con OAuth (recomendado) Tu cliente abre gitlab.com en el navegador, autorizas ahí y él guarda el token: no pegas ninguno. El client ID hay que configurarlo sí o sí — sin él estos clientes caen al registro dinámico, que GitLab responde con un alcance que este servidor no puede usar. **Claude Code** ```sh claude mcp add gitlab --transport http \ --client-id c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941 \ --callback-port 8090 \ https://mcp.jmrp.io/gitlab ``` **Cursor — ~/.cursor/mcp.json** ```json { "mcpServers": { "gitlab": { "type": "http", "url": "https://mcp.jmrp.io/gitlab", "oauth": { "clientId": "c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941", "scopes": [ "api" ] } } } } ``` **VS Code — .vscode/mcp.json** ```json { "servers": { "gitlab": { "type": "http", "url": "https://mcp.jmrp.io/gitlab", "oauth": { "clientId": "c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941", "scopes": [ "api" ] } } } } ``` ### O pegar un token **Claude Code** ```sh claude mcp add --transport http gitlab \ https://mcp.jmrp.io/gitlab \ --header "Authorization: Bearer " ``` **Cursor — ~/.cursor/mcp.json** ```json { "mcpServers": { "gitlab": { "url": "https://mcp.jmrp.io/gitlab", "headers": { "Authorization": "Bearer ${env:GITLAB_TOKEN}" } } } } ``` **VS Code — .vscode/mcp.json** ```json { "inputs": [ { "type": "promptString", "id": "gitlab-token", "description": "Tu credencial de gitlab.com, enviada como Bearer: un token de acceso OAuth, o un personal access token usado igual. Nunca se escribe en disco ni se registra en el servidor.", "password": true } ], "servers": { "gitlab": { "type": "http", "url": "https://mcp.jmrp.io/gitlab", "headers": { "Authorization": "Bearer ${input:gitlab-token}" } } } } ``` ## Antes de apoyarte en esto Este endpoint es un servicio personal, operado por una sola persona y ofrecido tal cual: sin SLA, sin canal de soporte y sin promesa de que siga en pie —o igual— la semana que viene. Los dos servidores son open source y son un único binario estático, así que lo que no puedas permitirte perder es mejor levantarlo en tu propia instancia. Cada credencial tiene 60 llamadas por segundo a GitLab por instancia, en ráfagas de hasta 40, y los accesos fallidos repetidos bloquean la dirección durante un tiempo. Por encima de eso, cada llamada se descuenta de los límites de gitlab.com, con tu propio token. Detrás del endpoint hay tres instancias de este servidor. Un hash consistente hace que el mismo cliente vuelva siempre a la misma, y cada instancia sale hacia fuera por su propio nodo de salida, en España o en Reino Unido: Cómo se enruta una petición, salto a salto: https://mcp.jmrp.io/es/internals/ Qué se registra y durante cuánto tiempo, de dónde parece venir una petición y la base legal de todo ello están escritos enteros en: Privacidad, logs y postura legal: https://mcp.jmrp.io/es/policies/ ### ¿gitlab cuesta algo, y hace falta cuenta? El endpoint es gratuito y aquí no hay nada a lo que darse de alta. Lo que necesita es una cuenta de gitlab.com que ya tengas, porque el servidor actúa en tu nombre: no tiene cuenta propia ni emite credencial alguna, así que no hay clave que pedir ni plan que elegir. La cuota que gastes es la tuya en gitlab.com, y lo que alcances es lo que alcance ese token: este servidor no añade ningún tier propio. ### ¿A dónde va tu token de GitLab? Tu token se queda solo en la memoria de tu navegador. No se guarda en localStorage ni en cookies, no viaja en la URL y desaparece al recargar. Se envía únicamente como cabecera Authorization: Bearer a mcp.jmrp.io/gitlab, que nunca lo escribe en disco ni lo registra: el servidor lo conserva en memoria solo mientras lo sigas usando —hasta una hora después de tu última llamada— y después lo descarta. El destino no es cuestión de confianza: la Content-Security-Policy de esta página declara connect-src 'self' https://gitlab.com y form-action 'self', así que es el propio navegador el que impide enviar el token a ningún sitio que no sea este dominio y el que lo emite. gitlab.com está en esa lista por una única razón —el botón de acceso, que canjea un código de autorización por un token emitido a la aplicación OAuth propia del inspector, con alcance read_api y nada más— y por ninguna otra. Lo que el servidor haga después con él —conservarlo en memoria mientras lo uses, volver a comprobarlo con gitlab.com cada quince minutos y descartarlo—, puedes comprobarlo en su código fuente, que es público. Aun así, desconfía por norma de cualquier web que te pida un token, incluida esta. Lo razonable es: - Comprobarlo tú mismo: el código de esta página es público, y el del servidor también. - Usar la credencial más estrecha que te sirva. Un token con alcance read_api se admite y recibe exactamente las acciones que GitLab acepta de ese alcance, que son lecturas: no puede romper nada, y es el adecuado para probar el servidor. api sólo hace falta para llegar a las acciones que escriben. Más estrecho todavía es un token fine-grained de GitLab, limitado a los proyectos y permisos que elijas: el servidor le sirve sólo lo que alcanza su concesión, y lo rechaza en la puerta si la concesión no incluye User: Read. El servidor decide acción por acción, no una vez en la puerta, así que pedir menos te sirve menos en lugar de rechazarte. - Revocarlo cuando termines de probar. - No reutilizar nunca un token que uses en producción. ### ¿Qué límites de peticiones y disponibilidad tiene gitlab? El endpoint gitlab de mcp.jmrp.io es igualmente personal, sin SLA ni garantía de continuidad. Para algo crítico, levanta tu propia instancia — el servidor es open source y un único binario estático. Cada credencial tiene su propio presupuesto en cada una de las tres instancias: 60 llamadas por segundo que lleguen a GitLab, en ráfagas de hasta 40, y el listado del catálogo en un cubo aparte que se rellena diez veces más despacio. Por encima de eso, lo que gastas es la cuota de gitlab.com, con tu propio token. Los accesos fallidos se cuentan por dirección. Diez en un minuto bloquean esa dirección hasta que pasa el minuto; cincuenta tokens rechazados distintos en diez minutos la bloquean un minuto, luego diez, y después una hora cada vez. Un cliente que reintenta con un token caducado se recupera solo; uno que prueba token tras token, no. ## Instrucciones de uso Lo que el propio servidor le dice a cada cliente al conectar (server/discover), citado tal cual (en inglés). gitlab-mcp-server exposes GitLab projects, merge requests, issues, branches, tags, releases, repositories, commits, files, groups, members, and uploads. FINDING TOOLS. This server exposes two tools that reach the whole GitLab API: 1. Call gitlab_find_action with a natural-language description of the task to get matching action IDs and their input schemas. 2. Call gitlab_execute_action with that action ID, its parameters under 'params'. 3. Every action="..." named below is a canonical action ID: pass it to gitlab_execute_action directly, no find step needed. PROJECT DISCOVERY. To find the project_id needed for most operations: 1. Read the .git/config file from the workspace to find [remote "origin"] url = ... 2. Call action="discover_project.resolve" with that URL to get the project_id. 3. Alternatively, use action="project.list" (owned=true) or action="search.projects" to find projects by name. DEFAULT BRANCH. When generating URLs to repository files or branches: 1. Call action="project.get" to retrieve the project metadata, which includes the default_branch field. 2. ALWAYS use the returned default_branch value (e.g. develop, master) instead of assuming 'main'. 3. Projects can use any branch as default, so NEVER hardcode 'main' in URLs. PACKAGE + RELEASE WORKFLOW. When uploading packages and linking them to releases: 1. Preferred: Use action="package.publish_and_link" to upload a file and create the release link in one step. 2. Alternative: Use action="package.publish" first, then use the 'url' field from its response as the URL for action="release.link_create". 3. NEVER construct package download URLs manually. Always use the actual URL returned by the publish tool. 4. RELEASE LINK NAMING: The link_name MUST be the exact filename (e.g. 'checksums.txt.asc'), NEVER add descriptive suffixes like '(GPG signature)'. go-selfupdate and other tools match asset names exactly. RELEASE CREATION. When creating releases: 1. You do NOT need to create the tag first. Provide 'ref' (branch or SHA) in action="release.create" and GitLab auto-creates the tag. 2. The response includes 'assets_sources' with auto-generated tar.gz/zip archive URLs. Use those, never construct source archive URLs. 3. Use 'tag_message' to create an annotated tag instead of a lightweight one. ID vs IID. GitLab uses two identifiers for issues and merge requests: 1. IID is the project-scoped number shown in URLs and UI (e.g. issue #3, MR !5). Most operations expect IID. 2. ID is the global numeric identifier. Only use action="issue.get_by_id" when you have a global ID from another API response. WATCHING RESOURCES. Instead of re-reading a resource in a loop to detect change: 1. Single-object resources (a pipeline, an issue, a merge request, a file, a wiki page, ...) can be watched for change notifications via MCP subscriptions/listen, which protocol revision 2026-07-28 introduced (a client speaking an earlier revision cannot watch resources on this transport: the legacy resources/subscribe is refused here, because each request's session ends with its response); collections (issue lists, branch lists) cannot. 2. Example: subscribe to gitlab://project/{project_id}/pipelines/latest to be notified when a pipeline's state changes, instead of polling it yourself. The server watches GitLab and sends notifications/resources/updated only when the content actually changed. ## Tools - 2 tools - 37 prompts - 8 resources - 37 resource templates - `gitlab_find_action` — Busca en el catálogo de acciones por lo que quieres hacer. Solo lectura: no llama a GitLab. - `gitlab_execute_action` — Ejecuta una acción del catálogo: proyectos, merge requests, incidencias, pipelines, releases, runners, wikis y más. ## Prompts - `audit_commit_hygiene` — Audit commit message quality between two refs. Scores Conventional Commit usage, merge commits, breaking-change markers, body/detail quality, and linked work references for release and contribution readiness. - `audit_project_full` — Audit a GitLab project in one report: a quick scorecard, then settings, branch protection, access management, labels, active milestones, templates, webhooks, and push rules, up to 100 per list. Use this for a complete project health assessment with actionable recommendations. - `audit_project_workflow` — Audit workflow configuration for a GitLab project: labels (names, colors, descriptions, open issue/MR counts), milestones (open/closed, due dates), and issue/MR templates, up to 100 per list. Identifies gaps like labels without descriptions, milestones without due dates, or missing templates. - `branch_mr_summary` — List up to 100 MRs targeting a specific branch in a project. Shows a readiness summary with total, draft and conflict counts. Ideal for release branch reviews. - `compare_branches` — Compare commit and file differences between two Git refs. Use for release branch preparation, feature branch divergence analysis, or deciding whether a merge/backport needs deeper review. - `daily_standup` — Generate a daily standup summary for a user: contribution events of the last 24 hours, and the project's open MRs they authored, are assigned or review and open issues assigned to or created by them, up to 100 per list. Produces a report with done/planned/blockers sections. - `generate_release_notes` — Generate release notes from the commits, file changes, and merge requests between two Git refs (tags, branches, or SHAs). Produces a structured document with the commits, up to 100 MRs merged around the commits' dates with their labels, contributors, and statistics for organizing into user-friendly release notes. - `group_milestone_progress` — Track the progress of up to 100 active group milestones across the group's projects. Shows issue/MR completion per milestone with progress bars, reading up to 100 issues and 100 MRs of each. - `group_mr_dashboard` — List up to 100 merge requests across a GitLab group with optional state and target branch filters. Shows MRs grouped by project with blocker and readiness summary statistics. - `label_distribution` — Analyze label usage distribution in a project from up to 100 labels. Shows open/closed issue counts and open MR counts per label. Zero additional API calls beyond the label list. - `merge_velocity` — Analyze MR throughput for a project from up to 100 MRs created in the period and since merged. Shows merge rate, average and median time-to-merge, and a daily merged count chart. Ideal for tracking team delivery pace. - `milestone_progress` — Track milestone progress for a project. Shows issue/MR completion, progress bar, and due date risk, reading up to 100 issues and 100 MRs of each milestone. Omit the milestone argument to see up to 100 active milestones. - `mr_description_quality` — Score a merge request description for reviewer readiness. Checks context, linked work, test evidence, rollout/risk notes, checklists, and whether up to 100 changed files suggest missing screenshots or migration notes. - `mr_discussion_health` — Analyze unresolved discussion threads across up to 20 open MRs in a project, the most recently created first, reading up to 100 discussions of each. Use this for review follow-up and merge-readiness cleanup, not approval-rule status. - `mr_risk_assessment` — Assess the risk level (LOW/MEDIUM/HIGH/CRITICAL) of a merge request from up to 100 changed files: size (lines added/removed), number of changed files, new/deleted files, sensitive file patterns (env, auth, migration, CI, security), and conflict status. - `my_activity_summary` — Generate a personal activity summary for a configurable period, across all projects: contribution events by action, the counts of MRs authored that were created in the period and merged and of MRs reviewed that were updated in it, and a daily activity chart, up to 100 per list. - `my_issues` — Show up to 100 issues assigned to you across all projects. Includes overdue detection and project grouping. Use this to see your issue backlog without specifying a project. - `my_open_mrs` — Show the open merge requests across all projects where you are author or assignee, up to 100 of each. Results are grouped by project for easy scanning. Use this to get a personal MR dashboard without specifying a project. - `my_pending_reviews` — Show up to 100 open merge requests across all projects where you are assigned as reviewer. Helps track which MRs are waiting for your review. Results grouped by project. - `project_activity_report` — Generate a project activity report: the counts of events, open MRs, open issues and MRs created in the period and merged, event and contributor breakdowns, a table of those merged MRs, and a daily activity chart, up to 100 per list. - `project_contributors` — Rank up to 100 project contributors by commits, additions, and deletions. Uses the repository contributors API for accurate stats. - `project_health_check` — Project health assessment combining the latest pipeline of the default branch, up to 100 open merge requests, and branch hygiene (merged/stale counts among up to 100 branches). Provides actionable recommendations for project maintenance. - `release_cadence` — Analyze release frequency for a project from its up to 100 most recent releases. Shows the time between the releases of the period, average and median cadence, and a release history table. - `release_readiness` — Check readiness of a release branch from up to 100 open MRs targeting it: draft/conflict counts, and the unresolved discussion threads among up to 100 discussions of each. - `review_mr` — Generate a structured code review for a merge request, reading up to 100 changed files. Files are categorized by risk (high-risk, business logic, tests, documentation) with per-file metrics, branch context, and a review plan. The diff of each file read is included without truncation. - `reviewer_workload` — Analyze review distribution across up to 100 direct members of a group, from up to 100 open group MRs. Shows how many of them each member is reviewing and identifies imbalances. Useful for managers to ensure fair review distribution. - `stale_items_report` — Find up to 100 open MRs and 100 open issues in a project that haven't been updated for a configurable number of days. Helps identify forgotten or blocked items. - `suggest_mr_reviewers` — Suggest suitable merge request reviewers based on up to 100 changed files and the active ones among up to 100 project members, inherited members included. Excludes the MR author and asks the model to consider ownership, approval-rule fit, and workload balance. - `summarize_mr_changes` — Summarize the changed files and key modifications in a merge request, reading up to 100 changed files. Lists each file with its change type (new/modified/deleted/renamed). Use this to quickly understand the scope of a merge request. - `summarize_open_mrs` — Summarize up to 100 open merge requests in a project, the most recently created first, including title, author, branches, age in days, and merge status. Highlights stale MRs (>7 days) and blockers. For one target branch, use branch_mr_summary. - `summarize_pipeline_status` — Summarize the latest CI/CD pipeline of a project's default branch. Groups up to 100 of its jobs by outcome (failed/passed/other) and includes failure reasons for debugging. - `team_member_workload` — Generate a workload summary for a team member over a configurable period: contribution events, the project's open MRs they authored, are assigned or review, MRs they authored that were created in the period and merged, and open authored and assigned issues, up to 100 per list. Use this for team management and capacity planning. - `team_overview` — Generate a team dashboard of up to 100 direct members of a group, each with the counts of their open MRs, of the open MRs they review and of their MRs created in the period and merged, from up to 100 open group MRs and 100 created in the period and merged. Includes a workload distribution pie chart. Requires a GitLab group ID. - `unassigned_items` — Find up to 100 open MRs and 100 open issues in a project that have no assignee. Helps identify ownership gaps and items needing attention. - `user_activity_report` — Generate an activity report for a user: contribution events, MRs they authored that were created in the period and merged, open MRs they review that were updated in it, and a daily activity chart, up to 100 per list. Designed for managers to review team member productivity. - `user_stats` — Generate statistics for a user: contribution events across all projects with their breakdown, daily activity trends and a Mermaid activity chart, and the project's merge request stats (authored/assigned/reviewed by state) and issue stats (authored/assigned by state), up to 100 per list. Use this for performance reviews, productivity tracking, or personal dashboards. - `weekly_team_recap` — Generate a weekly recap for a team: MRs created in the period and merged, by project, open MR and open issue counts, and open MR health (drafts, conflicts), all as tables, up to 100 per list. ## Catálogo de acciones Las tools de arriba dan la cara por un catálogo de 768 acciones en 29 dominios: se encuentran y se llaman a través de ellas, no se exponen una a una. Contado con un token Free — el tier y los permisos del token mueven la cifra. Índice: https://mcp.jmrp.io/servers/gitlab/actions.json. Una página de referencia por dominio en https://mcp.jmrp.io/es/servers/gitlab/actions/. ## Catálogo completo Todas las herramientas, prompts, recursos y plantillas de este servidor —con lo que cada una recibe y devuelve— están listadas en , y el propio servidor las sirve en vivo en `https://mcp.jmrp.io/gitlab/.well-known/mcp/server-card.json`.