Zum Hauptinhalt springen

​
Scopes & Rollenberechtigungen

Der Connector arbeitet unter den Scopes didit:management und didit:verification (ein dritter, didit:staff, wird angegeben, ist jedoch nur für Didit-Mitarbeiterkonten relevant). Beide Grenzen werden bei jedem Aufruf durchgesetzt: Das Token enthält die von Ihnen genehmigten Scopes, und innerhalb dieser entscheidet Ihre Rolle in der Konsole, was Sie tun können. Der effektive Zugriff ist die Schnittmenge, sodass die Genehmigung von nur didit:verification den Management-Bereich selbst für einen OWNER geschlossen hält. Jedes Tool ist einer Backend-Berechtigung zugeordnet (read:sessions, write:workflows, delete:lists usw.; die Tool-Referenz führt diese pro Tool auf). Der Server prüft diese Berechtigung vorab anhand der Organisationsberechtigungen, die von der Token-Introspection zurückgegeben werden, gesteuert durch MCP_PERMISSION_MODE: Das MCP eskaliert niemals über Ihre Rolle hinaus. Ein 403 bei einem Tool bedeutet, dass Ihrer Rolle diese Berechtigung fehlt, nicht, dass die gesamte Verbindung fehlgeschlagen ist.

​
App- und organisationsübergreifende Auflösung

Die Didit-Management-API ist pro Anwendung abgegrenzt (/organization/{org}/application/{app}/…). Das MCP löst diesen Scope für Sie auf:
  • Einzelne Organisation + Anwendung → wird automatisch aufgelöst; Sie übergeben niemals IDs.
  • Mehrere Anwendungen → Die app-übergreifenden Tools (didit_session_search, didit_transaction_search, didit_case_search, didit_vendor_user_search, didit_vendor_business_search, didit_workflow_search, didit_analytics) aggregieren über alle Anwendungen in einem einzigen Aufruf hinweg, wobei jede Zeile mit ihrer organization_id / application_id gekennzeichnet ist.
  • Die anwendungsspezifischen Listen-Tools (didit_session_list, didit_transaction_list, didit_case_list, didit_vendor_user_list, didit_vendor_business_list, didit_workflow_list) umfassen automatisch jede Anwendung, wenn Sie keine angeben, sodass ein einfaches „meine Sitzungen auflisten“ selbst bei vielen Anwendungen funktioniert. Übergeben Sie organization_id + application_id, um auf eine einzelne Anwendung einzugrenzen.
Verwenden Sie didit_context_get, um alle Ihre Organisationen und Anwendungen (sowie deren IDs) in einem einzigen Aufruf anzuzeigen. Es meldet auch den mode jeder Anwendung (live oder sandbox), schließen Sie also niemals anhand des Namens einer Anwendung auf die Umgebung; didit_session_create akzeptiert ein sandbox_scenario bei Sandbox-Anwendungen für nicht abgerechnete Testläufe.

​
Was der gehostete Katalog enthält

Der gehostete Connector bietet Ihnen 169 Tools. Er listet außerdem 17 Investigator-Tools auf, die erst funktionieren, wenn der Investigator für Ihre Organisation aktiviert ist. Zwei weitere Tools, didit_org_top_up (Stripe-Checkout) und didit_org_reveal_application_api_key (API-Schlüssel im Klartext), sind in tools/list für jeden OAuth-authentifizierten Aufrufer ausgeblendet. Die fünf Tools zur Kontoeinrichtung (didit_account_*) sind auf Remote-Servern vollständig ausgeschlossen und verweigern dort die Ausführung, da ein Remote-Connector niemals Anmeldedaten als Tool-Argumente entgegennehmen darf. Ein lokaler stdio-Server behält alle bei, insgesamt 193. Jedes aufgeführte Tool enthält MCP-Annotationen (readOnlyHint, destructiveHint, openWorldHint, einen title) und ein outputSchema sowie ein Label _meta["anthropic/toolGroup"], das seinen Bereich benennt (Sessions, Workflows & Questionnaires, Transactions (AML) usw.). Clients wie Claude verwenden die Annotationen, um die Tools des Connectors in Lese-, Schreib- und destruktive Gruppen zu unterteilen.

​
Verzweigte Workflows

