Der Identitätsprüfungs-MCP-Server für Claude

Wichtigste Erkenntnisse

• Ein Identitätsprüfungs-Model Context Protocol (MCP)-Server gibt Claude typisierte Tools für reale Identitäts- und Betrugsoperationen; er fordert das Modell nicht auf, ein Verifizierungsergebnis zu erfinden.
• Didits gehosteter Server stellt 115 Tools unter https://mcp.didit.me/mcp über zustandsloses, POST-only Streamable HTTP (Hypertext Transfer Protocol) bereit.
• Der Zugriff erfolgt über OAuth (Open Authorization) 2.1 mit PKCE (Proof Key for Code Exchange) und Dynamic Client Registration. Für den gehosteten Server gibt es keinen API-Schlüsselmodus (Application Programming Interface).
• Der Server agiert als angemeldeter Benutzer unter didit:management und didit:verification; bestehende Organisationsrollen definieren weiterhin, was Claude tun darf.
• Bekannte Zugangsdaten-tragende Antworten werden redigiert und Fehler-Payloads bereinigt. Tool-Annotationen klassifizieren Lese-, Schreib- und destruktives Verhalten; Wildcard-Löschungen verfügen über eine handlerseitige Bestätigungsprüfung, aber das aktuell beworbene Schema macht dieses Bestätigungsfeld nicht zugänglich.
• Die MCP-Verbindung ist kostenlos. Die Nutzung unterliegt Didits veröffentlichten Preisen, einschließlich eines vollen Know Your Customer (KYC)-Bundles für 0,33 $ und 500 kostenlosen Verifizierungen pro Monat für jede Funktion.

Wenn Sie einen Identitätsprüfungs-MCP-Server für Claude evaluieren, ist die nützliche Frage nicht, ob Claude einen Endpunkt aufrufen kann. Es geht darum, ob die Verbindung dem Modell der künstlichen Intelligenz (KI) genügend strukturierte Fähigkeiten bietet, um echte Arbeit zu leisten, während Authentifizierung, Autorisierung, Auditierbarkeit und menschliche Kontrolle erhalten bleiben. Hier unterscheiden sich die Implementierungen.

Dieser Leitfaden erklärt dieses Evaluierungsmodell anhand von Didits Claude-Konnektor als konkretes Beispiel. Er wiederholt bewusst nicht die Schritt-für-Schritt-Einrichtung, die im Claude-Installationsleitfaden, die Kategorieübersicht in der MCP-Tool-Referenz oder die Sitzungssequenz im KYC-Sitzungslebenszyklus-Leitfaden behandelt werden. Die kanonischen, aktuellen Schemata befinden sich in der Dokumentation und im öffentlichen Quellcode.

Was ist ein Identitätsprüfungs-MCP-Server?

MCP ist ein Protokoll, um einem Modell Tools zur Verfügung zu stellen. Ein MCP-Server veröffentlicht benannte Operationen mit Beschreibungen und typisierten Eingabeschemata. Ein MCP-Client wie Claude entdeckt diese Operationen, lässt das Modell eine auswählen, validiert seine Argumente und führt das Ergebnis zurück in die Konversation.

Ein Identitätsprüfungs-MCP-Server wendet dieses Muster auf regulierte Identitäts- und Betrugsarbeiten an. Anstatt aus allgemeinem Wissen zu antworten, wenn er aufgefordert wird, einen Kunden zu verifizieren, kann Claude eine echte Verifizierungssitzung erstellen, seine Entscheidung abrufen, eine Screening-Prüfung durchführen oder die konfigurierten Workflows einer Organisation überprüfen. Die zurückgegebenen Daten stammen vom verbundenen Dienst, nicht aus dem Speicher des Modells.

Diese Unterscheidung ist wesentlich. MCP macht ein Sprachmodell nicht zu einer Identitätsbehörde und überträgt die Compliance-Verantwortung nicht auf das Modell. Es gibt dem Modell einen gesteuerten Weg zu dem System, das die Prüfungen durchführt und die Ergebnisse aufzeichnet. Der Verifizierungsanbieter bleibt für den Dienst verantwortlich; der Kunde bleibt für Richtlinien und Überprüfung verantwortlich; Claude koordiniert die erlaubten Operationen.

