> ## 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: Erweiterte Funktionen, Fehlerbehebung & Self-Hosting > Rollen, Berechtigungen, Webhooks, Verzweigungs-Workflows, Troubleshooting und Self-Hosting für den Didit MCP-Server. ## 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](https://docs.didit.me/de/integration/mcp/tools.md) 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`: | Modus | Verhalten | | - | - | | `shadow` (Standard) | Jedes Tool wird aufgeführt; ein Aufruf, den Ihre Rolle nicht ausführen kann, geht an das Backend, das mit `403` antwortet. Das Ergebnis wird im Audit-Log des Servers protokolliert. | | `enforce` | Tools, die Ihre Rolle nicht ausführen kann, werden in `tools/list` ausgelassen; der Aufruf eines solchen Tools gibt einen `missing_scope`-Fehler zurück, der die Berechtigung benennt. | | `off` | Keine Vorabprüfung. | 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. > [!NOTE] > > **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": "" }` – 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](https://docs.didit.me/de/management-api/workflows/create.md) 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](https://docs.didit.me/de/management-api/workflows/create.md#verzweigung-nach-dem-grund-warum-nfc-nicht-ausgeführt-wurde) 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: `{ "": { "": { "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: | Sie können übergeben | Normalisiert zu | | - | - | | Ein Dokumenttyp-Array – `["PASSPORT"]` | dieses Dokument für **jedes** Land (weltweit nur Reisepass) | | Dokument-**Namen** oder -**Codes** – `PASSPORT`/`P`, `NATIONAL_ID`/`ID`, `DRIVER_LICENSE`/`DL`, `RESIDENCE_PERMIT`/`RP` (auch `SSC`, `HIC`, `TC`) | der kanonische Code | | Ein Länderschlüssel `"ALL"` – `{ "ALL": { "P": 1 } }` | auf jedes Land angewendet | | Skalare Flags – `{ "ESP": { "P": 1 } }` | `{ "ESP": { "P": { "enabled": 1 } } }` | | Vollständig weggelassen | alle Dokumente, alle Länder | 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-`config`s 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](https://docs.didit.me/de/reference/data-models.md) und [Verifizierungsstatus](https://docs.didit.me/de/integration/verification-statuses.md). *** ## 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](https://docs.didit.me/de/integration/webhooks.md). *** ## Transport und Endpoints | Endpoint | Zweck | | - | - | | `POST https://mcp.didit.me/mcp` | Der MCP-Endpoint (Streamable HTTP). `GET` und `DELETE` antworten mit `405`: Der Server ist zustandslos, erstellt pro Anfrage eine neue Serverinstanz und hält keinen vom Server initiierten Stream oder keine Sitzung aufrecht, die beendet werden müsste. | | `GET https://mcp.didit.me/healthz` | Health-Check: `{ "status": "ok", "service": "didit-mcp-server", "version": "5.1.1" }`. | | `GET https://mcp.didit.me/.well-known/oauth-protected-resource/mcp` | RFC-9728-Metadaten für geschützte Ressourcen (auch im Root des Origin bereitgestellt). | 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 > [accordion] Der Agent ruft ein Tool auf und erhält einen 403-Fehler oder missing\_scope > > 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.) > [accordion] Ein Schreib- oder Löschvorgang wurde nicht ausgeführt > > 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. > [accordion] 'organization\_id is required' oder keine Ergebnisse > > 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`. > [accordion] Der Browser hat sich für die Anmeldung nicht geöffnet (gehostet) > > 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. > [accordion] Tools erscheinen nicht im Client > > 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. > [accordion] VS Code (oder ein anderer Client) kann OAuth nicht ermitteln / öffnet niemals einen Browser > > 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](#self-hosting). > [accordion] Ein Datei-Upload wird abgelehnt > > 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](https://docs.didit.me/de/integration/sandbox-testing.md). * 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](https://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](https://docs.didit.me/de/integration/mcp/installation.md#self-hosting). ```bash theme={null} git clone https://github.com/didit-protocol/mcp.git && cd mcp # Docker (recommended) — serves /mcp + /healthz on port 3000 docker build -t didit-mcp . && docker run -p 3000:3000 --env-file .env didit-mcp # …or with Node npm install && npm run build node dist/http.js # hosted HTTP/OAuth DIDIT_ACCESS_TOKEN= node dist/index.js # stdio (headless) ``` ### Umgebungsvariablen | Variable | Modus | Zweck | | - | - | - | | `DIDIT_ACCESS_TOKEN` | stdio | Das Bearer-Zugriffstoken des Benutzers für Headless-Ausführungen. | | `DIDIT_API_BASE_URL` | beide | Basis der Verifizierungs-API (Standard `https://verification.didit.me/v3`). | | `DIDIT_AUTH_BASE_URL` | beide | Basis der Authentifizierungs-API (Standard `https://apx.didit.me/auth/v2`). | | `MCP_PORT` | gehostet | HTTP-Listen-Port (Standard `3000`). | | `MCP_RESOURCE_URI` | gehostet | Öffentliche URL des Transports, einschließlich Pfad (zum Beispiel `https://mcp.example.com/mcp`). Die RFC 9728-Metadaten-URL wird daraus abgeleitet. | | `MCP_AUTHORIZATION_SERVER_ORIGIN` | gehostet | Origin des Autorisierungsservers (Standard `https://business.didit.me`). | | `MCP_TOKEN_VERIFY_MODE` | gehostet | `introspection` (Standard; opake Tokens) oder `jwks` (JWT-Zugriffstokens). | | `MCP_OAUTH_INTROSPECT_URL` | gehostet | RFC 7662-Introspection-Endpoint. | | `MCP_OAUTH_CLIENT_ID` / `MCP_OAUTH_CLIENT_SECRET` | gehostet | Basic-Auth-Zugangsdaten, die der Ressourcenserver zum Aufrufen der Introspection verwendet. Stellen Sie diese über einen Secret Manager bereit. | | `MCP_SCOPES_SUPPORTED` | gehostet | In den Metadaten angekündigte Scopes (Standard `didit:management didit:verification`). | | `MCP_DEFAULT_ORG` / `MCP_DEFAULT_APP` | beide | Den Scope für Single-Tenant-Bereitstellungen automatisch ausfüllen. | | `DIDIT_AUTH_ISSUER`, `DIDIT_OIDC_DISCOVERY_URL`, `DIDIT_OIDC_AUTHORIZE_URL`, `DIDIT_OIDC_TOKEN_URL`, `DIDIT_OIDC_REGISTRATION_URL` | gehostet | Überschreibungen für die Metadaten des Autorisierungsservers; nur erforderlich, wenn dieser seine Endpoints an einer anderen Stelle als unter den Standardwerten des Origins veröffentlicht. | | `DIDIT_JWKS_URL` | gehostet | Verwendetes JWKS, wenn `MCP_TOKEN_VERIFY_MODE=jwks`. | | `MCP_PERMISSION_MODE` | beide | Vorabprüfung der Berechtigungen pro Tool: `shadow` (Standard), `enforce` oder `off`. | | `MCP_JSON_BODY_LIMIT` | gehostet | JSON-RPC-Body-Limit (Standard `25mb`). | `.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. *** > [card] [Tool-Referenz](https://docs.didit.me/de/integration/mcp/tools.md) > > Jedes Tool, gruppiert nach Bereich. > [card] [Beispiele](https://docs.didit.me/de/integration/mcp/examples.md) > > Prompts und End-to-End-Konversationen. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.