# mcp.jmrp.io — public MCP servers

> Two Model Context Protocol servers, self-hosted and free to use. Point your MCP client at an endpoint, or try them in the browser.
> This file is an index, not a corpus. Every entry links to the markdown twin
> that carries the detail, which is what keeps the index small enough to fit
> in an agent's context. Each page of this site is published as markdown at
> its own URL with `index.md` appended.

This file is the protocol-level companion to https://mcp.jmrp.io/llms.txt: one
section per server with its endpoint, headers, surface and an example call,
plus the credential policy that spans both. What a single page already says —
its prose, and the client configuration — stays in that page's twin rather
than being repeated here, so the two cannot come to disagree.
Both language versions of the site (https://mcp.jmrp.io/, https://mcp.jmrp.io/es/) describe exactly the same
servers; only the prose is translated.

## Protocol

All servers speak the Model Context Protocol over streamable HTTP:

- One POST endpoint per server, JSON-RPC 2.0 in the body.
- `Accept: application/json, text/event-stream` — answers may come back as a
  single JSON object or as an SSE frame whose last `data:` line carries it.
- Stateless: no `Mcp-Session-Id`, every POST is self-contained.
- A GET never returns a page: libgen answers 405, gitlab answers 401.

## libgen

No account required. Search, read and get download links for books and papers across arXiv, Crossref, OpenLibrary, Gutenberg, PubMed and Library Genesis.

### Does libgen cost anything, and do I need an account?

Neither. libgen takes no credential at all: no account here, no API key, no per-source registration. Every source it queries is open or public, and none of them asks you to sign up first, which is why the endpoint accepts a call from anyone who can reach it.

The only ceilings are the ones described below, which are there to spend third-party capacity slowly and keep each instance answering, not to ration yours.

### Where does libgen search, and what is its legal position?

libgen is a client of third-party public indexes: it queries open-access providers (arXiv, Crossref, OpenLibrary, Project Gutenberg, dblp, PubMed, ERIC, OpenAlex, Europe PMC, bioRxiv, the RFC Editor, NIST, Dagstuhl, the ACL Anthology, Zenodo, SciELO, FAO, Fatcat, OAPEN and the Internet Archive) and shadow-library sources — a Library Genesis mirror, Anna's Archive, Sci-Hub, SciDB and randombook.org. It hosts no catalogue and stores or redistributes no content of its own — `download` returns a link to the source, it does not serve the file.

What you do with those links is your responsibility, and the rules that apply depend on where you are.

### What are libgen's rate limits and availability?

libgen at mcp.jmrp.io is a personal service, offered as-is and with no SLA. It may change or go away without notice, so do not build anything critical on top of it — run your own instance instead: the server is open source and a single static binary.

Its catalogue queries and every download share one limiter per instance, about 2 requests a second (3 instances, so roughly 6 a second in total). The open-access sources it also searches — arXiv, Crossref, PubMed and the rest — are each paced on their own, at the rate that source asks of its clients. OpenAlex meters an address rather than a person, so everyone using this endpoint shares its daily allowance: its search results, and the works a record cites or that cite it, can run out sooner here than on a server of your own. Those ceilings are deliberately low: they point at third-party services, and going faster would spend their capacity, not ours.

Each address may make 60 calls a second per instance, in bursts of up to 40, with listing the tools on a bucket of its own; a tool call past that comes back as an error the model can read and back off from. Each instance also bounds what it holds open: at most four download or read calls per address at a time (64 across the instance), and 2,384 calls of any kind. Past the first, the call is refused with a message telling you to let one finish; past the second, the server answers that it is busy — on the current protocol, HTTP 503 with Retry-After: 30 — instead of queuing it.

- Endpoint: `https://mcp.jmrp.io/libgen` (POST only; GET answers 405)
- Transport: streamable HTTP, stateless JSON-RPC 2.0
- Version: 2.2.1
- Repository: https://github.com/jmrplens/libgen-mcp
- Documentation: https://jmrp.io/docs/libgen-mcp
- Health: `https://mcp.jmrp.io/libgen/health` (GET, no credentials)
- Authentication: none. The server is public and takes no credentials.

Tools:

- `search` — Find books, papers, comics, magazines and standards, with metadata and download links, optionally within a range of publication years.
- `get_details` — Full metadata for one record (identifiers, DOI, cover, other editions), citations in BibTeX and RIS plus, on request, six more styles or CSL-JSON, the works it cites or that cite it, and a pasted reference resolved to its DOI.
- `read` — Extract and paginate the text of a book or paper, search inside it or read one section of its table of contents, so a model can read it without downloading it whole.
- `download` — Resolve a download link from an md5, ISBN or DOI. Over HTTP it returns the link, it does not write files.

Prompts — canned plans a client can render, beyond the tools above:

- `acquire_book` — Find a book across the catalogs and open-access sources, then generate step-by-step instructions to confirm and download the best matching edition.
- `research_topic` — Survey papers and books on a topic across the catalogs and open-access sources, then build a reading list with instructions to download and produce an annotated bibliography.
- `get_paper` — Resolve a specific paper by DOI or by a free-text citation and generate instructions to download it.
- `download_troubleshoot` — Diagnose a failed or stuck download and produce a step-by-step recovery plan tailored to the identifier, the enabled providers, and any error message.

Verify the live list with:

```http
POST https://mcp.jmrp.io/libgen
Content-Type: application/json
Accept: application/json, text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}
```

Client configuration — Claude Code, Cursor and VS Code, for both the OAuth
and the pasted-token paths — is on the server's page and in its markdown
twin: https://mcp.jmrp.io/servers/libgen/index.md

Mind the top-level key when you read them: Cursor reads `mcpServers` with no
`type` field, VS Code reads `servers` with `type: "http"`.

## gitlab

Free hosted GitLab MCP endpoint, no account beyond your own gitlab.com token, never written to disk. Over 700 operations: projects, MRs, pipelines.

### Does gitlab cost anything, and do I need an account?

The endpoint is free and there is nothing here to sign up for. What it needs is a gitlab.com account you already have, because the server acts as you: it holds no account of its own and issues no credential, so there is no key to request and no plan to pick.

Whatever quota you spend is your own on gitlab.com, and what you can reach is whatever that token can reach — this server adds no tier of its own.

### Where does your GitLab token go?

Your token stays in your browser's memory only. It is not written to localStorage or cookies, never travels in the URL, and is gone on reload. It is sent solely as an Authorization: Bearer header to mcp.jmrp.io/gitlab, which never writes it to disk or logs it: the server keeps it in memory only while you keep using it — up to an hour after your last call — and then drops it.

The destination is not a matter of trust: this page's Content-Security-Policy declares connect-src 'self' https://gitlab.com and form-action 'self', so the browser itself refuses to send the token anywhere but this domain and the one that issues it. gitlab.com is on that list for exactly one reason — the sign-in button, which exchanges an authorization code for a token issued to the inspector's own OAuth application, scoped to read_api and nothing wider — and for nothing else. What the server then does with it — keep it in memory while you use it, re-check it with gitlab.com every fifteen minutes, and drop it — you can verify in its source code, which is public.

Even so, be suspicious of any site asking for a token — this one included. The sensible habits are:

- Verify it yourself: this page's source is public, and so is the server's.
- Use the narrowest credential that does what you need. A token scoped to read_api is admitted and served exactly the actions GitLab accepts from that scope, which are reads: it cannot break anything, and it is the right one for trying the server out. api is only needed to reach the actions that write. Narrower still is a GitLab fine-grained token, limited to the projects and permissions you pick: the server serves it only what its grant reaches, and turns it away at the door unless the grant includes User: Read. The server decides per action, not once at the door, so asking for less is served less rather than refused.
- Revoke it when you are done testing.
- Never reuse a token you rely on in production.

### What are gitlab's rate limits and availability?

The gitlab endpoint at mcp.jmrp.io is likewise personal, with no SLA and no continuity guarantee. For anything critical, run your own instance — the server is open source and ships as one static binary.

Each credential has its own budget on each of the three instances: 60 calls a second that reach GitLab, in bursts of up to 40, with listing the catalogue on a separate bucket that refills a tenth as fast. Past that, what you spend is gitlab.com's quota, under your own token.

Failed sign-ins are counted per address. Ten in a minute block that address until the minute is out; fifty different rejected tokens in ten minutes block it for a minute, then ten, then an hour at a time. A client retrying one expired token recovers on its own; one trying token after token does not.

- Endpoint: `https://mcp.jmrp.io/gitlab` (POST only; GET answers 401)
- Transport: streamable HTTP, stateless JSON-RPC 2.0
- Version: 3.2.0
- Repository: https://github.com/jmrplens/gitlab-mcp-server
- Documentation: https://jmrp.io/docs/gitlab-mcp-server
- Health: `https://mcp.jmrp.io/gitlab/health` (GET, no credentials)
- Required headers:
  - `Authorization` (credential — never store it): Your gitlab.com credential, sent as Bearer: an OAuth access token, or a personal access token used the same way. Never written to disk or logged on the server.

Tools:

- `gitlab_find_action` — Search the action catalogue by what you want to do. Read-only: it does not call GitLab.
- `gitlab_execute_action` — Run one catalogue action: projects, merge requests, issues, pipelines, releases, runners, wikis and more.

Prompts — canned plans a client can render, beyond the tools above:

- `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.

Resources — documents the server serves by URI, read with `resources/read`:

- `gitlab://groups` — Groups accessible to the authenticated user, up to one page (100). Returns each group's ID, name, full path, description, visibility level, and web URL.
- `gitlab://guides/code-review` — Code review checklist and best practices for GitLab merge request reviews.
- `gitlab://guides/conventional-commits` — Conventional commit message format and examples for consistent Git history.
- `gitlab://guides/git-workflow` — Best practices for Git branching strategies with GitLab (feature branches, trunk-based, GitLab Flow).
- `gitlab://guides/merge-request-hygiene` — Guidelines for creating and reviewing high-quality merge requests.
- `gitlab://guides/pipeline-troubleshooting` — Common GitLab CI/CD pipeline issues and how to diagnose and fix them.
- `gitlab://tools` — Surface-aware manifest of the tools and executable actions available in this server instance. Use gitlab://tools/{id} to fetch one entry's accepted call shape and input schema.
- `gitlab://user/current` — Get the currently authenticated GitLab user profile. Returns username, display name, email, state (active/blocked), admin status, and web URL.

Resource templates — the same, parameterized; fill the `{…}` slots before reading:

- `gitlab://group/{group_id}` — Get details for a specific GitLab group by numeric ID or URL-encoded path. Returns name, full path, description, visibility, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://group/{group_id}/label/{label_id}` — Get details for a single group label by numeric ID or name. Returns id, name, color, and description. Usage counts come from group.group_label_list with with_counts. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://group/{group_id}/members` — Members of a GitLab group, up to one page (100), with their access levels (10=guest, 20=reporter, 30=developer, 40=maintainer, 50=owner). Includes inherited members.
- `gitlab://group/{group_id}/milestone/{milestone_iid}` — Get details for a single group milestone by IID. Returns id, iid, title, description, state, due date, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://group/{group_id}/projects` — Projects within a GitLab group, up to one page (100). Returns each project's ID, name, namespace path, visibility, web URL, description, and default branch.
- `gitlab://project/{project_id}` — Get basic metadata for a GitLab project by numeric ID or URL-encoded path. Returns name, namespace path, visibility, web URL, description, and default branch. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/board/{board_id}` — Get details for a single project issue board by numeric ID. Returns id and name. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/branch/{branch}` — Get details for a single repository branch. Returns name, protection status, merge status, default flag, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/branches` — Branches in a GitLab project, up to one page (100). Returns each branch's name, protection status, merge status, default flag, and web URL.
- `gitlab://project/{project_id}/commit/{sha}` — Get details for a single commit by SHA. Returns id, short_id, title, message, author and committer names and emails, authored/committed dates, parent commits, web URL, and stats (additions, deletions and their total).
- `gitlab://project/{project_id}/deploy_key/{deploy_key_id}` — Get details for a single project deploy key by numeric ID. Returns id, title, key, and fingerprint. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/deployment/{deployment_id}` — Get details for a single project deployment by numeric ID. Returns id, iid, ref, sha, status, and environment name. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/environment/{environment_id}` — Get details for a single project environment by numeric ID. Returns id, name, slug, state, and tier. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/feature_flag/{name}` — Get details for a single project feature flag by name. Returns name, description, active, and version. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/file/{ref}/{+path}` — Get the contents of a repository file at a specific ref (branch, tag, or SHA). Path may include slashes. Files over 1 MiB return metadata only with truncated=true. Binary files return metadata with empty content. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/issue/{issue_iid}` — Get details of a specific issue by its IID (project-scoped ID). Returns title, state, labels, assignees, author, web URL, and creation date. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/issues` — Open issues for a GitLab project, up to one page (100). Returns each issue's IID, title, state, labels, assignees, author, web URL, and creation date.
- `gitlab://project/{project_id}/job/{job_id}` — Get details for a single CI job by numeric ID. Returns id, name, stage, status, ref, duration, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/label/{label_id}` — Get details for a single project label by numeric ID or label name. Returns id, name, color, and description. Usage counts come from project.label_list with with_counts. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/labels` — Labels defined in a GitLab project, up to one page (100). Returns each label's name, color, description, and counts of open issues and merge requests using the label.
- `gitlab://project/{project_id}/members` — Members of a GitLab project, up to one page (100), with their access levels (10=guest, 20=reporter, 30=developer, 40=maintainer, 50=owner). Includes inherited members from parent groups.
- `gitlab://project/{project_id}/milestone/{milestone_iid}` — Get details for a single project milestone by IID. Returns id, iid, title, description, state, due date, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/milestones` — Milestones in a GitLab project, up to one page (100). Returns each milestone's title, description, state (active/closed), due date, and web URL.
- `gitlab://project/{project_id}/mr/{merge_request_iid}` — Get details of a specific merge request by its IID (project-scoped ID). Returns title, state, source/target branches, author, merge status, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/mr/{merge_request_iid}/discussions` — List discussion threads on a merge request. Returns up to one page of 100 discussions. A busier merge request has more than this resource shows. Each discussion has an id, individual_note flag, and an array of notes (id, author, body, system, resolved/resolvable, created_at). Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/mr/{merge_request_iid}/notes` — List notes (comments) on a merge request. Returns up to one page of 100 notes, newest ordering as GitLab returns it. A busier merge request has more than this resource shows. Each note carries id, author username, body, system flag, resolvable/resolved flags, and timestamps. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/pipeline/{pipeline_id}` — Get details of a specific CI/CD pipeline by its numeric ID. Returns pipeline status, ref, SHA, source, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/pipeline/{pipeline_id}/jobs` — Jobs for a specific CI/CD pipeline, up to one page (100), including each job's name, stage, status, duration, failure reason (if failed), and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/pipelines/latest` — Get the latest CI/CD pipeline of a GitLab project's default branch. Returns pipeline ID, status (running/pending/success/failed/canceled), ref, SHA, source, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/release/{tag_name}` — Get details for a single GitLab release by tag name. Returns tag_name, name, description, author, creation/release dates. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/releases` — Releases for a GitLab project, up to one page (100). Returns each release's tag name, name, description, author, and creation/release dates.
- `gitlab://project/{project_id}/snippet/{snippet_id}` — Get details for a single project snippet by numeric ID. Returns id, title, file_name, description, visibility, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/tag/{tag_name}` — Get details for a single Git tag. Returns name, target commit SHA, annotation message, and protection status. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://project/{project_id}/tags` — Repository tags for a GitLab project, up to one page (100). Returns each tag's name, message, target commit SHA, protection status, and creation date.
- `gitlab://project/{project_id}/wiki/{slug}` — Get a wiki page by slug. Returns title, slug, format (markdown/rdoc/asciidoc/org), and raw content. Slugs are case-sensitive and use hyphens for spaces. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://snippet/{snippet_id}` — Get details for a single personal/global snippet by numeric ID. Returns id, title, file_name, description, visibility, and web URL. Subscribable: subscriptions/listen (protocol 2026-07-28). Resources/subscribe on stateful sessions.
- `gitlab://tools/{id}` — Accepted call shape and input schema for one entry from gitlab://tools. Replace {id} with an entry ID from the active surface, such as project.get in dynamic mode, gitlab_project.get in meta mode, or gitlab_project_get in individual mode.

Subscriptions — watch a resource and be notified when it changes:

- `resources/subscribe` — not available here: requires stateful sessions (--stateless=false)
- `subscriptions/listen` — available (since protocol 2026-07-28)
- 26 of the resource templates above are subscribable — the ones whose `resources/templates/list` entry carries `_meta["io.github.jmrplens/subscribable"]: true`.

Action catalog — the tools above front a catalog of 768 actions across 29 domains (project, user, group, issue, …), counted with a Free-tier token — tier and token permissions both move the count. Browse the index at https://mcp.jmrp.io/servers/gitlab/actions.json, or read `gitlab://tools` with `resources/read`.

Verify the live list with:

```http
POST https://mcp.jmrp.io/gitlab
Content-Type: application/json
Accept: application/json, text/event-stream
Authorization: Bearer <your token>

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}
```

Client configuration — Claude Code, Cursor and VS Code, for both the OAuth
and the pasted-token paths — is on the server's page and in its markdown
twin: https://mcp.jmrp.io/servers/gitlab/index.md

Mind the top-level key when you read them: Cursor reads `mcpServers` with no
`type` field, VS Code reads `servers` with `type: "http"`.

## Credential policy

`Authorization` travels in the request that needs it and is
never written to disk or logged: not by the server, which holds it in memory
only while a client keeps using it and drops it afterwards, and not by the web
inspector, which keeps it in the tab's memory only — no
localStorage, no cookies, no query string, no logs. Reloading the page drops it.

For `gitlab` that credential is `Authorization: Bearer <token>`, and either
kind works: an OAuth access token obtained from gitlab.com, or a personal
access token sent the same way, classic or fine-grained. An unauthenticated
call answers `401` with a `WWW-Authenticate` challenge naming
`https://mcp.jmrp.io/.well-known/oauth-protected-resource/gitlab`, the RFC 9728
document that says which authorization server issues tokens for this endpoint.

Treat any site that asks for a token with suspicion, this one included. Ask
for the narrowest scope that does what you need: a token scoped to
`read_api` is admitted and served exactly the actions GitLab accepts from that
scope, which are reads and the right ones for trying the server out, while
`api` is only needed to reach the actions that write. A fine-grained personal
access token is narrower still: it carries a grant of named permissions on the
projects or groups you pick, the server serves it only what that grant reaches,
and it refuses one at the door unless the grant includes `User: Read`. The
decision is per action rather than once at the door, so a client that asks for
less is served less rather than refused.

The RFC 9728 document named by the `401` challenge advertises exactly one
scope, `api`: the one that buys the full surface, and the one a
client that discovers scopes will ask GitLab for. It never lists both, because
such a client asks for everything listed and GitLab refuses an authorization
request naming any scope the OAuth application lacks (`invalid_scope`). A
client that wants a read-only credential names `read_api` itself, from an
application that has that scope checked.
Use a token you created for this, and revoke it when you are done.