Werkzeugreferenz

Alle 26 Certivant-MCP-Werkzeuge, gruppiert nach ihrer Aufgabe — Sichtung der Warteschlange, Versand und Nachverfolgung von Formularen, Lebenszyklusaktionen, Erklärung von Entscheidungen und Netzwerkrisiko, Sitzungen zur Live-ID-Verifizierung, KYB-Registerprüfungen und Berichte — mit dem, was jedes zurückgibt und was es bewusst nicht zurückgibt.

Der Katalog umfasst standardmäßig 26 Werkzeuge, bewusst auf etwa diese Anzahl begrenzt. Darüber hinaus nimmt die Genauigkeit bei der Auswahl der Werkzeuge durch das Modell messbar ab. Daher ersetzt oder bündelt eine neue Fähigkeit bestehende Werkzeuge, statt einfach angehängt zu werden: list_expiring_documents nimmt ein Argument mode entgegen, statt zwei gleichartige Werkzeuge auszuliefern, und die Werkzeuge für die Live-ID-Verifizierung fassen Auflistung und Detailansicht in einem Werkzeug zusammen, während Verschieben, Absagen und erneutes Einladen in einem anderen liegen. Drei weitere Compliance-Werkzeuge existieren hinter Betreiber-Schaltern (siehe Ende dieser Seite).

Jedes Werkzeug ist ehrlich annotiert (readOnlyHint, destructiveHint, idempotentHint), damit Ihr Host diejenigen mit realen Folgen absichern kann. Fünf Werkzeuge versenden tatsächlich E-Mails (oder SMS). Zwei davon sind zerstörerisch. Alle übrigen lesen nur.

send_form_to_customer, send_verification_reminder und renew_verification senden echte E-Mails an Kunden. Keines davon ist idempotent: Ein zweimaliger Aufruf verschickt zwei E-Mails. Schlägt ein Aufruf fehl, prüfen Sie zuerst list_form_deliveries, bevor Sie erneut versuchen, statt blind erneut zu senden.

Den Tag bewältigen

Werkzeug	Gibt zurück	Gibt nicht zurück
`get_todays_queue`	Einen Gesamt-Snapshot für die gesamte Organisation: Anzahl je Status, eskaliert und auf zweite Prüfung wartend, feststeckend (ohne Aktivität seit N Tagen, Standard 7), fehlgeschlagene Sanktionsprüfungen, Eskalationen über der SLA für die Prüfung, fällige Re-KYC sowie Aktivität der letzten 24 Stunden bzw. 7 Tage.	Nur Zählwerte — keine Anfrage-IDs, keine Namen, keine Antragstellerdaten. Verwenden Sie die Listen-Werkzeuge, um mit einer Gruppe zu arbeiten.
`find_verification`	Freitextsuche nach Person, E-Mail-Adresse, Firmenname oder externer Referenz. Eine kompakte Liste zur Unterscheidung — ID, Status, Typ, Entscheidung, Score, Zeitstempel, Tage seit der letzten Aktualisierung — sowie die Anzahl der Treffer, damit eine mehrdeutige Suche sichtbar mehrdeutig bleibt.	E-Mail-Adressen werden standardmäßig nicht zurückgegeben. Namen von Antragstellern kommen innerhalb der nicht vertrauenswürdigen Hülle an.
`list_stalled_verifications`	Nicht abgeschlossene Fälle ohne Aktivität seit N Tagen (Standard 7), jeweils mit `daysWaiting` und den noch ausstehenden `pendingDocTypes`. Die Liste „Wen muss ich nachfassen?“ — diese Fälle warten auf den Antragsteller.	Rückstand auf Prüferseite. Eskalationen und SLA-Verletzungen stehen in `get_todays_queue`. Die Kombination des Filters mit einem Endstatus liefert nichts.
`whats_changed_since`	Schichtübergabe: alles, was seit einem Zeitstempel berührt wurde, das älteste zuerst, gruppiert nach dem aktuellen Status, mit der Angabe, wie lange die Änderung zurückliegt.	Natürlichsprachliche Zeitangaben. `since` muss ein vollständiger ISO-8601-Zeitstempel sein, etwa `2026-07-18T00:00:00.000Z` — ein reines Datum wird abgelehnt.
`get_verification_status`	Eine schlanke Statusdarstellung für eine Anfrage-ID — Status, Zeitstempel, Entscheidung, Gesamtscore. Günstig genug, um regelmäßig abgefragt zu werden.	Unter keiner Einstellung personenbezogene Daten.

