Automatisierung und MCP

Was MCP ist

MCP (Model Context Protocol) ist der offene Standard, über den KI-Assistenten wie Claude Werkzeuge aufrufen. euid.com meldet dem Assistenten seine Werkzeuge mit Beschreibung und Eingabefeldern; der Assistent wählt das passende, ruft es auf und liest die Antwort. Sie sagen „prüfe beispiel.at mit 50 Seiten und gib mir die Aufgaben", der Assistent erledigt die Aufrufe. Jedes Werkzeug entspricht einer Funktion des Dienstes; es gibt keinen zweiten Weg an den Regeln vorbei.

Zugang anlegen

• Voraussetzung ist ein Konto als Agentur oder Organisation mit einem Prüfkunden. Registrieren Sie sich unter /registrieren, Art „Agentur" oder „Organisation".
• Der Inhaber legt den Zugang selbst an: Zahnrad der Organisation → MCP-Zugänge (/pruefung/zugaenge), Name vergeben, Rolle wählen. Das Token beginnt mit euid_mcp_ und wird einmal angezeigt; der Dienst speichert nur seinen Abdruck. Verloren heißt: neu anlegen, das alte widerrufen.
• Die Rolle folgt der Kundenart: Agentur → agentur, Organisation → organisation; enger (tester, nur lesen) ist wählbar, weiter nie. Der Sichtbereich ist der eigene Prüfkunde und die direkt betreuten Organisationen; alles andere weist der Dienst vor dem Aufruf ab.
• Nur das Admin-Token des Betreibers sieht alle Prüfkunden. Es wird an niemanden ausgegeben.

Die Rollen

• agentur: prüfen, messen, Stapel, Aufgaben, Listen im eigenen Sichtbereich. Guthaben aufladen, Siegel ausstellen, Optik setzen und Kunden anlegen bleiben dem Betreiber.
• organisation: wie agentur, ohne Stapel (eine Website).
• tester: nur lesen. Stand, Aufgaben, Katalog, Verbesserungsplan, Listen; jeder schreibende Aufruf wird abgewiesen.
• pruefer: eine prüfende Person. Ihr Assistent holt die nächste Seite, liest Befunde und Vorlesetext vor und trägt das Urteil ein; die Gutschrift je Seite ist dieselbe wie in der Fläche. Der Zugang entsteht unter MCP-Zugänge, Abschnitt „Mein Prüfer-Zugang".
• betreiber: alle Werkzeuge. Diese Rolle vergibt der Betreiber nur an eigene Skripte.

Einrichtung in Claude Code

Ein Befehl im Terminal genügt; das Token kommt in die Kopfzeile Authorization.

claude mcp add --transport http euid https://euid.com/api/mcp \
  --header "Authorization: Bearer <IHR-TOKEN>"

Einrichtung je Projekt (.mcp.json)

Für ein Repository, in dem mehrere Personen arbeiten: die Datei .mcp.json im Projektstamm, das Token als Umgebungsvariable.

{
  "mcpServers": {
    "euid": {
      "type": "http",
      "url": "https://euid.com/api/mcp",
      "headers": { "Authorization": "Bearer ${EUID_MCP_TOKEN}" }
    }
  }
}

Einrichtung in Claude Desktop und anderen Assistenten

• Claude Desktop: Einstellungen → Connectors → „Custom connector" → Adresse https://euid.com/api/mcp; das Token als Kopfzeile Authorization: Bearer <IHR-TOKEN>.
• Cursor, Windsurf, Continue und andere Werkzeuge mit MCP-Unterstützung: Servertyp „HTTP" (Streamable HTTP), dieselbe Adresse, dieselbe Kopfzeile.
• Eigene Programme: JSON-RPC 2.0 per POST an https://euid.com/api/mcp mit den Methoden initialize, tools/list und tools/call. Ohne Token antwortet tools/list mit den öffentlichen Werkzeugen (Siegel verifizieren, Preise lesen).

Der übliche Weg einer Prüfung

• pruefservice.kunden.liste: welche Prüfkunden sehe ich? Liefert die Kennungen (UUID) für alle weiteren Aufrufe.
• pruefservice.pruefung.starten: Domain, Prüfkunde, Umfang (Seitenstaffel) und Prüfbereiche. Kostet Guthaben wie im Browser. Mit Warteschlange antwortet der Aufruf sofort mit „eingereiht".
• pruefservice.pruefung.stand: nachfragen, bis fertig. Gemessene Seiten, Punktwerte je Prüfbereich, Berichtsadressen.
• pruefservice.pruefung.todos: das Ergebnis als Aufgabenliste je Prüfbereich und Regel mit Schwere, Fundstellen, Maßnahme und Verweis in die Wissensbasis.
• pruefservice.stapel.starten: viele Domains in einem Aufruf (Rolle agentur). Die Messungen laufen nacheinander, der Stand steht je Domain.

Ein Aufruf ohne Assistent

Dasselbe Werkzeug mit curl. Das Format ist JSON-RPC 2.0, die Antwort kommt als JSON.

curl -s -X POST https://euid.com/api/mcp \
  -H "content-type: application/json" \
  -H "authorization: Bearer $EUID_MCP_TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"pruefservice.pruefung.starten",
        "arguments":{"kundeId":"<uuid>","domain":"beispiel.at","stufe":50}}}'

Die Schnittstelle /api/v1

Wer lieber HTTP-Endpunkte als Werkzeuge ruft, nutzt /api/v1 mit einem Agentur-Token (Kopfzeile Authorization: Bearer oder x-api-key). Der Sichtbereich ist derselbe: die Agentur und ihre direkt betreuten Organisationen. Messen lassen kann nur ein Zugang mit dem Recht „voll", weil Messen Guthaben bewegt.

• GET /api/v1/kunden: betreute Prüfkunden; POST legt einen an (Firma, Domain, Prüfbereiche).
• POST /api/v1/pruefungen: Prüfung starten (kundeId, domain, seiten aus der Staffel, bereiche); GET listet Läufe, GET /api/v1/pruefungen/<runId> liefert den Stand.
• POST /api/v1/stapel: viele Domains; GET zeigt den Fortschritt.
• GET /api/v1/zertifikate: Siegel im Sichtbereich mit Verifikationsadresse.

Was ein Zugang nie tut

• Ein Siegel entsteht nie aus einem Aufruf allein: Es braucht den Domain-Nachweis und den ausdrücklichen Aufruf von pruefservice.zertifikat.ausstellen durch den Betreiber.
• Guthaben entsteht nur über die Kasse; ein Zugang kann es verbrauchen, nie erzeugen.
• Jeder Aufruf steht im Aktivitätslog mit Zugangsname, Werkzeug und Ergebnis. Abgewiesene Aufrufe stehen dort ebenso.
• Ein Token gilt, bis der Betreiber es widerruft; der Widerruf wirkt innerhalb einer Minute.