Einfache Workflows sind eine flache Liste von Funktionen. Für konditionale Logik – basierend auf einem Status ablehnen, anhand eines extrahierten Feldes weiterleiten, einen Schritt an eine Übereinstimmung knüpfen, eine Document-AI-Anfrage hinzufügen – steuert das MCP Didits Knotengraphen (dieselbe Struktur wie im visuellen Builder der Konsole). Ein Graph besteht aus { start_node, nodes }; jeder Knoten ist ein feature, branch, status (terminal), action oder webhook. Verzweigungsregeln unterstützen Operatoren einschließlich fuzzy_match (String-Felder mit einem Ähnlichkeitsschwellenwert (score) von 0–100) auf extrahierten Feldern wie kyc.extra_fields.profession, und ein DOCUMENT_AI-Funktionsknoten fordert Dokumente an (z. B. Kapitalnachweis).

​
Einen bestehenden Workflow bearbeiten (empfohlen)

Reale Workflows enthalten umfangreiche Funktionskonfigurationen – eine OCR-documents_allowed-Allowlist kann 150 KB+ groß sein, zuzüglich POA-Listen und Telefon-Länderlisten. Lesen Sie daher nicht den gesamten Graphen aus, um ihn erneut zu senden. Bearbeiten Sie ihn stattdessen mit kleinen Operationen:
1

Finden & überprüfen

didit_workflow_search { workflow_id } findet ihn über alle Ihre Anwendungen hinweg. didit_workflow_get_graph gibt die Struktur mit großen Konfigurationen in zusammengefasster Form zurück (die Ausgabe überschreitet nie das zulässige Limit; übergeben Sie include_config: true für die Rohwerte); didit_workflow_get_field_definitions listet verzweigbare Felder und gültige Operatoren auf.
2

Mit Operationen bearbeiten

didit_workflow_edit_graph nimmt einige kleine Operationen entgegen – set_next, set_node, set_branches, merge_node_config – und das MCP ruft den vollständigen Graphen serverseitig ab, wendet sie an, validiert, erstellt automatisch einen Entwurf und speichert ihn. Ihre Allowlists bleiben Byte für Byte erhalten und werden nie über die Anfrage übertragen. Bei einem Validierungsfehler wird applied: false zurückgegeben (nichts gespeichert).
3

Prüfen & veröffentlichen

Er bleibt ein prüfbarer Entwurf, bis Sie ihn mit publish veröffentlichen (in der Konsole oder über didit_workflow_publish). Die Live-Version wird niemals angetastet.
Um beispielsweise nach der Ausweisverifizierung eine Verzweigung einzufügen, die wieder in Ihre bestehende Pipeline mündet, senden Sie lediglich Folgendes: Leiten Sie das next des OCR-Knotens auf eine neue Verzweigung um und fügen Sie die Verzweigung + einen terminalen Declined-Knoten + einen DOCUMENT_AI-Schritt hinzu (dessen next wieder auf den ursprünglichen nächsten Schritt verweist). Die anderen 10 Knoten – und deren Allowlists – bleiben unberührt.
“Nach der Ausweisverifizierung: falls abgelehnt, ablehnen; falls Beruf ≈ ‘Software Engineer’ (≥80%), Kapitalnachweis anfordern; danach fortfahren.” → ein branch-Knoten: kyc.status == Declined → ein Declined-Statusknoten; kyc.extra_fields.profession fuzzy_match “Software Engineer” Übereinstimmungswert 80 → ein DOCUMENT_AI-Kapitalnachweisknoten → und ein sonst-Pfad zurück in die Pipeline.
Eine Verzweigung benötigt immer ein explizites sonst. Der Standardfall (der Pfad, der gewählt wird, wenn keine Bedingung zutrifft) muss eine Verzweigung mit leeren rules sein – z. B. { "id": "else", "rules": [], "goto": "<liveness>" } – nicht das bloße next des Verzweigungsknotens. Das MCP (und das Backend) konvertieren das next eines Verzweigungsknotens automatisch in eine sonst-Verzweigung, sodass eine Verzweigung niemals als mehrdeutige Kante ohne sichtbares sonst dargestellt wird.
Um einen Workflow von Grund auf neu zu erstellen, verwenden Sie didit_workflow_validate_graph und danach didit_workflow_set_graph (vollständiger Graph), oder lassen Sie didit_workflow_build_graph einen vollständigen Graphen aus einer einfachen Funktionsspezifikation zusammenstellen, ohne zu speichern. Selbst ein einfaches didit_workflow_create wird als derselbe Knotengraph gespeichert – das MCP setzt Ihre features-Liste zu verketteten Funktionsknoten zusammen, die in einem automatischen Entscheidungsstatus enden, sodass die Funktionen tatsächlich ausgeführt werden (es wird standardmäßig veröffentlicht; übergeben Sie status: "draft", um ihn unveröffentlicht zu lassen). Siehe Workflow erstellen → Verzweigte & knotenbasierte Workflows für die vollständige JSON-Struktur.

