Policies

Privacy & data

This service is run by José Manuel Requena Plens (jmrp.io), who is also the author of both servers. The site sets no cookies and runs no analytics scripts; the only thing it stores in your browser is the theme you pick, in localStorage, and that never leaves it. The Content-Security-Policy names exactly one third party — gitlab.com, and only so the inspector's sign-in flow can exchange an authorization code for a token, which is disabled right now — and the browser refuses every other destination.

One party sits in front of all of it: Cloudflare, which fronts mcp.jmrp.io and decrypts and re-encrypts every request it forwards — page views and MCP calls alike — as any CDN does. It sees what this server sees, including an Authorization header on its way through. The edge script that mints this site's nonces only ever handles page reads — MCP calls bypass it entirely — and keeps no copy of any request, but Cloudflare's own logs of that script record the URL, method, status and request headers of each page request for a few days. The one report your browser may still send is a Cloudflare network-error report — only when a request to this site fails, with a connection error or a 4xx or 5xx response, only from Chromium browsers, and to Cloudflare, not to this server. Internals describes that hop.

A credential you send travels as a request header to the server you chose and is never written to disk or logged. gitlab keeps it in memory while you keep using it — for up to an hour after your last call, checking every fifteen minutes with gitlab.com that it is still valid — and then drops it.

libgen needs none to be used at all; the one exception is opt-in: a download that sets annas_member asks your client for an Anna's Archive membership key, uses it for that request and never stores it. gitlab is the server that asks for a credential. Where that value goes, what the browser itself prevents, and how to scope and revoke it are set out in full in its security notice on the home page: Where does your GitLab token go?

Logs and retention

The web server keeps standard access logs — IP address, user agent, the request line (method, path and query string), status code, response size, referrer, and the country, city and network operator that IP resolves to, looked up locally in a MaxMind database rather than by asking anyone — for abuse prevention (CrowdSec reads them) and for the author's own usage dashboards. The files are rotated daily and deleted after a year; the copy that feeds the dashboards lives on the author's own network.

The body of a call is never logged: it carries the arguments, which is to say whatever you actually searched for or asked — nginx inspects it only to pull out two names. Usage metrics record the JSON-RPC method, the tool name, the call's status, timing and response size, which instance and exit served it, and the caller's IP address — which is there so the author can tell their own test traffic from real use — but never the arguments, and never the content of the response. Those metrics feed the same dashboards.

gitlab additionally exports OpenTelemetry traces and metrics to a collector on the author's network: the method, the tool and the catalogue action (issue.list, say), success or the error code, timings, and a keyed pseudonym of the caller and of any resource read — stable across restarts, readable by no one — but never the arguments, the results, the token or any GitLab response.

No SLA

This is a personal service, offered as-is with no service-level agreement: no uptime guarantee, no support channel, and no commitment that either endpoint stays online — or unchanged — from one day to the next. Do not build anything critical on top of it; both servers are open source, and running your own instance is one static binary away.

Where a request appears to come from

Calls the servers make outward — to a Library Genesis mirror, the open-access providers, or gitlab.com — leave through an exit node in Spain or the United Kingdom, not from wherever you or this site happen to be. What that third party sees as the source of the request is the exit node's address: neither your own IP address nor this server's ever reaches it. The one transfer that does not go this way is the one behind a link handed back to you — download's above all: fetching it is your own client's connection, from your own address.

Which nodes there are, which instance leaves through which, and what happens when one fails are described under Internals: Egress: which exit a request leaves from

Legal position

libgen runs no catalogue and hosts nothing of its own: it is a client of indexes and libraries other people operate. On the open side those are 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; on the shadow-library side, a Library Genesis mirror, randombook.org, Anna's Archive, Sci-Hub, and the SciDB article viewer Anna's Archive runs. Which of them a call reaches, and in what order, is a property of the tool you call rather than of the service as a whole.

search starts from the Library Genesis catalogue; on this deployment the operator's default is extra_sources=always, so a call that does not say otherwise also reaches Anna's Archive and seven open providers — arXiv, Crossref, OpenLibrary, Project Gutenberg, dblp, PubMed and ERIC — on every call, and a call that sets extra_sources=never keeps to the catalogue alone. download and read go by identifier — read takes a hash or a DOI only: an article asked for by DOI is tried at thirteen open sources first — OpenAlex, Europe PMC, bioRxiv, the RFC Editor, NIST, Dagstuhl, the ACL Anthology, Zenodo, SciELO, FAO, Fatcat, Crossref and OAPEN — and reaches Sci-Hub, then SciDB, only when none of those serves it; a book asked for by ISBN is looked for at OAPEN and the Internet Archive only, which serve openly licensed copies and nothing else; and a book asked for by its catalogue hash, which is the shadow libraries' own identifier, goes straight to them — the Library Genesis mirror, then randombook.org, then Anna's Archive. get_details adds Crossref and OpenLibrary metadata on request, and falls back to Anna's Archive for a hash the catalogue does not carry. download states that order in its own description, and read lists its sources in its source parameter, on libgen's server card.

libgen's download tool never delivers a file over HTTP, which is the only way this endpoint is reached: it resolves the identifier you gave it and hands back a link to whichever source holds the item, for your own client to fetch. Its read tool does fetch the file, to return the slice of text you asked for, and keeps what it fetched in a cache on the instance that served you. Either way, mcp.jmrp.io publishes no catalogue and offers no file for anyone else to fetch: the transfer, if you make it, is between you and that third party.

What you do with the links libgen returns is your responsibility, under whichever law applies to you. gitlab does nothing more than relay calls to gitlab.com with the credential you supply, and grants no right beyond what gitlab.com already grants you.

This service is operated from Spain by a private individual, not a company, and is not affiliated with any of the sources named above: it only queries them, and their names belong to their owners.

Questions about this page, and requests that this host stop resolving a given item or source, go to the address in the site's security.txt: mail@jmrp.io

None of this is a license over anything: what this site itself lets you reuse — its text, its code and the two servers — is stated on its own page: License