Eine nützliche Definition: Ein Identitätsprüfungs-MCP-Server ist ein autorisierungsbewusster Adapter, der Identitäts- und Betrugsfunktionen als typisierte Tools bereitstellt, die ein KI-Client entdecken und aufrufen kann.

Was Didits Server innerhalb von Claude ermöglicht

Didit ist eine Infrastruktur für Identität und Betrug. Sein gehosteter MCP-Katalog bietet Claude 115 Tools, die 19 maschinennahe Domänen umfassen. Es geht nicht nur um die Anzahl; es geht um die Bandbreite der Arbeit, die Claude über eine authentifizierte Sitzung hinweg verbinden kann.

Eine normale Interaktion beginnt mit didit_context_get, das die Organisationen und Anwendungen zurückgibt, auf die der Benutzer zugreifen kann. Claude kann dann Tools auswählen, die zur Aufgabe passen:

• didit_session_create erstellt eine Verifizierungssitzung aus einem konfigurierten Workflow, während didit_session_get_decision die resultierende Entscheidung abruft.
• didit_verify_id, didit_verify_passive_liveness und didit_verify_face_match führen gezielte Dokumenten- und Biometrie-Prüfungen durch, wenn die benötigten Bilddateien auf dem Dateisystem des MCP-Servers vorhanden sind.
• didit_verify_aml führt Anti-Geldwäsche (AML)-Screening durch.
• didit_verify_kyb_search und didit_verify_kyb_select unterstützen die Ermittlung und Datenauswahl im Know Your Business (KYB)-Register.
• didit_transaction_create zeichnet überwachte Aktivitäten auf, und didit_transaction_screen_wallet führt Know Your Transaction (KYT)-Wallet-Screening durch.
• didit_case_create eröffnet einen Untersuchungsfall, während didit_case_manage die Zuweisung, Kommentare, Eskalation, Wiedereröffnung, Lösung und Feldaktualisierungen unterstützt.
• didit_workflow_create und didit_workflow_edit_graph ermöglichen autorisierten Benutzern das Erstellen von Verifizierungsabläufen; didit_webhook_create verbindet resultierende Ereignisse mit nachgeschalteten Systemen.

Dies sind Beispiele, kein Ersatz für die kanonische MCP-Tool-Dokumentation. Der aktuelle Server stellt nur Tools bereit: Er veröffentlicht keine MCP-Ressourcen oder Prompt-Vorlagen. Spezialisierte Compliance-Konfigurationen und gesetzliche Meldepflichten bleiben gesteuerte Workflows in der Business Console und sind keine autonomen Chat-Aktionen.

Die Bildgrenze des gehosteten Claude

Fünf Bild-Tools – didit_verify_id, didit_verify_age, didit_verify_face_match, didit_verify_passive_liveness und didit_lists_entry_upload_face – akzeptieren absolute Pfadeingaben, die ihre Handler vom eigenen Dateisystem des MCP-Servers lesen.

Ein in den gehosteten Claude hochgeladenes Bild ist daher diesen Tools normalerweise nicht zugänglich: Der Konnektor bietet kein Tool zur Dateivorbereitung. Ein Bild im Chat zu sehen ist nicht dasselbe wie einen lesbaren front_image_path bereitzustellen. Die Tools sind in lokalen oder selbst gehosteten Bereitstellungen praktisch, wo Dateien auf dem Server-Dateisystem abgelegt werden können.

Für einen echten Antragsteller, der den gehosteten Claude verwendet, nutzen Sie didit_session_create, senden Sie die zurückgegebene url und rufen Sie dann das Ergebnis mit didit_session_get_decision ab. Der Antragsteller erfasst die konfigurierte Evidenz in Didits gehosteter Umgebung; Claude bereitet das Bild nicht vor.

Die zu bewertende Authentifizierungsgrenze

Der gehostete Endpunkt ist https://mcp.didit.me/mcp und verwendet zustandsloses, POST-only Streamable HTTP. Claude verbindet sich über OAuth (Open Authorization) 2.1 mit PKCE (Proof Key for Code Exchange) und Dynamic Client Registration; der gehostete Server hat keinen API-Schlüsselmodus.

