Políticas

Privacidad y datos

Este servicio lo opera José Manuel Requena Plens (jmrp.io), autor también de los dos servidores. El sitio no usa cookies ni scripts de analítica; lo único que guarda en tu navegador es el tema que elijas, en localStorage, y de ahí no sale. La Content-Security-Policy nombra exactamente un tercero —gitlab.com, y solo para que el flujo de acceso del inspector pueda canjear un código de autorización por un token, que ahora mismo está desactivado— y el navegador rechaza cualquier otro destino.

Delante de todo ello hay un tercero: Cloudflare, que da la cara por mcp.jmrp.io y descifra y vuelve a cifrar cada petición que reenvía —páginas y llamadas MCP por igual—, como cualquier CDN. Ve lo mismo que ve este servidor, incluida una cabecera Authorization de paso. El script de borde que acuña los nonces de este sitio solo atiende lecturas de páginas —las llamadas MCP no pasan por él— y no guarda copia de ninguna petición, pero los logs que Cloudflare lleva de ese script registran la URL, el método, el estado y las cabeceras de cada petición de página durante unos días. El único informe que tu navegador aún puede enviar es un aviso de error de red de Cloudflare: solo cuando falla una petición a este sitio, con un error de conexión o una respuesta 4xx o 5xx, solo desde navegadores Chromium, y a Cloudflare, no a este servidor. Funcionamiento interno describe ese salto.

Una credencial que envíes viaja como cabecera al servidor que elijas y nunca se escribe en disco ni se registra. gitlab la conserva en memoria mientras la sigas usando —hasta una hora después de tu última llamada, comprobando cada quince minutos con gitlab.com que sigue siendo válida— y después la descarta.

libgen no necesita ninguna para usarse; la única excepción es voluntaria: una descarga con annas_member pide a tu cliente una clave de socio de Anna's Archive, la usa para esa petición y no la guarda. gitlab es el servidor que pide una credencial. A dónde va ese valor, qué impide el propio navegador y cómo acotarlo y revocarlo se explican por extenso en su aviso de seguridad, en la portada: ¿A dónde va tu token de GitLab?

Logs y retención

El servidor web guarda logs de acceso estándar —dirección IP, user agent, la línea de petición (método, ruta y query string), código de estado, tamaño de la respuesta, referente, y el país, la ciudad y el operador de red a los que resuelve esa IP, consultados en local en una base de datos de MaxMind y no preguntando a nadie— para prevenir abusos (los lee CrowdSec) y para los paneles de uso del propio autor. Los ficheros rotan a diario y se borran al año; la copia que alimenta los paneles vive en la red del propio autor.

El cuerpo de una llamada nunca se registra: lleva los argumentos, es decir, lo que de verdad buscas o preguntas —nginx lo mira solo para extraer dos nombres—. Las métricas de uso registran el método JSON-RPC, el nombre de la herramienta, el estado, los tiempos y el tamaño de la respuesta, qué instancia y qué salida la sirvieron, y la IP de quien llama —que está ahí para que el autor pueda separar su propio tráfico de pruebas del real—, pero nunca los argumentos ni el contenido de la respuesta. Esas métricas alimentan los mismos paneles.

gitlab exporta además trazas y métricas OpenTelemetry a un colector en la red del autor: el método, la herramienta y la acción de catálogo (issue.list, por ejemplo), el éxito o el código de error, los tiempos y un seudónimo con clave de quien llama y del recurso leído —estable entre reinicios, que nadie puede leer—, pero nunca los argumentos, los resultados, el token ni respuesta alguna de GitLab.

Sin SLA

Este es un servicio personal, ofrecido tal cual y sin acuerdo de nivel de servicio: sin garantía de disponibilidad, sin canal de soporte y sin compromiso de que ninguno de los dos endpoints siga en pie —o igual— de un día para otro. No montes nada crítico encima: los dos servidores son open source y cada uno es un único binario estático, así que para levantar tu propia instancia basta con ese binario.

De dónde parece venir una petición

