> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Didit MCP-Beispiele: Prompts & Agenten-Konversationen

> Beispiel-Prompts und Agenten-Konversationen für Didit MCP: Workflows, Sitzungen, KYB-Unternehmensregister, Prüfungs-Warteschlange und Webhooks.

Einige Muster, die zeigen, wofür das Didit MCP besonders geeignet ist. Formulieren Sie Ihre Anfragen in natürlicher Sprache – der Agent wählt die passenden Tools aus. Jedes unten genannte Tool ist in der [Tools-Referenz](https://docs.didit.me/de/integration/mcp/tools.md) enthalten.

***

## Schnelle Prompts

**Betrieb & Überwachung (App-übergreifend)**

* *„Zeige mir die letzten 5 Sitzungen im Status ‚in Prüfung‘ über alle meine Apps hinweg.“* → `didit_session_search` mit `status: "In Review"`, `limit: 5`
* *„Wie viele Personen haben in den letzten 15 Tagen eine Telefonverifizierung versucht, den Vorgang aber abgebrochen?“* → `didit_analytics` mit `last_n_days: 15` (ein Aufruf; liest den Funktions-Funnel aus)
* *„Finde den Kunden mit den vendor\_data `user_8842` und nenne mir App und Status.“* → `didit_vendor_user_search`
* *„Wie hoch sind mein Credit-Guthaben und die Konversionsrate dieses Monats?“* → `didit_org_get_balance` + `didit_analytics`

**Konfiguration**

* *„Erstelle einen KYC-Workflow mit Ausweisscan + Liveness und gib mir einen Verifizierungslink.“* → `didit_workflow_create` → `didit_session_create`
* *„Erstelle einen Ausweisverifizierungs-Workflow, der nur Reisepässe akzeptiert, gefolgt von einer Liveness-Erkennung per Selfie.“* → `didit_workflow_create` – geben Sie einfach `documents_allowed: ["PASSPORT"]` an; das MCP erweitert dies für jedes Land auf reine Reisepassprüfung (siehe [Erweitert → Funktionskonfigurationen](https://docs.didit.me/de/integration/mcp/advanced.md#funktionskonfigurationen-und-allowlists)).
* *„Neuer Workflow: Reisepass scannen; wenn der Ausweis abgelehnt wird, die Sitzung ablehnen; wenn der angegebene Beruf ≈ ‚Software Engineer‘ ist (≥60%), einen Liveness-Check durchführen; andernfalls einen Adressnachweis auf Spanisch anfordern; anschließend automatisch entscheiden.“* → `didit_workflow_get_field_definitions` → `didit_workflow_validate_graph` → `didit_workflow_set_graph`
* *„Im Workflow `26d33c04…` nach der Ausweisverifizierung: wenn abgelehnt, Sitzung ablehnen; wenn der Beruf zu ≥80% ‚Software Engineer‘ ähnelt, einen Document-AI-Schritt für Kapitalnachweis hinzufügen; dann fortfahren.“* → `didit_workflow_search` → `didit_workflow_get_graph` → `didit_workflow_edit_graph` (kleine Operationen, gespeichert als überprüfbarer Entwurf)
* *„Für welche Länder kann ich einen BankID- oder MitID-Login anstelle eines Dokumentenscans anbieten?“* → `didit_workflow_get_id_verification_methods_catalog`
* *„Registriere ein Webhook-Ziel für Statusaktualisierungen unter `https://myapp.com/webhooks/didit`.“* → `didit_webhook_create`

**Compliance**

* *„Führe ein AML-Screening für diese Wallet durch und setze sie bei Treffern auf die Sperrliste.“* → `didit_transaction_screen_wallet` → `didit_blocklist_add`
* *„Eröffne einen Fall für die Sitzung `…` und weise ihn mir zu.“* → `didit_case_create` → `didit_case_manage`
* *„Ist Acme Ltd ein registriertes Unternehmen im Vereinigten Königreich und wer sind die Gesellschafter?“* → `didit_verify_kyb_search` → `didit_verify_kyb_select`

***

## 1. Verifizierung einrichten

> **Sie:** „Richten Sie die Didit-Identitätsverifizierung für meine App mit Ausweisscan und Liveness ein und geben Sie mir einen Link zum Ausprobieren.“
>
> **Agent:** Ich erstelle zuerst den Workflow. *(ruft `didit_workflow_create` mit `workflow_label: "Standard KYC"`, `features: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]` auf)* – **„Standard KYC“** wurde veröffentlicht, `workflow_id = 6f2c…`. Jetzt eine Sitzung zum Testen. *(ruft `didit_session_create` mit `workflow_id: "6f2c…"`, `vendor_data: "test-user-1"` auf)* – Hier ist Ihr Link: `https://verify.didit.me/session/…`. Öffnen Sie ihn auf Ihrem Smartphone, um den Ablauf auszuführen. In der Produktion erstellt Ihr Backend Sitzungen über die REST-API:
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
>   -H "x-api-key: $DIDIT_API_KEY" \
>   -H "Content-Type: application/json" \
>   -d '{ "workflow_id": "6f2c...", "vendor_data": "internal-user-id", "callback": "https://myapp.com/done" }'
> ```
>
> Dieser `x-api-key` ist der **REST-API-Schlüssel** Ihrer Anwendung für Ihr Backend; er ist unabhängig davon, wie Sie sich bei diesem MCP angemeldet haben, was über *Log in with Didit* erfolgt. Soll ich auch das Webhook-Ziel registrieren?
>
> **Sie:** „Ja – mein Endpoint ist `https://myapp.com/webhooks/didit`.“
>
> **Agent:** *(ruft `didit_webhook_create` mit `label: "Production"`, `url: "https://myapp.com/webhooks/didit"`, `webhook_version: "v3"`, `subscribed_events: ["status.updated"]` auf)* – Erledigt. Das Signaturgeheimnis ist in der Rückgabe maskiert; kopieren Sie es daher aus dem Bereich **Webhooks** in der Konsole und speichern Sie es als `DIDIT_WEBHOOK_SECRET`. Prüfen Sie bei jeder Zustellung den Header `X-Signature-V2`, bevor Sie der Zustellung vertrauen.

***

## 2. KYB: Ein Unternehmen im Register prüfen

> **Sie:** „Ist Acme Trading Ltd ein echtes Unternehmen im Vereinigten Königreich? Ich habe die Registernummer 12345678.“
>
> **Agent:** *(ruft `didit_verify_kyb_search` mit `country_code: "GB"`, `name: "Acme Trading Ltd"`, `registration_number: "12345678"` auf)* – Ein Kandidat: **ACME TRADING LTD**, 2019 eingetragen, Status *aktiv*, eingetragener Sitz in Manchester. Möchten Sie den vollständigen Datensatz mit Organmitgliedern und Gesellschaftern?
>
> **Sie:** „Ja, und sagen Sie mir, wer die wirtschaftlich Berechtigten sind.“
>
> **Agent:** *(ruft `didit_verify_kyb_select` mit der `kyb_response_id` des Kandidaten auf)* – Vollständiger Datensatz abgerufen: zwei Geschäftsführer, eine Person mit maßgeblicher Kontrolle, die 75%+ der Anteile und Stimmrechte hält. Der Datensatz enthält die Einreichungshistorie und die eingetragene Adresse. Dies war eine kostenpflichtige Registerabfrage (zwei Aufrufe, die Credits verbrauchen). Wenn dies für jeden Geschäftskunden automatisch geschehen soll, kann ich mit `didit_workflow_create` `KYB_REGISTRY` zu einem KYB-Workflow hinzufügen; `didit_workflow_get_kyb_registry_catalog` zeigt uns, welche Datenstufen das Register des Vereinigten Königreichs verkauft.

***

## 3. Die Prüfwarteschlange bearbeiten

> **Sie:** „Was wartet auf meine Prüfung und was ist das Problem bei den einzelnen Fällen?“
>
> **Agent:** *(ruft `didit_session_search` mit `status: "In Review"`, `limit: 10` auf)* – Vier Sitzungen über zwei Anwendungen hinweg befinden sich in Prüfung. Liest jede Entscheidung aus. *(ruft `didit_session_get_decision` für jede `session_id` auf)*
>
> | Sitzung | Anwendung | Grund für den Stopp |
> | - | - | - |
> | `a1f3…` | Onboarding | Übereinstimmungswert des Gesichtsabgleichs 71 (Schwellenwert 80), Liveness-Erkennung bestanden |
> | `b7c2…` | Onboarding | Dokument vor 2 Monaten abgelaufen |
> | `c904…` | Marketplace | AML: ein PEP-Treffer, Namensübereinstimmung 92%, abweichendes Geburtsdatum |
> | `d215…` | Marketplace | Adressnachweis älter als 90 Tage |
>
> **Sie:** „Genehmige `a1f3` – Ich habe das Selfie überprüft und es ist dieselbe Person. Lehne `b7c2` ab, abgelaufenes Dokument.“
>
> **Agent:** *(ruft `didit_session_update_status` mit `session_id: "a1f3…"`, `new_status: "Approved"`, dann mit `session_id: "b7c2…"`, `new_status: "Declined"`, `comment: "Expired document"` auf)* – Beide wurden aktualisiert. *(ruft `didit_session_add_review` für `a1f3…` mit der Notiz „Manual selfie review: same person“ auf)* – Prüfungsnotiz hinzugefügt, damit das Audit-Log zeigt, warum der Score überschrieben wurde. Die beiden AML- und Adressnachweis-Fälle sind weiterhin offen; geben Sie einfach Bescheid und ich erstelle mit `didit_case_create` einen Fall für den PEP-Treffer.

***

## 4. Eine Transaktionsregel vor dem Livegang backtesten

> **Sie:** „Ich möchte jeden markieren, der innerhalb einer Stunde mehr als 3 Überweisungen über \$1,000 durchführt. Wie viele Treffer oder Fehlalarme würde das verursachen?“
>
> **Agent:** *(ruft `didit_transaction_rule_backtest` mit `conditions` für `amount > 1000`, einer `aggregation` der Anzahl ≥ 3 über ein 1-Stunden-Fenster und `period_days: 90` auf)* – In den letzten 90 Tagen hätte diese Regel bei 14 Transaktionen von 6 Personen ausgelöst; 2 dieser Personen sind bereits markiert. Soll ich sie im `TEST`-Modus erstellen, damit sie Treffer aufzeichnet, ohne eine Aktion auszuführen?
>
> **Sie:** „Ja, TEST-Modus.“
>
> **Agent:** *(ruft `didit_transaction_rule_create` mit `title: "Velocity: 3+ transfers over $1,000 per hour"`, `category: "aml_ctf"`, `mode: "TEST"`, denselben `conditions` und derselben `aggregation` sowie einer `actions`-Liste auf, die die Person markiert)* – Erstellt. Überwachen Sie die Regel nach einigen Tagen mit `didit_transaction_rule_get`; wenn Sie zufrieden sind, wechselt `didit_transaction_rule_update` den `mode` auf `ACTIVE`. `didit_transaction_rule_library_list` enthält auch Didits vordefinierte Velocity-Regeln, falls Sie lieber eine davon installieren möchten.

***

## Sitzungsergebnisse sind asynchron

`didit_session_create` gibt eine `session_id`, ein `session_token` und eine gehostete `url` zurück – aber die Verifizierung hat noch nicht stattgefunden. Der Benutzer öffnet die `url` und schließt den Ablauf ab. Die endgültige Entscheidung wird über folgende Wege übermittelt:

1. Einen `status.updated`-**Webhook** (empfohlen) oder
2. `didit_session_get_decision` (Polling als Fallback).

Beide verwenden dasselbe Format – **immer als Arrays** mit einer `node_id` pro Eintrag:

```json theme={null}
{
  "session_id": "uuid",
  "status": "Approved",
  "session_kind": "user",
  "id_verifications":  [ { "node_id": "first_id", "status": "Approved", "first_name": "Jane" } ],
  "liveness_checks":   [ { "node_id": "first_liveness", "status": "Approved", "score": 95.4 } ],
  "face_matches":      [ { "node_id": "first_face_match", "status": "Approved", "score": 96.1 } ],
  "aml_screenings":    [ { "node_id": "first_aml", "status": "Approved", "total_hits": 0, "hits": [] } ],
  "reviews": []
}
```

Lesen Sie niemals V2-Schlüssel im Singular (`id_verification`, `liveness`) aus – diese werden nur übermittelt, wenn ein Ziel explizit auf `webhook_version: "V2"` festgelegt ist. Siehe [Datenmodelle](https://docs.didit.me/de/reference/data-models.md) für die feldspezifische Referenz pro Funktion und [Erweitert → Webhooks](https://docs.didit.me/de/integration/mcp/advanced.md#umgang-mit-webhooks) für Verifizierungs- und Wiederholungsregeln.

***

## Mit der Ein-Prompt-Integration kombinieren

Das MCP eignet sich hervorragend für den *Betrieb* von Didit. Damit ein Agent eine vollständige Integration *schreibt* (Backend-Route + Frontend-SDK + Webhook-Handler + DB-Schema), übergeben Sie ihm den [Integrations-Prompt](https://docs.didit.me/de/integration/integration-prompt.md) – er führt durch die sieben Schritte und ruft MCP-Tools auf, um den Workflow, die Sitzung und den Webhook live zu erstellen.

***

> [card] [Tools-Referenz](https://docs.didit.me/de/integration/mcp/tools.md)
>
> Alles, was der Agent aufrufen kann.

> [card] [Erweiterte Themen & Fehlerbehebung](https://docs.didit.me/de/integration/mcp/advanced.md)
>
> Rollen, anwendungsübergreifendes Verhalten, Webhooks, Self-Hosting.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.