​
Verzweigungen für NFC-Überspringungsgründe mit MCP

Fragen Sie für einen neuen Graphen:
“Erstelle einen Entwurfs-Workflow mit Ausweisverifizierung, gefolgt von NFC. Wenn nfc.skip_reason gleich DEVICE_WITHOUT_NFC oder DOCUMENT_WITHOUT_CHIP ist, setze die Sitzung auf In Prüfung; genehmige sie andernfalls. Behalte eine explizite sonst-Verzweigung bei und validiere den Graphen vor dem Speichern.”
Der Agent sollte didit_workflow_get_field_definitions, didit_workflow_validate_graph und anschließend didit_workflow_set_graph aufrufen. Für einen bestehenden Workflow fragen Sie:
“Bearbeite Workflow 26d33c04…: Leite nach dessen NFC-Knoten jeden der sieben bekannten nfc.skip_reason-Werte auf In Prüfung weiter und behalte den bestehenden erfolgreichen NFC-Pfad als explizites sonst bei. Speichere einen Entwurf; veröffentliche ihn nicht.”
Der Agent sollte didit_workflow_search, didit_workflow_get_graph, didit_workflow_get_field_definitions und dann didit_workflow_edit_graph aufrufen. Das Bearbeitungstool wendet kleine Operationen serverseitig an, sodass nicht betroffene Knoten und große Allowlists erhalten bleiben. Siehe Workflow erstellen → Verzweigung nach Grund für nicht ausgeführtes NFC für die sieben Werte, equals/in-Regeln, Null-Verhalten und einen vollständigen geordneten Graphen.

​
Funktionskonfigurationen und Allowlists

Die config eines Funktionsknotens schränkt ein, was dieser akzeptiert. didit_workflow_get_feature_config_schema gibt jeden Schlüssel zurück, den jede Funktion akzeptiert, inklusive Typen und Standardwerten, und die beiden Katalog-Tools (didit_workflow_get_id_verification_methods_catalog, didit_workflow_get_kyb_registry_catalog) beantworten die servergesteuerten Fragen, von denen eine Konfiguration abhängt. Die kanonische OCR-Allowlist ist pro Land → pro Dokument → Objekt: { "<ISO3>": { "<CODE>": { "enabled": 1 } } } (z. B. { "ESP": { "P": { "enabled": 1 } } }). Das MCP normalisiert benutzerfreundlichere Formate vor der Validierung für Sie, sodass Sie diese Struktur nicht manuell schreiben müssen: Bei poa_languages_allowed von PROOF_OF_ADDRESS gilt dasselbe Prinzip – übergeben Sie ein Sprach-Array (["es"]) oder eine Map ({ "es": 1 }). Diese Erleichterungen gelten überall dort, wo Sie dem MCP eine Funktionskonfiguration übergeben: bei didit_workflow_create-Funktionen sowie den Knoten-configs in set_graph / edit_graph / validate_graph.

​
Antwortstruktur (V3-Vertrag)

Jedes Tool gibt das unveränderte JSON des zugrunde liegenden REST-Endpoints zurück. Zwei Dinge sollten Sie wissen:
  • Synchrone Tools (Workflows, Abrechnung, eigenständiges verify_*, Listenverwaltung) geben ihr endgültiges Ergebnis direkt (inline) zurück – reagieren Sie im selben Schritt darauf.
  • Die Sitzungserstellung ist asynchron – didit_session_create gibt eine url zurück, die der Benutzer abschließen muss; die Entscheidung wird per Webhook oder didit_session_get_decision übermittelt.
Entscheidungsschlüssel sind immer Plural-Arrays mit einer node_id pro Eintrag (id_verifications[], liveness_checks[], face_matches[], aml_screenings[], poa_verifications[], phone_verifications[], email_verifications[], database_validations[], reviews[] sowie für KYB registry_checks[], document_verifications[], key_people_checks[]). Siehe Datenmodelle und Verifizierungsstatus.

​
Umgang mit Webhooks