Beginnen Sie mit get_todays_queue und gehen Sie dann ins Detail. Rekonstruieren Sie die Warteschlange nicht, indem Sie find_verification in einer Schleife aufrufen — das Ratenlimit je Mandant liegt bei 120 Anfragen pro Minute, und eine Schleife erschöpft es, bevor sie fertig ist.

Arbeit vorantreiben

Werkzeug	Gibt zurück	Hinweise
`start_verification`	Erstellt eine Verifizierung und gibt den Link zurück, den der Antragsteller verwendet, in einem einzigen Aufruf.	Versendet keine E-Mail — der Link kommt zu Ihnen zurück, damit Sie ihn zustellen. Nicht idempotent.
`start_verifications_batch`	Bis zu 50 Zeilen in einem Aufruf. Jede Zeile wird eigenständig geprüft und angelegt; eine fehlerhafte E-Mail-Adresse lässt nur diese Zeile scheitern, erfolgreiche Zeilen werden nicht zurückgerollt. Fehler melden den `index` in Ihrer Liste und den Grund.	Verwenden Sie es statt einer Schleife über `start_verification`. Melden Sie Fehler einzeln — nie als „einige sind fehlgeschlagen“.
`send_form_to_customer`	Versendet eine echte E-Mail. Legt den Antragsteller an, erstellt die Anfrage, erzeugt den persönlichen Link, sendet die Einladung und gibt einen Nachverfolgungs-Verweis für `get_delivery_status` zurück.	Nicht idempotent — zweimal bedeutet zwei Antragsteller, zwei Anfragen, zwei E-Mails. Holen Sie zuerst die Formular-ID über `list_verification_forms`; eine geratene ID führt zu 404.
`send_verification_reminder`	Versendet eine echte E-Mail. Erinnert einen Antragsteller mit einem neuen Link, der dieselbe Anfrage fortsetzt — Status und bereits hochgeladene Dokumente bleiben erhalten.	Nur solange der Fall `PENDING_UPLOAD` oder `DOCUMENTS_READY` ist. Serverseitig gedrosselt — siehe Sicherheit und Grenzen.
`renew_verification`	Versendet eine echte E-Mail. Erstellt eine neue Anfrage für denselben Antragsteller, verknüpft mit der ursprünglichen, die dieselben Dokumente verlangt, und sendet eine Mitteilung zur erneuten Verifizierung.	Die ursprüngliche Anfrage bleibt unverändert. Nicht idempotent — jeder Aufruf ist eine weitere Erneuerung und eine weitere E-Mail. Suchen Sie fällige Fälle zuerst mit `list_expiring_documents` im Modus `renewals`.
`resubmit_verification`	Setzt eine ABGELEHNTE Anfrage zurück auf `PENDING_UPLOAD`, damit der Antragsteller es erneut versuchen kann — die übliche Lösung bei einem unscharfen Foto oder einem abgelaufenen Ausweis.	Zerstörerisch. Es löscht die vorhandenen Prüfungen und den Risiko-Score, sodass `explain_verification_decision` die Ablehnung danach nicht mehr erklären kann. Lesen Sie die Erklärung zuerst. Versendet keine E-Mail.
`list_verification_forms`	Der Katalog, aus dem Sie versenden: ID, Name, Typ (`kyc` = Privatperson, `kyb` = Unternehmen), Status, öffentlicher Slug. Standardmäßig nur veröffentlichte Formulare.	Keinerlei Antragstellerdaten. Ein unveröffentlichtes Formular führt den Empfänger zum allgemeinen Upload-Ablauf statt zu dem Formular, das Sie meinten.
`list_form_deliveries`	Alle, an die ein bestimmtes Formular gesendet wurde, und der jeweilige Stand — `sent`, `started`, `completed`, `bounced`, `failed`. `status: sent` ist die Nachfassliste.	E-Mail-Adressen der Empfänger sind standardmäßig maskiert.
`get_delivery_status`	Der vollständige Lebenszyklus einer Zustellung: gesendet, zugestellt, geöffnet, begonnen, abgeschlossen, wie viele Erinnerungen versandt wurden und wann die letzte gesendet wurde.	Vertrauen Sie `startedAt`/`completedAt` — sie werden serverseitig beobachtet. `openedAt` hängt von der Öffnungsverfolgung im E-Mail-Client ab, die die meisten Clients blockieren; ein leeres `openedAt` ist kein Beleg dafür, dass die Person die E-Mail ignoriert hat.

