Conspiracy Wiki — Tiered MCP Project

El mismo patrón que el proyecto de grafo de conocimiento personal (vault → db → MCP), aplicado a una wiki de teorías conspirativas de 200 entradas, dividida en 3 niveles de acceso y expuesta mediante 3 servidores MCP desplegables por separado.

Definición de niveles

Nota de alcance: las conspiraciones basadas en discurso de odio (tropos antisemitas, negación del Holocausto, "gran reemplazo", etc.) y cualquier cosa que pueda leerse como una llamada a la violencia se excluyen en todos los niveles — esa línea no se mueve independientemente de lo "oscuro" que se suponga que es un nivel.

Related MCP server: wiki-loop-mcp

Matriz de acceso (acumulativa, según especificación)

El mismo código base (mcp/server.py) para los tres — solo cambia la variable de entorno MAX_TIER. Cada uno tiene su propio filtro SQL, por lo que un despliegue MCP-3 literalmente no puede consultar filas de nivel 1; no es solo que estén ocultas en la interfaz.

Archivos

• mcp/data.py — las 200 teorías seleccionadas con título/resumen/nivel/categoría

• db/schema.sql — esquema de Postgres (tabla theories + columna de búsqueda tsvector generada)

• mcp/build_db_postgres.py — carga las 200 teorías en una base de datos Postgres (variable de entorno DATABASE_URL)

• mcp/server_postgres.py — el servidor FastMCP por niveles, respaldado por Postgres (4 herramientas: list_theories, search_theories, get_theory, tier_info)

• vault/*.md — 200 notas de estilo Obsidian, una por teoría (aún se generan localmente mediante mcp/build_db.py si quieres los archivos del vault; la versión SQLite se conserva como server.py/build_db.py por si alguna vez quieres una variante totalmente local/sin conexión)

• Dockerfile — imagen única; los 3 servicios desplegados ejecutan esta imagen y se conectan a la MISMA instancia compartida de Postgres, diferenciándose solo en MAX_TIER

• render.yaml — blueprint de Render: 1 base de datos Postgres gratuita administrada + 3 servicios web

Compilación/prueba local (Postgres)

Requiere una instancia de Postgres — lo más fácil es una gratuita de Neon o Supabase si no quieres instalar Postgres en Windows.

cd conspiracy-wiki-mcp
pip install -r requirements.txt

$env:DATABASE_URL = "postgres://user:pass@host:5432/conspiracy_db"
cd mcp
python build_db_postgres.py    # creates schema + loads 200 rows

$env:MAX_TIER = "1"
python server_postgres.py      # runs on :8000

Despliegue (para que NO sea local — requisito para que la tarea cuente)

Render (recomendado — un blueprint lo hace todo):

1. Sube esta carpeta a un repocitorio de GitHub.

2. En Render: New + → Blueprint → selecciona el repocitorio.

3. Render lee render.yaml y aprovisiona:

   • 1 base de datos Postgres gratuita administrada (conspiracy-db)

   • 3 servicios web, cada uno conectado automáticamente a esa misma base de datos mediante DATABASE_URL, diferenciándose solo en MAX_TIER

4. Cuando la base de datos esté activa, ejecuta el cargador una vez (pestaña Render Shell en cualquiera de los 3 servicios, o desde tu máquina con la cadena de conexión externa de la base de datos):

   $env:DATABASE_URL = "<external connection string from Render dashboard>"
   python mcp/build_db_postgres.py

5. Los 3 servicios sirven ahora la misma base de datos, filtrada por nivel. Copia las 3 URL públicas del panel de Render.

Alternativa con Fly.io: usa Fly Postgres (fly postgres create) para la base de datos compartida y luego fly deploy en cada una de las 3 apps con DATABASE_URL y MAX_TIER configurados por app — la misma idea, otra plataforma.

Una vez desplegado, registra cada URL como su propio conector MCP — la URL de MCP 1 para acceso completo, la de MCP 2 para el nivel intermedio y la de MCP 3 para la demo pública/básica — que es lo que realmente satisface "no local".

Integración con Claude / clientes MCP

Cada URL desplegada es un endpoint MCP estándar de streamable-HTTP — añádela como conector remoto de la misma forma en que añadirías cualquier otro servidor MCP, apuntando a https://<service>.onrender.com (o la URL de tu app en Fly). No se necesita ningún paso de ingesta local — la base de datos ya está integrada en cada contenedor en tiempo de compilación.