Lassen Sie die finale Entscheidung per Webhook an Ihr Backend zustellen, anstatt sie über den Agenten abzufragen:
  1. Der Agent ruft didit_webhook_create einmalig mit einem label, Ihrer öffentlichen HTTPS-url, webhook_version: "v3" und subscribed_events (typischerweise ["status.updated", "data.updated"]) auf. Die Antwort schwärzt das Signaturgeheimnis, ebenso wie didit_webhook_get und didit_webhook_list; kopieren Sie es unter Webhooks in der Konsole und speichern Sie es als DIDIT_WEBHOOK_SECRET.
  2. Ihr Backend prüft den kanonischen X-Signature-V2-Header bei jeder Zustellung: shortenFloats → sortKeys → JSON.stringify (Unicode ohne Escaping) → HMAC-SHA256 → timingSafeEqual. Lehnen Sie ab, wenn abs(now − X-Timestamp) > 300 Sekunden beträgt.
  3. Deduplizieren Sie anhand von event_id. Antworten Sie innerhalb von 5 Sekunden mit 2xx; lagern Sie rechenintensive Aufgaben in eine Warteschlange aus.
  4. Didit unternimmt bei 5xx / 404 bis zu 2 Wiederholungsversuche (~1 Min., dann ~4 Min.) und verwirft die Zustellung anschließend – fehlgeschlagene Zustellungen können Sie im Reiter Zustellungen in der Konsole wiederholen.
Der Agent muss den Empfänger lediglich einrichten; er empfängt selbst keine Events. Vollständiger Vertrag: Webhooks.

​
Transport und Endpoints

Der Endpoint unterstützt zwei Protokollgenerationen: Clients, die bei jeder Nachricht eine Protokollversion ab dem 2026-07-28 festlegen, überspringen den initialize-Handshake und können server/discover aufrufen; alle älteren Clients (Claude Code, Cursor, SDK-basierte Clients) verwenden unverändert den standardmäßigen Streamable-HTTP-Handshake. CORS ist freigegeben, sodass browserbasierte Clients (der Claude-Web-Connector, MCP Inspector) Cross-Origin auf /mcp und die Discovery-Dokumente zugreifen können. Das Limit für den JSON-Body beträgt 25 MB, was für eine 15 MB große Base64-Dateieingabe ausreicht.

​
Fehlerbehebung

Ihrer Rolle in dieser Organisation fehlt die für das Tool erforderliche Berechtigung (z. B. ein READER, der einen Schreibzugriff versucht); der Fehler missing_scope nennt diese. Wenn jedes Tool fehlschlägt, trennen Sie die Verbindung und führen Sie Log in with Didit erneut aus. (Das MCP unterstützt ausschließlich Bearer/OAuth – ein x-api-key wird von jedem Tool abgelehnt, daher behebt ein API-Schlüssel keinen 403-Fehler.)
Destruktive Tools erfordern eine Bestätigung in Ihrem Client. Genehmigen Sie den Aufruf oder prüfen Sie, ob die Bestätigungsaufforderung des Tools nicht automatisch abgelehnt wird. didit_session_delete, didit_session_batch_delete und didit_org_reveal_application_api_key erfordern zusätzlich confirm: true in den Tool-Argumenten; ohne diese Angabe wird der Aufruf abgelehnt, bevor etwas ausgeführt wird.
Sie haben wahrscheinlich mehrere Anwendungen. Verwenden Sie ein *_search-Tool (das alles abdeckt) oder führen Sie didit_context_get aus und übergeben Sie die gewünschte organization_id / application_id.
Einige Clients (Windsurf, Zed) verbinden sich über die mcp-remote-Bridge – stellen Sie sicher, dass npx -y mcp-remote@latest https://mcp.didit.me/mcp in der Konfiguration enthalten ist. Öffnen Sie den Client erneut, um den OAuth-Handshake erneut auszulösen.
Vergewissern Sie sich, dass der Server verbunden ist (die meisten Clients zeigen einen Statuspunkt an) und dass Sie Log in with Didit abgeschlossen haben. Starten Sie den MCP-Host nach dem Bearbeiten seiner Konfiguration neu. didit_org_top_up und didit_org_reveal_application_api_key werden beim gehosteten Connector niemals aufgeführt.
Stellen Sie sicher, dass Sie auf https://mcp.didit.me/mcp verweisen und nicht auf den reinen Origin https://mcp.didit.me – die Ressourcen-Metadaten werden unter /.well-known/oauth-protected-resource/mcp bereitgestellt, beschränkt auf diesen Pfad (mit einer Kopie im Root des Origin für Clients, die dort anfragen). Wenn Sie selbst hosten, bedeutet dies meist, dass MCP_RESOURCE_URI auf den Origin anstelle der vollständigen Transport-URL gesetzt ist; siehe Selbsthosting.
Senden Sie die Datei beim gehosteten Endpoint als *_base64 (reines Base64 oder eine data:-URL); *_path funktioniert nur auf einem lokalen stdio-Server. Dateien sind auf 15 MB begrenzt und müssen vom Inhalt her PNG, JPG, WebP, GIF, BMP, ICO oder PDF sein, nicht nur nach Dateiendung.