Eine Entscheidung verstehen

Werkzeug	Gibt zurück	Gibt nicht zurück
`explain_verification_decision`	Die tatsächliche Begründung des Scorers für eine Anfrage: welche Ausschlussgründe der Stufe 1 oder Prüfauslöser der Stufe 2 ausgelöst wurden, welche Bewertungsfaktoren auf welcher Grundlage fehlgeschlagen sind, welche nicht bewertet werden konnten und warum, der Score im Vergleich zum angewandten Schwellenwert, alle ausgelösten Richtlinienregeln, Warnsignale des Netzwerkrisikos mit der Angabe, wie jedes erkannt wurde, und eine schriftliche Zusammenfassung des Falls. Außerdem wird markiert, wenn ein menschlicher Prüfer das automatisierte Urteil überstimmt hat.	Siehe die Lücke unten — die strukturierte Begründung ist nicht bei jeder Anfrage vorhanden.
`get_verification_result`	Das Ergebnis: Status, Entscheidung, Vertrauensscore, jede ausgeführte Prüfung und ob sie bestanden wurde, eine Zählung bestanden/fehlgeschlagen/nicht zutreffend über die Bewertungsfaktoren, welche Ausschlussgründe oder Prüfauslöser ausgelöst wurden, `redFlags` und eine Zusammenfassung `network` (erkanntes VPN / Proxy / Tor / Rechenzentrum / Relay, wie erkannt, Land und Netzbetreiber der IP-Adresse, ob die Zeitzone des Geräts zur IP passt), welche Dokumente geliefert wurden und was der Antragsteller noch schuldet.	Standardmäßig keine personenbezogenen Daten — kein Name, kein Geburtsdatum, keine Dokumentnummern, keine Adressen und kein OCR-Text. `include_pii: true` erweitert die Antwort um Identitätsfelder, und dies wird protokolliert.

reasoningAvailable: false ist häufig. Die strukturierte Begründung des Scorers (verdictMeta) wird nur bei Verifizierungen erfasst, die seit ihrer Einführung bewertet wurden. Daher kommen viele — in der Praxis die meisten älteren — Anfragen mit reasoningAvailable: false und ohne Aufschlüsselung der Faktoren zurück. Bei einer Stichprobe eines aktiven Mandanten hatte keine der 12 ältesten Anfragen sie, und nur 5 der 12 neuesten. Wenn Sie dies sehen, beschreiben Sie, was Status und Prüfungen zeigen, und sagen Sie, dass die Begründung nicht erfasst wurde. Leiten Sie nicht ab, warum der Scorer entschieden hat.

Netzwerkrisiko

Die Verbindung jeder Verifizierung wird durch die eigene Erkennung von Certivant geprüft — ohne Drittanbieter — auf Tor-, VPN-, Proxy-, Hosting-/Rechenzentrums- und Datenschutz-Relay-Netzwerke. Beide oben genannten Werkzeuge melden dies als redFlags sowie als Objekt network:

detected — die gefundenen Arten; detections — jeweils mit ihrer Quelle (eine täglich aktualisierte IP-Liste, der Name des Betreibers, ein WebRTC- oder DNS-Leck, eine IP, die von vielen Antragstellern geteilt wird, oder eine Browser-Antwortzeit, die deutlich länger ist als am Edge gemessen).
ipCountry, networkOperator, deviceTimezoneMatchesIp, ipToGpsDistanceKm, likelyRealNetworkCountry.
Niemals die IP-Adresse, den Hostnamen oder die Stadt — das sind personenbezogene Daten.
assessed: false bedeutet nicht geprüft (keine IP-Adresse des Antragstellers, etwa bei per API erstellten Anfragen) — niemals „unauffällig“.

Ein Warnsignal beschreibt die Verbindung, nicht die Person: Datenschutzbewusste und Unternehmensnutzer verwenden VPNs. Jede Organisation legt je Art fest, ob eine Erkennung ablehnt, eskaliert, nur markiert oder ignoriert wird.

Verifizierung per Live-ID