Die materielle Sicherheitseigenschaft ist die resultierende Identität. Aufrufe werden als angemeldeter Didit-Benutzer unter didit:verification und didit:management ausgeführt, während die Backend-Rolle der Organisation immer noch bestimmt, welche Operationen erfolgreich sind. Ein Leser wird kein Administrator, nur weil Claude ein Schreib-Tool ausgewählt hat.

Bestätigen Sie für die Bewertung, dass der Zugriff widerrufen werden kann, ohne eine Produktionsanwendungs-Anmeldeinformation zu rotieren, dass Aktionen einem Benutzer zugeordnet bleiben und dass der Kontext mehrerer Organisationen explizit ist. Die genaue Abfolge von Entdeckung, Zustimmung und Einrichtung gehört in den Claude-Installationsleitfaden und die Authentifizierungsdokumentation.

Sicherheit ist mehr als Authentifizierung

Authentifizierung beantwortet, wer anruft. Ein produktionsreifer MCP-Server muss auch kontrollieren, was das Modell sieht und wie riskante Aktionen ablaufen.

Didit kennzeichnet Tools mit Annotierungen für schreibgeschützt, schreiben, destruktiv, idempotent und Open-World. Ein Client kann diese Signale verwenden, um Operationen zu gruppieren oder zu kennzeichnen, aber eine Annotation ist eine beschreibende Metadaten. Sie erzwingt nicht automatisch, dass das Modell oder der Server eine Bestätigung anfordert.

Die Bestätigungsregel ist eng gefasst. didit_session_delete löscht eine Sitzung dauerhaft und erfordert nur die session_id. Begrenzte Batch-Löschungen mit einer expliziten Bezeichnerliste erfordern ebenfalls kein Bestätigungsfeld. Der Handler für eine Wildcard-Löschung lehnt delete_all: true ab, es sei denn, confirm: true wird ebenfalls angegeben, aber das aktuell beworbene Batch-Lösch-Eingabeschema lässt confirm weg. Betrachten Sie dies als einen handlerseitigen Schutz mit einer Schemalücke, nicht als einen vollständigen, für den Client sichtbaren Genehmigungsablauf. Teams sollten ihre eigene Richtlinie für die menschliche Genehmigung bei folgenreichen Schreibvorgängen hinzufügen, anstatt anzunehmen, dass eine Annotation diese erzwingt.

Bekannte Anmeldeinformationen enthaltende Ausgaben werden bewusst behandelt: Anmeldeinformationsfelder von Anwendungen und Signatur-Geheimnis-Metadaten von Webhooks werden redigiert, während Fehler-Payloads vor der Rückgabe an den Client tiefgreifend bereinigt werden. Dies ist keine Garantie dafür, dass jedes Feld in jeder erfolgreichen Geschäftsantwort global entfernt wird, daher sollten Teams immer noch die persönlichen Daten minimieren, die sie Claude abrufen lassen. Die Operation zur Offenlegung von Anmeldeinformationen existiert nur im vollständigen lokalen/stdio-Katalog, erfordert eine eigene Bestätigung und ist vom 115-Tool-gehosteten OAuth-Katalog ausgeschlossen. Die Operation zum Aufladen von Guthaben ist ebenfalls von diesem gehosteten Katalog ausgeschlossen.

Dieses geschichtete Modell ist einer Systemaufforderung vorzuziehen, die einem Agenten lediglich sagt, er solle „vorsichtig sein“, aber seine Grenzen müssen präzise angegeben werden. Backend-Rollen, Eingabevalidierung, gezielte Redaktion, Fehlerbereinigung und die Wildcard-Lösch-Handler-Prüfung sind Erzwingung. Risiko-Annotationen und Chat-Anweisungen informieren das Verhalten, und die aktuelle Schemalücke bei der Wildcard-Bestätigung gehört auf die Checkliste eines Evaluators.

Wie man einen MCP-Server für Identitätsarbeit evaluiert

Bevor Sie einen Identitäts- oder Betrugsdienst mit Claude verbinden, überprüfen Sie Folgendes:

• Transport: Gibt es einen dokumentierten Remote-Endpunkt, der einen aktuellen MCP-Transport verwendet?
• Authentifizierung: Stellt der Zugriff einen Benutzer über OAuth dar, oder hängt er von einer weitgehend privilegierten Anmeldeinformation ab, die in die Konfiguration kopiert wurde?
• Autorisierung: Werden Organisationsrollen vom Backend bei jedem Aufruf durchgesetzt?
• Schemata: Definieren Tools eingeschränkte Eingaben, erlaubte Aktionen und nützliche Fehler?
• Risikometadaten: Kann der Client Lese-, Schreib-, destruktive Operationen und Aufrufe, die externe Systeme betreffen, unterscheiden?
• Datenverarbeitung: Werden Geheimnisse und unnötige persönliche Daten aus Tool-Ergebnissen und Fehlern redigiert?
• Grenzen: Gibt der Anbieter an, was das Modell nicht tun kann und wo eine menschliche Compliance-Prüfung weiterhin erforderlich ist?
• Prüfbarkeit: Kann Ihr Team den Quellcode und eine gepflegte Tool-Referenz überprüfen?

Didit veröffentlicht seine Implementierung im öffentlichen MIT-lizenzierten GitHub-Repository und dokumentiert die Architektur in der MCP-Übersicht und dem Authentifizierungsleitfaden. Die v5-Codebasis ist für die Paketveröffentlichung als privat gekennzeichnet und wird nicht über npm vertrieben. Für Claude ist der vorgesehene Pfad der gehostete Endpunkt und dessen browserbasierter Autorisierungsfluss.

Wann der Claude-Konnektor gut passt

Der Konnektor ist am stärksten, wenn ein Mensch Claude bitten möchte, begrenzte Operationen über einen bestehenden Didit-Arbeitsbereich zu untersuchen, zu koordinieren oder auszuführen: Überprüfen Sie aktuelle Entscheidungen, erstellen Sie einen gehosteten Verifizierungslink, führen Sie nicht-bildbasierte Screenings durch, überprüfen Sie eine Fallwarteschlange, vergleichen Sie Workflows oder fassen Sie Aktivitäten über Anwendungen hinweg zusammen. Er ist auch nützlich für Entwickler, die Schemata erkunden, bevor sie eine Backend-Integration implementieren. Standalone-Bildprüfungen benötigen den oben beschriebenen serverseitigen Dateizugriff.

Er ist kein Ersatz für deterministischen Produktionscode, bei dem Ihre Anwendung bei jeder Anfrage dieselbe Operation ohne einen konversationsbasierten Benutzer auslösen muss. In diesem Fall verwenden Sie Didits Representational State Transfer (REST)-APIs und Software Development Kits. MCP und REST bedienen unterschiedliche Aufrufer: Einer delegiert die Arbeit einer angemeldeten Person an einen KI-Client; der andere verbindet die Anwendungslogik direkt mit dem Dienst.

Die Wirtschaftlichkeit ist dieselbe, egal welche Schnittstelle eine Prüfung initiiert. Der MCP-Server selbst ist kostenlos. Ein vollständiges KYC-Bundle – Identitäts-Dokumentenverifizierung, passive Lebenderkennung, Gesichtsabgleich und Internetprotokoll (IP)-Analyse – kostet 0,33 $. Jede Funktion beinhaltet 500 kostenlose Verifizierungen pro Monat. Didit unterstützt über 2.000 Unternehmen in der Produktion in über 220 Ländern und Gebieten, 14.000+ Dokumententypen und 48+ Sprachen.

Didit mit Claude verbinden

Wenn das Autorisierungs- und Sicherheitsmodell zu Ihrem Anwendungsfall passt, fügen Sie den Didit-Benutzerdefinierter Konnektor zu Claude hinzu. Der Konnektor verweist auf den gehosteten Streamable HTTP-Endpunkt und startet den Didit-Anmeldefluss.

Für exakte Schritte in Claude Desktop und Claude Code verwenden Sie den speziellen Installationsleitfaden. Für Produktkontext und weitere Beispiele besuchen Sie die Didit MCP-Entwicklerseite.

Das prägnante Urteil lautet: Ein Identitätsprüfungs-MCP-Server ist es wert, mit Claude verwendet zu werden, wenn er Identitäts- und Betrugsoperationen in typisierte, berechtigungsbewusste Aktionen umwandelt, ohne die Kontrollen um sie herum zu schwächen. Die Anzahl der Tools macht die Verbindung nützlich; OAuth, Rollendurchsetzung, Redaktion, präzise Schemata und eng gefasste Wildcard-Löschprüfungen machen sein Risikomodell überprüfbar.