Two Model Context Protocol servers, self-hosted and free to use. Point your MCP client at an endpoint, or try them in the browser.
The Model Context Protocol (MCP) is an open standard that lets AI assistants use external tools and data sources; mcp.jmrp.io hosts two such servers, libgen and gitlab. Read the specification at modelcontextprotocol.io.
Both servers speak streamable HTTP: one POST per JSON-RPC 2.0 call, stateless — no session header — answering JSON or an SSE stream depending on your Accept header (application/json, text/event-stream). Neither endpoint serves a page to a plain GET: libgen rejects the method with 405, gitlab checks credentials first and answers 401.
libgen
No credentials required
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 ceiling is the rate limit described below, which is there to spend third-party capacity slowly rather than 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 outbound requests are rate-limited to about 2 per second per instance (3 instances, so roughly 6 per second in total) — one limiter for the whole process, covering catalogue queries and downloads alike, whichever source they reach. That ceiling is deliberately low: it points at third-party mirrors, and going faster would spend their capacity, not ours.
Free hosted GitLab MCP endpoint, no account beyond your own gitlab.com token, never written to disk. Over 700 operations: projects, MRs, pipelines.
POSThttps://mcp.jmrp.io/gitlab
v3.1.0 · 3/3 nodes up
Authorization
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.
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 — a sign-in button exchanging an authorization code for a token, currently disabled — 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 gets the read-only part of the surface: 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. The server decides per action, not once at the door, so asking for less is served less rather than refused.
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.
Whatever quota applies is gitlab.com's, spent with your own token: this server adds no limit of its own beyond the site-wide one.