​
Sicherheit

Der MCP agiert mit Ihren echten Berechtigungen und kann Live-Ressourcen verändern. Lassen Sie “review tool calls before running” in Ihrem Client aktiviert – insbesondere für Write- und Destructive-Tools. Der MCP selbst speichert kein Geheimnis in Ihrer Konfiguration (er verwendet Mit Didit anmelden), schwärzt API-Schlüssel und Webhook-Signaturgeheimnisse in der Tool-Ausgabe, blendet die Auflade- und Rohschlüssel-Tools im gehosteten Katalog aus und akzeptiert niemals Kontozugangsdaten als Tool-Argumente auf einem Remote-Server. Jeder Tool-Aufruf wird mit dem Aufrufer, dem Tool und der Berechtigungsentscheidung in das Audit-Log des Servers geschrieben.

​
Prompt-Injection

Didit-Tools geben das zurück, was Ihre Benutzer eingegeben oder hochgeladen haben, wie etwa Namen, Dokumententext und Fragebogenantworten. Eine zu verifizierende Person kontrolliert diesen Text, sodass sie Anweisungen an Ihren Agenten in einen Namen oder ein Dokument einfügen kann, und der Server gibt diese Felder genau so zurück, wie sie erfasst wurden. Ein Agent kann diesen Text nicht zuverlässig von Ihren eigenen Anweisungen unterscheiden. Behandeln Sie daher jedes Tool-Ergebnis als Daten:
  • Lassen Sie die Tool-Genehmigung für Write- und Destructive-Tools aktiviert und lesen Sie, was der Agent tun möchte, bevor Sie es genehmigen.
  • Melden Sie sich als Mitglied an, dessen Rolle zur Aufgabe passt. Ein Agent, der nur Sitzungen liest, kann ein READER-Mitglied verwenden, und das Backend verweigert seine Schreibzugriffe unabhängig davon, was der Agent versucht.
  • Testen Sie einen neuen Agenten oder Prompt zuerst in einer Sandbox-Anwendung.
  • Genehmigen oder lehnen Sie eine Verifizierung niemals ab, weil der Text innerhalb dieser Verifizierung dies verlangt. Verlassen Sie sich auf die Entscheidung, deren Warnungen und Ihre eigene Prüfung.

​
Personenbezogene Daten

Tool-Ergebnisse können personenbezogene Daten wie Namen, Geburtsdaten, Dokumentennummern und Links zu Bildern enthalten, und Ihr MCP-Client sendet diese an das von ihm verwendete Modell. Bevor Sie eine Live-Anwendung verbinden, prüfen Sie, ob Ihre Vereinbarung mit Ihrem KI-Anbieter diese Daten abdeckt, oder arbeiten Sie in einer Sandbox-Anwendung.

​
Self-Hosting

Der gehostete Server basiert auf github.com/didit-protocol/mcp (MIT). Klonen Sie ihn und führen Sie ihn mit Docker oder Node aus; er authentifiziert sich bei beiden Transporten immer als Didit-Benutzer (es gibt keinen API-Schlüssel-Modus). Einrichtungsschritte finden Sie unter Installation → Self-Hosting.

​
Umgebungsvariablen

.env.example im Repository ist eine kopierbare Vorlage, und ARCHITECTURE.md erklärt die Trennung von Ressourcenserver und Autorisierungsserver. Beim Start ruft der HTTP-Server das Discovery-Dokument des Autorisierungsservers ab und greift auf die konfigurierten URLs zurück, falls dieser nicht erreichbar ist.

Tool-Referenz

Jedes Tool, gruppiert nach Bereich.

Beispiele

Prompts und End-to-End-Konversationen.
Zuletzt geändert am 7. November 2026