Conspiracy Wiki — Abgestuftes MCP-Projekt

Gleiches Muster wie beim persönlichen Wissensgraph-Projekt (vault → db → MCP), angewendet auf ein Wiki mit 200 Verschwörungstheorie-Einträgen, aufgeteilt in 3 Zugriffsstufen und bereitgestellt über 3 separat deploybare MCP-Server.

Stufendefinitionen

Anmerkung zum Umfang: Auf Hassrede basierende Verschwörungserzählungen (antisemitische Stereotype, Holocaustleugnung, „Great Replacement“ usw.) und alles, was sich wie ein Aufruf zur Gewalt liest, sind auf jeder Stufe ausgeschlossen — diese Grenze verschiebt sich nicht, egal wie „dunkel“ eine Stufe sein soll.

Related MCP server: wiki-loop-mcp

Zugriffsmatrix (kumulativ, laut Spezifikation)

Dieselbe Codebasis (mcp/server.py) für alle drei — nur die MAX_TIER-Umgebungsvariable unterscheidet sich. Jede Bereitstellung hat ihren eigenen SQL-Filter, sodass ein MCP-3-Deployment Stufe-1-Zeilen schlichtweg nicht abfragen kann; es ist nicht nur in der UI versteckt.

Dateien

• mcp/data.py — die 200 kuratierten Theorien mit Titel/Zusammenfassung/Stufe/Kategorie

• db/schema.sql — Postgres-Schema (theories-Tabelle + generierte tsvector-Suchspalte)

• mcp/build_db_postgres.py — lädt die 200 Theorien in eine Postgres-DB (DATABASE_URL-Umgebungsvariable)

• mcp/server_postgres.py — der gestufte FastMCP-Server mit Postgres-Backend (4 Tools: list_theories, search_theories, get_theory, tier_info)

• vault/*.md — 200 Notizen im Obsidian-Stil, eine pro Theorie (werden weiterhin lokal über mcp/build_db.py generiert, falls du die Vault-Dateien möchtest; die SQLite-Version bleibt als build_db.py erhalten, falls du jemals eine komplett lokale/Offline-Variante möchtest)

• Dockerfile — ein einzelnes Image; alle 3 bereitgestellten Dienste führen dieses Image aus, verbinden sich mit DERSELBEN gemeinsamen Postgres-Instanz und unterscheiden sich nur in MAX_TIER

• render.yaml — Render-Blueprint: 1 verwaltete kostenlose Postgres-DB + 3 Web-Dienste

Lokaler Build/Test (Postgres)

Erfordert eine Postgres-Instanz — am einfachsten ist eine kostenlose Instanz von Neon oder Supabase, falls du Postgres nicht unter Windows installieren möchtest.

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

Deployment (damit es NICHT lokal ist — erforderlich, damit die Aufgabe zählt)

Render (empfohlen — ein Blueprint erledigt alles):

1. Pushe diesen Ordner in ein GitHub-Repository.

2. Auf Render: New + → Blueprint → wähle das Repository aus.

3. Render liest render.yaml und richtet Folgendes ein:

   • 1 verwaltete kostenlose Postgres-DB (conspiracy-db)

   • 3 Web-Dienste, die jeweils über DATABASE_URL automatisch mit derselben DB verbunden sind und sich nur in MAX_TIER unterscheiden

4. Sobald die DB live ist, führe den Loader einmal aus (Render-Shell-Tab auf einem der 3 Dienste oder von deinem Rechner aus mit dem externen Verbindungsstring der DB):

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

5. Alle 3 Dienste bedienen jetzt dieselbe DB, nach Stufe gefiltert. Hol dir die 3 öffentlichen URLs aus dem Render-Dashboard.

Fly.io-Alternative: Verwende Fly Postgres (fly postgres create) für die gemeinsame DB und führe dann bei jeder der 3 Apps fly deploy aus, wobei DATABASE_URL und MAX_TIER pro App gesetzt werden — gleiche Idee, andere Plattform.

Sobald alles bereitgestellt ist, registriere jede URL als eigenen MCP-Connector — die URL von MCP 1 für vollen Zugriff, die von MCP 2 für die mittlere Stufe, die von MCP 3 für die öffentliche/Basis-Demo — genau das erfüllt „nicht lokal“ tatsächlich.

Anbindung an Claude / MCP-Clients

Jede bereitgestellte URL ist ein Standard-Streamable-HTTP-MCP-Endpunkt — füge sie als Remote-Connector hinzu, genau wie du jeden anderen MCP-Server hinzufügen würdest, und zeige dabei auf https://<service>.onrender.com (oder deine Fly-App-URL). Kein lokaler Ingest-Schritt nötig — die DB ist beim Build bereits in jeden Container eingebacken.