4PDA MCP

Servidor MCP que expone la versión lofi (texto) del foro 4PDA sin navegador. Usa impit para superar el desafío TLS de Cloudflare.

¿Por qué lofi?

La versión lofi/texto es ~50 veces más pequeña que la página completa y tiene un marcado estable y sencillo: ideal para el consumo con LLM. La versión completa (?act=idx, ?showforum=, ?showtopic=) es muy pesada en JavaScript y está protegida por Cloudflare.

Related MCP server: Reddit MCP Server

Convenciones de URL (descubiertas)

4PDA cambió el punto de entrada de lofi. lofiversion/index.php?index.html ahora devuelve 404. El formato actual es:

• lofiversion/index.php?f{forum_id}.html — una página de foro (subforums + lista de temas)

• lofiversion/index.php?t{topic_id}.html — página 1 del tema

• lofiversion/index.php?t{topic_id}-{offset}.html — página N del tema, paso 20

• index.php?act=idx — índice completo, usado solo para enumerar las categorías principales

La publicación fija de cabecera se repite en todas las páginas del tema; este servidor la descarta a partir de la página ≥ 2.

Herramientas

• list_forums(forum_id?) — categorías principales cuando se omite forum_id; en caso contrario, los subforos (y el resumen de temas) de un foro como lista plana. Devuelve un árbol que el cliente puede anidar.

• list_topics(forum_id) — temas de un foro: id, título, respuestas, is_important.

• list_posts(topic_id, page=1) — publicaciones de una página: autor, fecha, html (con los enlaces internos reescritos a lofi cuando sea posible). La publicación de cabecera se descarta a partir de la página ≥ 2.

Ejecución

pip install -e .
4pda-mcp            # stdio MCP server
# or: mcp run src/fourpda_mcp/server.py

Sin navegador, sin autenticación (contenido público de solo lectura). impit suplanta a Chrome para superar Cloudflare.

Limitación de frecuencia

4PDA protege el endpoint lofi con Cloudflare; no está en caché, por lo que cada solicitud llega al origen y Cloudflare le aplica una limitación. El límite no se ha publicado; se midió de forma empírica (ago. 2026):

El servidor se mantiene muy por debajo del punto de corte aplicando un intervalo mínimo entre solicitudes (FOURPDA_MIN_INTERVAL, por defecto 1.0 — es decir, 1 solicitud/s, un margen de 2× bajo las 2 solicitudes/s seguras). Si aun así se produce un 429, el servidor registra el tiempo de espera de Retry-After y, sin enviar más solicitudes, devuelve una respuesta estructurada rate_limited desde cada llamada:

{"rate_limited": true, "retry_after_seconds": 3600,
 "retry_at_utc": "2026-08-24T23:00:00Z",
 "hint": "4PDA is rate-limiting requests. Retry after 3600s."}

Esto se devuelve como un resultado normal (sin errores), de modo que el agente pueda leer retry_after_seconds y esperar en lugar de golpear un endpoint bloqueado. El tiempo de espera está limitado a una hora para que un Retry-After anómalo no pueda congelar el proceso.