Werkzeug	Gibt zurück	Hinweise
`list_live_verifications`	Ohne `conference_id`: Sitzungen, gefiltert nach Status (`scheduled`, `in_progress`, `completed`, `cancelled` oder `expired` = hat nie stattgefunden), Anfrage, Referenz oder Datumsbereich. Mit `conference_id`: die Details dieser Sitzung — Moderator, ob der Antragsteller beigetreten ist und zugestimmt hat, Sitzungseinstellungen (Datei-Upload durch den Antragsteller, automatische Prüfung eingegangener Dokumente), Entscheidung und Ergebnis, Aufzeichnung und Zertifikat.	Kein Name und keine E-Mail-Adresse des Antragstellers, außer mit `include_pii: true` zusammen mit einer `conference_id` (wird protokolliert).
`schedule_live_verification`	Plant eine Sitzung für eine bestehende Anfrage (`scheduled_for` mit Zeitzone oder `start_now`), optional mit `applicant_file_upload` und `auto_verify_documents`.	Sendet dem Antragsteller eine E-Mail bzw. SMS. Nicht idempotent; eine Anfrage mit einer beitretbaren Sitzung liefert 409. Der einmalige Beitrittslink wird nur im Fließtext zurückgegeben — teilen Sie ihn ausschließlich mit dem Antragsteller.
`manage_live_verification`	`action`: `reschedule` (Teilnehmer werden benachrichtigt), `resend_invitation` (neuer Link, der alte funktioniert nicht mehr) oder `cancel`.	Als zerstörerisch annotiert: Die Absage ist nicht rückgängig zu machen. Bestätigen Sie vor einer Absage oder einer erneuten Einladung.

KYB

Werkzeug	Gibt zurück	Hinweise
`get_business_record`	Was das Unternehmen bei einer UNTERNEHMENS-Anfrage angegeben hat: Firmenname, Registernummer, Land und Gesellschaftsform, KYB-Status, der bevollmächtigte Vertreter und wie er abgeglichen wurde, sowie die angegebenen Geschäftsführer und wirtschaftlich Berechtigten mit Eigentumsanteilen und jede verknüpfte KYC-Anfrage, die einen UBO verifiziert.	Eine reine Lesung dessen, was Certivant gespeichert hat. Es erfolgt kein Abruf beim Register, und es entstehen keine Kosten. Es sagt nicht aus, ob irgendetwas davon zutrifft.
`check_company_registry`	Der Abgleich zwischen dem öffentlichen Unternehmensregister und den Angaben des Unternehmens: welche angegebenen Geschäftsführer das Register nicht führt und welche Registerdirektoren nie angegeben wurden. Der Abgleich ist die Antwort; der Rohdatensatz ist ergänzende Evidenz.	Keine reine Lesung — es erfolgt ein kostenpflichtiger externer Registeraufruf, und bei einer Übereinstimmung wird der KYB-Datensatz als `verified` markiert. Einmal pro Unternehmen aufrufen, niemals in einer Schleife.
`submit_business_details`	Erfasst die KYB-Angaben eines Unternehmens zu einer bestehenden UNTERNEHMENS-Anfrage — Firmenname, Registernummer, Land und Gesellschaftsform, Geschäftsführer, wirtschaftlich Berechtigte.	Nebenwirkungen über den Datensatz hinaus: Es löst eine Registerabfrage im Hintergrund aus und erstellt für jeden wirtschaftlich Berechtigten mit einem Anteil von 25 % oder mehr eine eigene PRIVATPERSON-Verifizierungsanfrage (die Schwelle der FATF). Rufen Sie es niemals spekulativ auf oder um „einen Tippfehler zu korrigieren“.

Bekannte Einschränkung: check_company_registry schlägt derzeit im Live-Betrieb fehl. Der vorgelagerte Registeraufruf liefert 401, weil der OpenCorporates-API-Schlüssel nicht weitergereicht wird; der Abgleich der Geschäftsführer ist daher gegen einen echten Registertreffer nicht belegt. Bis dies behoben ist, rechnen Sie mit einem Fehler statt einem Abgleich, und bauen Sie keinen Workflow, der auf den Erfolgsfall dieses Werkzeugs angewiesen ist. get_business_record und submit_business_details sind nicht betroffen.

Berichte und Dokumente

