# RIB iTWO 4.0 MCP Server

Read-only MCP-Server fuer den Zugriff auf die SQL-Server-Datenbank einer RIB iTWO 4.0 Instanz.

## Tools

- `list_schemas` – alle Schemas auflisten
- `list_tables(schema)` – Tabellen/Views eines Schemas
- `search_tables(keyword)` – Tabellen ueber alle Schemas nach Namen durchsuchen
- `describe_table(schema, table)` – Spalten, Typen, Nullability
- `run_query(sql)` – beliebiges SELECT-Statement (read-only erzwungen)

## Setup

1. **ODBC-Treiber installieren**: [Microsoft ODBC Driver 18 for SQL Server](https://learn.microsoft.com/de-de/sql/connect/odbc/download-odbc-driver-for-sql-server) fuer Windows installieren.

2. **DB-User anlegen**: Auf dem SQL Server einen Login mit `db_datareader`-Rolle (nur lesend) fuer die iTWO-Datenbank anlegen. Server-seitige Rechte sind die eigentliche Absicherung – die Query-Filterung im Server ist nur eine zusaetzliche Schutzschicht.

3. **Abhaengigkeiten installieren**:

   ```powershell
   cd "C:\Users\schol\Desktop\MCP Datenbank"
   python -m venv .venv
   .venv\Scripts\Activate.ps1
   pip install -e .
   ```

4. **Konfiguration**: `.env.example` nach `.env` kopieren und Zugangsdaten eintragen.

   ```powershell
   Copy-Item .env.example .env
   ```

5. **Lokal testen**:

   ```powershell
   python -m rib_itwo_mcp.server
   ```

## Deployment auf Coolify

Der Server laeuft als HTTP-Service (Transport `streamable-http`), damit Claude sich remote verbinden kann. Der ODBC-Treiber steckt im `Dockerfile`, ein DB-Client muss auf dem Coolify-Host selbst **nicht** installiert werden.

1. Repo zu Git pushen (GitHub/GitLab etc.).
2. In Coolify eine neue **Application** aus diesem Repo anlegen, Build-Pack: **Dockerfile**.
3. Umgebungsvariablen in Coolify setzen (aus `.env.example`):
   - `DB_SERVER`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`
   - `DB_DRIVER=ODBC Driver 18 for SQL Server`
   - `DB_TRUST_SERVER_CERTIFICATE=yes` (oder `no`, falls valides Zertifikat)
   - `DB_ALLOWED_SCHEMAS`, `DB_MAX_ROWS` optional
   - `MCP_AUTH_TOKEN` — **Pflicht**, langes zufaelliges Secret (`openssl rand -hex 32`), da der Endpoint sonst offen im Netz erreichbar ist
4. Port `8000` freigeben bzw. Coolify-Proxy/Domain darauf mappen. Der Healthcheck-Pfad ist `/health`.
5. Deployen. Der SQL-Server muss vom Coolify-Host aus per Netzwerk erreichbar sein (Firewall/Security-Group ggf. anpassen, Port 1433).

### Als Connector in Claude hinzufuegen (remote/HTTP)

Sobald die App unter z.B. `https://rib-itwo-mcp.deine-domain.de` erreichbar ist:

```powershell
claude mcp add --transport http rib-itwo https://rib-itwo-mcp.deine-domain.de/mcp --header "Authorization: Bearer <dein-MCP_AUTH_TOKEN>"
```

(In der Claude Desktop/Web-Oberflaeche entsprechend als "Custom Connector" mit URL + Bearer-Token eintragen.)

#### Alternative: Login-Flow statt Bearer-Token

Wenn `MCP_LOGIN_USER`, `MCP_LOGIN_PASSWORD` und `MCP_PUBLIC_URL` gesetzt sind, bietet der
Server stattdessen einen OAuth-2.1-Login-Flow (Authorization Code + PKCE, Dynamic Client
Registration) an. Beim Hinzufuegen als "Custom Connector" in Claude reicht dann die
URL `https://rib-itwo-mcp.deine-domain.de/mcp` allein — Claude oeffnet automatisch eine
vom Server gehostete Login-Seite (Benutzername/Passwort), statt dass ein Bearer-Token
manuell eingetragen werden muss. Es handelt sich dabei **nicht** um ein "Login mit dem
Claude.ai-Account" (das bietet Anthropic fuer fremde Server nicht an), sondern um einen
vom Server selbst betriebenen Login, der lediglich denselben Effekt hat: kein
Copy-Paste eines Tokens mehr noetig.

Der statische `MCP_AUTH_TOKEN` bleibt parallel gueltig, damit z.B. der n8n
MCP-Client-Node (der keinen OAuth-Flow beherrscht) weiterhin per Bearer-Header
funktioniert.

### Lokal als stdio-Connector (Alternative ohne Coolify)

Fuer rein lokale Nutzung ohne HTTP kann `MCP_TRANSPORT=stdio` gesetzt werden:

```powershell
claude mcp add rib-itwo -e MCP_TRANSPORT=stdio -- "C:\Users\schol\Desktop\MCP Datenbank\.venv\Scripts\python.exe" -m rib_itwo_mcp.server
```

## Sicherheit

- `run_query` erlaubt ausschliesslich einzelne `SELECT`/`WITH`-Statements, blockt Mehrfach-Statements sowie schreibende/administrative Keywords.
- Zusaetzlich sollte der DB-User selbst nur Leserechte besitzen (`db_datareader`), damit die Absicherung nicht allein von der Query-Filterung abhaengt.
- Optional laesst sich der Zugriff per `DB_ALLOWED_SCHEMAS` auf bestimmte Schemas einschraenken.
- `DB_MAX_ROWS` begrenzt die Ergebnismenge pro Abfrage.
- Bei HTTP-Deployment (Coolify) ist `MCP_AUTH_TOKEN` die einzige Zugriffssperre vor dem Endpoint — ohne gesetztes Token ist der Server fuer jeden mit Netzwerkzugriff offen. Zusaetzlich TLS ueber den Coolify-Proxy/eine Domain sicherstellen, damit das Token nicht im Klartext uebertragen wird.