Dos servidores Model Context Protocol, self-hosted y de uso libre. Apunta tu cliente MCP a un endpoint, o pruébalos en el navegador.
El Model Context Protocol (MCP) es un estándar abierto que permite a los asistentes de IA usar herramientas y fuentes de datos externas; mcp.jmrp.io aloja dos de esos servidores, libgen y gitlab. Lee la especificación en modelcontextprotocol.io.
Ambos servidores hablan streamable HTTP: un POST por llamada JSON-RPC 2.0, sin estado — sin cabecera de sesión — respondiendo JSON o un stream SSE según tu cabecera Accept (application/json, text/event-stream). Ninguno de los dos endpoints sirve una página ante un GET normal: libgen rechaza el método con un 405 y gitlab comprueba antes las credenciales, así que responde 401.
No requiere cuenta. Búsqueda, lectura y enlaces de descarga de libros y artículos en arXiv, Crossref, OpenLibrary, Gutenberg, PubMed y Library Genesis.
Ninguna de las dos. libgen no pide credencial alguna: ni cuenta aquí, ni clave de API, ni registro por fuente. Todas las que consulta son abiertas o públicas y ninguna exige alta previa, y por eso el endpoint acepta una llamada de cualquiera que pueda alcanzarlo.
Los únicos techos son los que se describen abajo, que existen para gastar despacio la capacidad de terceros y para que cada instancia siga respondiendo, no para ponerte un cupo.
¿Dónde busca libgen y cuál es su postura legal?
libgen es un cliente de índices públicos de terceros: consulta proveedores de acceso abierto (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) y fuentes de bibliotecas en la sombra — un mirror de Library Genesis, Anna's Archive, Sci-Hub, SciDB y randombook.org. No aloja catálogo alguno ni almacena o redistribuye contenido propio — `download` devuelve un enlace a la fuente, no sirve el fichero.
Lo que hagas con esos enlaces es responsabilidad tuya, y las normas aplicables dependen de dónde estés.
¿Qué límites de peticiones y disponibilidad tiene libgen?
libgen en mcp.jmrp.io es un servicio personal, ofrecido tal cual y sin SLA. Puede cambiar o desaparecer sin aviso, así que no montes nada crítico encima — levanta tu propia instancia: el servidor es open source y un único binario estático.
Sus consultas al catálogo y todas las descargas comparten un limitador por instancia, de unas 2 peticiones por segundo (hay 3 instancias, así que unas 6 por segundo en total). Las fuentes de acceso abierto que también consulta —arXiv, Crossref, PubMed y las demás— van cada una a su propio ritmo, el que esa fuente pide a sus clientes. OpenAlex mide por dirección y no por persona, así que todos los que usan este endpoint comparten su cuota diaria: sus resultados de búsqueda, y las obras que cita un registro o que lo citan, pueden agotarse antes aquí que en un servidor propio. Esos techos son deliberadamente bajos: apuntan a servicios de terceros, y correr más gastaría su capacidad, no la nuestra.
Cada dirección puede hacer 60 llamadas por segundo por instancia, en ráfagas de hasta 40, y el listado de tools va en un cubo aparte; una llamada que pase de ahí vuelve como un error que el modelo puede leer para frenar. Cada instancia limita además lo que mantiene abierto: como mucho cuatro llamadas de descarga o lectura por dirección a la vez (64 en toda la instancia), y 2.384 llamadas de cualquier tipo. Pasado el primero, la llamada se rechaza con un mensaje que te pide esperar a que termine una; pasado el segundo, el servidor responde que está ocupado —en el protocolo actual, HTTP 503 con Retry-After: 30— en lugar de ponerla en cola.
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.
POSThttps://mcp.jmrp.io/gitlab
v3.4.0 · 3/3 nodes up
Authorization
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.
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 del inspector 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, y el inspector no carga analítica ni ningún script de otro sitio. 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, y una dirección IPv6 por el /64 en el que está. 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; y cuando diez /64 de un mismo /48 IPv6 han tenido un token rechazado en esos diez minutos, se bloquea el /48 entero de la misma forma. Un token que el despliegue ya está sirviendo no se bloquea nunca. Un cliente que reintenta con un token caducado se recupera solo; uno que prueba token tras token, no.
Los documentos que publica sin credencial, las dos server cards y los metadatos OAuth, también van por dirección: 20 peticiones por segundo, en ráfagas de hasta 200.