Las llamadas que los servidores hacen hacia fuera —a un mirror de Library Genesis, a los proveedores de acceso abierto o a gitlab.com— salen por un nodo de salida en España o en Reino Unido, no desde donde estés tú ni desde donde esté este sitio. Lo que ese tercero ve como origen de la petición es la dirección del nodo de salida: ni tu propia IP ni la de este servidor le llegan nunca. La única transferencia que no va por aquí es la que hay detrás de un enlace que se te devuelve —el de download ante todo—: descargarlo es una conexión de tu propio cliente, desde tu propia dirección.

Qué nodos hay, qué instancia sale por cuál y qué pasa cuando uno falla se describen en Funcionamiento interno: Salida: por dónde sale una petición

Postura legal

libgen no opera catálogo alguno ni aloja nada propio: es un cliente de índices y bibliotecas que gestionan otros. Del lado abierto son arXiv, Crossref, OpenLibrary, Project Gutenberg, dblp, PubMed, ERIC, OpenAlex, Europe PMC, bioRxiv, el RFC Editor, NIST, Dagstuhl, la ACL Anthology, Zenodo, SciELO, la FAO, Fatcat, OAPEN e Internet Archive; del lado de las bibliotecas en la sombra, un mirror de Library Genesis, randombook.org, Anna's Archive, Sci-Hub y el visor de artículos SciDB de Anna's Archive. A cuáles llega una llamada, y en qué orden, lo decide la herramienta que llamas y no el servicio entero.

search parte del catálogo de Library Genesis; en este despliegue el valor por defecto del operador es extra_sources=always, así que una llamada que no diga otra cosa llega además a Anna's Archive y a siete proveedores abiertos —arXiv, Crossref, OpenLibrary, Project Gutenberg, dblp, PubMed y ERIC— en todas las llamadas, y una que fije extra_sources=never se queda solo en el catálogo. download y read van por identificador —read solo admite hash o DOI—: un artículo pedido por DOI se intenta primero en trece fuentes abiertas —OpenAlex, Europe PMC, bioRxiv, el RFC Editor, NIST, Dagstuhl, la ACL Anthology, Zenodo, SciELO, la FAO, Fatcat, Crossref y OAPEN— y solo llega a Sci-Hub, y después a SciDB, cuando ninguna de ellas lo sirve; un libro pedido por ISBN se busca únicamente en OAPEN e Internet Archive, que sirven copias con licencia abierta y nada más; y un libro pedido por su hash de catálogo, que es el identificador propio de esas bibliotecas, va directo a ellas: el mirror de Library Genesis, luego randombook.org, luego Anna's Archive. get_details añade metadatos de Crossref y OpenLibrary si se le pide, y recurre a Anna's Archive para un hash que el catálogo no tenga. download declara ese orden en su propia descripción, y read lista sus fuentes en su parámetro source, en la ficha de libgen.

La herramienta download de libgen nunca entrega un fichero por HTTP, que es la única forma de llegar a este endpoint: resuelve el identificador que le des y devuelve un enlace a la fuente que tenga el ítem, para que lo descargue tu propio cliente. Su herramienta read sí descarga el fichero, para devolverte el fragmento de texto que pediste, y guarda lo descargado en una caché de la instancia que te atendió. En ambos casos, mcp.jmrp.io no publica catálogo alguno ni pone ningún fichero a disposición de nadie: la transferencia, si la haces, es entre ese tercero y tú.

Lo que hagas con los enlaces que devuelve libgen es responsabilidad tuya, bajo la ley que te sea aplicable. gitlab no hace más que retransmitir llamadas a gitlab.com con la credencial que le des, y no concede ningún derecho más allá del que ya te concede gitlab.com.

Este servicio lo opera desde España una persona física, no una empresa, y no está vinculado a ninguna de las fuentes citadas: solo las consulta, y sus nombres pertenecen a sus dueños.

Las preguntas sobre esta página, y las peticiones de que este host deje de resolver un ítem o una fuente concretos, van a la dirección del security.txt del sitio: mail@jmrp.io

Nada de esto es una licencia sobre nada: lo que este sitio sí te deja reutilizar —sus textos, su código y los dos servidores— se dice en su propia página: Licencia