Werkzeug	Gibt zurück	Gibt nicht zurück
`get_compliance_metrics`	Die mandantenweite Zusammenfassung: Genehmigungsquote und der vollständige Trichter (eingereicht / ausstehend / in Verarbeitung / genehmigt / abgelehnt / eskaliert), Volumen nach Dokumenttyp, Ergebnisse nach Staatsangehörigkeit, ein täglicher Trend über 30 Tage und Fehlerquoten je Prüfung, die zeigen, welche Prüfung am häufigsten fehlschlägt — OCR, Gesichtsabgleich, Lebenderkennung, Sanktionen.	Keine Liste der Ablehnungsgründe. „Häufigste Ablehnungsgründe“ erzeugt dieses Werkzeug nicht; es liefert Fehlerquoten je Prüfung. Außerdem keine Zeilendaten und überhaupt keine personenbezogenen Daten.
`list_expiring_documents`	Zwei Modi. `documents` (Standard) — Verifizierungen, deren hochgeladene Dokumente innerhalb von N Tagen ablaufen oder veraltet sind (ein Ausweis nach Ablauf oder ein datiertes Nachweisdokument, das älter als das Aktualitätsfenster des Mandanten ist). `renewals` — Verifizierungen, deren eigene periodische Neuprüfung fällig ist (das `expiresAt` der Anfrage), überfällig oder innerhalb von N Tagen fällig.	Dies sind verschiedene Fragen. Ein gültiger Reisepass bei einer Anfrage, deren jährliche Auffrischung fällig ist, erscheint nur unter `renewals`. Führen Sie den Modus aus, nach dem Sie tatsächlich gefragt wurden.
`list_verification_documents`	Nur Metadaten zu jedem Dokument einer Anfrage: Typ (`passport`, `id_card`, `drivers_license`, `selfie`, `business_reg`, `utility_bill`, `bank_statement`), Seite, Verarbeitungsstatus, Dateityp und -größe, Hochladezeitpunkt sowie die eigenen ausgelesenen Daten des Dokuments, einschließlich der Angabe, ob es als abgelaufen gilt.	Kein Bild, kein OCR-Text, keine Dokumentnummer, kein Name, keine Adresse, keine MRZ — der OCR-Block ist strukturell ausgeschlossen und unter keiner Einstellung erhältlich.
`get_document_download_url`	Eine kurzlebige (15 Minuten) signierte URL, damit ein Mensch ein hochgeladenes Dokument ansehen kann, sowie deren Gültigkeitsdauer.	Die Datei wird nicht zurückgegeben, und der Agent darf sie nicht abrufen — ein Ausweisdokument, das in eine Unterhaltung gezogen wird, ist ein in die Protokolle eines Modellanbieters kopierter Passscan. Der Link benötigt keine Zugangsdaten, behandeln Sie ihn daher wie ein Geheimnis: Geben Sie ihn an die Person weiter, die gefragt hat, und hören Sie dann auf.

Gesperrte Compliance-Werkzeuge

Drei Werkzeuge existieren, sind aber standardmäßig deaktiviert. Die Sperre wird bei der Registrierung angewendet; ist das Flag nicht gesetzt, erscheint das Werkzeug überhaupt nicht in tools/list. Jedes benötigt ein eigenes Flag mit dem exakten Wert "true" auf dem MCP-Server und einen API-Schlüssel mit dem Berechtigungsbereich kyc:manage:

Werkzeug	Flag	Was es tut
`decide_verification`	`CERTIVANT_MCP_ALLOW_DECISIONS`	Erfasst eine manuelle Genehmigung bzw. Ablehnung. Eine regulierte Entscheidung in einem Kontext, der vom Antragsteller kontrollierten Text enthält — bewusst aktivieren.
`export_applicant_data`	`CERTIVANT_MCP_ALLOW_EXPORT`	Startet einen Auftrag zum Datenexport nach der DSGVO.
`erase_applicant`	`CERTIVANT_MCP_ALLOW_ERASURE`	Löschung nach der DSGVO — nicht rückgängig zu machen; erfordert die Wiederholung einer Bestätigung.

Was nicht im Katalog enthalten ist

get_fraud_signals, explain_to_applicant, submit_verification — nicht ausgeliefert.
Einstellungen (Schwellenwerte, Maßnahmen bei Netzwerkrisiko, Datenschutzrichtlinie, Rollen) — werden nur im Dashboard verwaltet; der API-Schlüssel des Connectors kann sie nicht lesen.

Werkzeugreferenz

On this page