Chaindoc MCP Server (Beta): Turn Claude and ChatGPT Into Your AI Document Employee

Ein MCP-Server ist ein kleines Programm, das KI-Assistenten wie Claude Desktop oder ChatGPT externe Dienste so aufrufen lässt, als wären es eingebaute Werkzeuge. Das Model Context Protocol (MCP) wurde im November 2024 von Anthropic vorgestellt und ist ein offener Standard, um KI-Agenten mit echten Systemen zu verbinden. Statt der KI zu sagen "erkläre, wie Chaindoc funktioniert", sagst du einfach "sende dieses NDA an John zur Unterschrift", und die KI führt das direkt über den MCP-Server aus, ohne Copy-Paste, ohne Logins, ohne Tool-Wechsel.

Chaindoc MCP ist der erste E-Signatur-native MCP-Server, derzeit in privater Beta. Er macht Claude Desktop, ChatGPT (über das OpenAI Apps SDK), Cursor und Zed zur funktionierenden Oberfläche für den gesamten Vertragslebenszyklus: entwerfen, unterzeichnen, prüfen, nachverfolgen. Ehrlich gesagt, wenn du das erste Mal siehst, wie Claude für dich einen Vertrag erstellt und versendet, fühlt sich das fast wie Schummeln an.

Der Wandel ist real. Laut dem Salesforce State of Sales Report 2024 verbringen Vertriebsmitarbeiter nur 28% ihrer Woche aktiv mit Verkaufen; der Rest geht für Verwaltungsarbeit drauf, etwa Vertragserstellung, das Hinterherjagen von Dokumenten und CRM-Updates. KI-Mitarbeiter auf MCP-Basis können den Großteil dieser 72% in Chat-Anweisungen verwandeln. Forschung der Aberdeen Group zeigt, dass Organisationen mit E-Signatur-Workflows Verträge 80% schneller abschließen und 22,6 Angebote pro Mitarbeiter und Monat verarbeiten, gegenüber 10,4 bei manuellen Abläufen. Kombiniere diese Gewinne mit einem KI-Agenten, der die Arbeit Ende-zu-Ende übernimmt, und die Produktivitätsobergrenze steigt deutlich.

Dieser Leitfaden erklärt, was der Chaindoc MCP Server tut, wie er sich von einer klassischen API-Integration unterscheidet, was in der Beta verfügbar ist und wie du Zugang anforderst. Mehr Kontext zu Integrationen findest du auf unserer Seite REST-API für E-Signatur und Dokumentenautomatisierung und in unserem bestehenden Leitfaden CRM-Integration mit Chaindoc und Pipedrive.

Ein KI-Mitarbeiter ist in diesem Kontext kein Chatbot, der einen Menschen vortäuscht. Es ist ein KI-Agent mit einem klar definierten Werkzeugkasten und der Befugnis, ihn in deinem Namen zu nutzen. Das MCP-Protokoll gibt der KI drei Dinge, die ihr vorher fehlten: ein Verzeichnis verfügbarer Werkzeuge (Chaindoc-Operationen wie "Dokument erstellen" oder "Signatur prüfen"), eine strukturierte Aufrufmethode und einen Pfad, um Ergebnisse zurückzulesen, damit sie den nächsten Schritt planen kann.

Überleg dir, wie ein menschlicher Mitarbeiter eine Vertragsaufgabe abwickelt. Du schreibst per E-Mail "sende das NDA an John, kopiere unsere Standard-IP-Klauseln, hak nach, falls er nicht in einer Woche unterschrieben hat". Die Person öffnet Chaindoc, sucht die NDA-Vorlage, füllt sie aus, sendet sie, setzt eine Kalendererinnerung für die Nachverfolgung und prüft den Status zum Stichtag. Jeder dieser Schritte entspricht einem Chaindoc MCP-Werkzeug: `chaindoc_create_document`, `chaindoc_create_signature_request`, `chaindoc_get_status`, `chaindoc_subscribe_webhook`. Der KI-Agent überlegt, welche Werkzeuge in welcher Reihenfolge aufzurufen sind, und passt sich an das an, was jeder Schritt zurückliefert.

Was sich für dich als Menschen ändert:

• Du öffnest keine 14 Browser-Tabs mehr für Vertragsarbeit. Die meisten Vertragsoperationen wandern in eine einzige Chat-Oberfläche.
• Der KI-Agent erledigt das langweilige Mittelstück (Vorlagen ausfüllen, auf Unterschriften achten, Erinnerungen senden), du selbst kommst nur am Anfang (Absicht) und am Ende (Prüfung) ins Spiel.
• Audit-Trails werden stärker, nicht schwächer, denn jede KI-Aktion wird von Chaindoc genauso aufgezeichnet wie eine menschliche Aktion, mit derselben Blockchain-Verankerung, wie in unserem Leitfaden zur Audit-Trail-Compliance beschrieben.

Eine ehrliche Warnung: KI-Agenten machen Fehler. Sie wählen gelegentlich die falsche Vorlage, zählen Unterzeichner falsch oder senden bei mehrdeutigen Anweisungen an die falsche E-Mail. Der MCP-Server gibt vollständige Fehlermeldungen zurück, daher merkt die KI ihre Fehler meist mitten in der Aufgabe. Eine menschliche Prüfung ist bei hochwertigen Verträgen trotzdem empfohlen.

Die meisten frühen MCP-Server verbinden KI-Agenten mit Nur-Lese-Daten: Web durchsuchen, eine Datenbank abfragen, eine Datei lesen. E-Signatur ist anders, denn sie ist der seltene Workflow, in dem der Wert nicht im Abrufen liegt, sondern im Handeln. Die KI erzählt dir nicht nur von einem Vertrag; sie versendet ihn. Das verändert die Produktivitätsrechnung um eine ganze Größenordnung.

Drei Gründe, warum E-Signatur ungewöhnlich gut zu MCP passt:

1. 1.
   Diskrete, klar definierte Aktionen. Vertragsoperationen lassen sich in saubere Primitive zerlegen (erstellen, senden, unterschreiben, prüfen, Status, auflisten). KI-Agenten sind gut darin, das richtige Primitiv für eine Anweisung zu wählen; bei unscharfen mehrstufigen Workflows tun sie sich schwerer. E-Signatur-Operationen sind genau die Art von Aufgabe, die du einer Junior-Mitarbeiterin in einem Satz beschreiben würdest.
2. 2.
   Hohe Audit-Trail-Strenge. Bei den meisten Workflows, die KI-Agenten anfassen, ist die Herkunft schwach belegt. Hat der Agent diese Mail wirklich gesendet? Waren die Daten sauber? Mit Chaindoc landet jede KI-Aktion in einem manipulationssicheren Audit-Trail, der an einer öffentlichen Blockchain verankert ist, demselben Datensatz, den auch ein menschlicher Nutzer hinterlässt. Das macht KI-getriebenes Vertragswesen standardmäßig konform für ESIGN, eIDAS und SOX; siehe unseren Leitfaden zu Audit-Trail und juristischer Beweiskraft.
3. 3.
   Lange Liste von Vertragsvarianten. Ein typisches Unternehmen führt Dutzende Vertragstypen (NDAs, MSAs, SOWs, Lieferantenvereinbarungen, Arbeitsverträge, Subunternehmerverträge). Jeder hat leichte Abweichungen je nach Rechtsraum, Branche und Gegenpartei. KI-Agenten gehen mit dieser Variabilität gut um, weil sie über Vorlagen und Klauseln nachdenken können; regelbasierte Automatisierung kann das nicht.

Für konkrete Vertragsszenarien, in denen Chaindoc MCP gerade in der Beta getestet wird, sieh dir unsere bestehenden Beiträge zum Subunternehmer-NDA für Softwarefirmen, zum W-9-Formular-Leitfaden für Subunternehmer und zur Einstufung freier Mitarbeiter vs. Angestellter an.

Der Chaindoc MCP Server in der Beta stellt sieben Werkzeuge bereit, die den vollständigen Vertragslebenszyklus abdecken. Jedes Werkzeug entspricht einem konkreten Endpunkt der Chaindoc REST API, wobei die MCP-Schicht die Authentifizierung, das Parsen der Antwort und den Fehlerkontext übernimmt, damit der KI-Agent etwas zurückbekommt, mit dem er wirklich arbeiten kann.

Werkzeuge in der Beta

• `chaindoc_create_document` , lädt eine Datei oder Vorlagenvariante hoch und gibt eine Dokument-ID und eine Viewer-URL zurück. Damit erstellt die KI auf Basis von Chat-Anweisungen einen Entwurf aus einer Vorlage.
• `chaindoc_create_signature_request` , sendet ein Dokument zur Unterschrift an einen oder mehrere Unterzeichner, mit optionaler KYC-Prüfung, Unterzeichnungsreihenfolge und Erinnerungsplan.
• `chaindoc_get_status` , liefert den vollständigen Stand einer Signaturanfrage: wer unterschrieben hat, wer noch aussteht, Signatur-URLs für aktive Unterzeichner und den bisherigen Audit-Trail.
• `chaindoc_verify_document` , prüft ein von Chaindoc signiertes Dokument auf Manipulation und gibt das Signaturzertifikat, den Blockchain-Anker und das Integritätsergebnis zurück.
• `chaindoc_list_documents` , paginierte Liste von Dokumenten mit optionalen Filtern (Status, Zeitraum, Unterzeichner-E-Mail). So findet die KI auch bei vager Beschreibung das passende Dokument.
• `chaindoc_get_template` — ruft eine gespeicherte Vorlage samt Variablenschema ab, damit die KI genau weiß, welche Felder auszufüllen sind.
• `chaindoc_subscribe_webhook` — registriert einen Webhook für Statusereignisse und gibt die Webhook-ID und das HMAC-Geheimnis zurück. Wird genutzt, um asynchrone Benachrichtigungen einzurichten, die die KI später abfragen kann.

Was noch nicht in der Beta ist

Werkzeuge zur Rechnungsstellung, KYC-Orchestrierung und Multi-Tenant-OAuth stehen auf der Roadmap (siehe Abschnitt unten). Die aktuelle Beta arbeitet API-Schlüssel-basiert, was für Einzelnutzer und kleine Teams gut funktioniert, aber den OAuth-Fluss pro Nutzer für Multi-Tenant-Produktiveinsatz noch nicht unterstützt.

Wenn du Chaindoc bereits über die REST-API und SDKs integriert hast, ist die Frage berechtigt: Warum eine neue Schicht? Die Antwort: MCP ersetzt die API nicht; es ist eine andere Oberfläche für einen anderen Konsumenten. Klassische API-Integrationen sind für Code geschrieben (ein Backend-Service, ein CRM-Plugin). MCP ist für KI-Agenten geschrieben (Claude, ChatGPT, Cursor).

Sobald der MCP-Server konfiguriert ist (siehe Abschnitt zum Beta-Zugang weiter unten), läuft der Ablauf für dich als Nutzer im Gespräch. Hier ein echtes Beispiel aus dem Beta-Test.

Schritt 1: Claude Desktop öffnen und beschreiben, was du brauchst

Du tippst: "Sende das Subunternehmer-NDA an John Smith unter john@acme.example, Unterzeichnungsfrist nächsten Freitag, kopiere die IP-Abtretungsklausel aus unserer Software-Vorlage."

Schritt 2: Claude überlegt, welche Werkzeuge zu rufen sind

Claude ruft `chaindoc_get_template` auf, um deine Subunternehmer-NDA-Vorlage zu holen, erkennt die Variablenfelder (Name der Gegenpartei, E-Mail, Frist, Rechtsraum) und führt die IP-Abtretungsklausel aus deiner Standardbibliothek ein. Dann ruft es `chaindoc_create_document` mit der ausgefüllten Vorlage auf.

Schritt 3: Claude richtet die Signaturanfrage ein

Claude ruft `chaindoc_create_signature_request` mit Johns E-Mail, der Unterzeichnungsfrist und (optional) KYC-Prüfung auf. Es kommt eine Bestätigung zurück: "Dokument aus Vorlage `Contractor NDA v3` erstellt, an john@acme.example gesendet, Signatur-URL aktiv bis Freitag, 9. Mai, 23:59 UTC."

Schritt 4: Claude registriert einen Status-Webhook

Claude ruft `chaindoc_subscribe_webhook` auf, um auf das Ereignis `signature.completed` zu lauschen. So bekommst du in Claude eine Benachrichtigung, sobald John unterschreibt, ohne dass du selbst pollen musst. Der gesamte Ablauf dauert von deiner ersten Nachricht bis zur live in Johns Posteingang liegenden Signaturanfrage rund 60 Sekunden.

Schritt 5: Verifikation nach Abschluss

Wenn John unterschreibt, feuert der Webhook und Claude meldet das Ergebnis. Du kannst Claude dann bitten, die Signatur zu prüfen, und es ruft `chaindoc_verify_document` auf, um den Blockchain-Anker, das Signaturzertifikat und den Audit-Trail zu bestätigen. Dieselbe Prüfung, die du manuell unter /verify-document durchführen würdest, nur direkt im Chat, in dem du gestartet bist.

Mal ehrlich: Die Erfahrung variiert je nach KI-Modell. Claude Desktop ist aktuell am rundesten, weil Anthropic MCP gebaut hat. ChatGPT über das Apps SDK funktioniert gut, hat aber etwas mehr Latenz. Cursor und Zed sind super, falls du sowieso im Code-Editor lebst. Das Protokoll ist standardisiert, daher wird sich die Erfahrung über die Clients hinweg mit der Zeit angleichen.

Jede Aktion, die ein KI-Agent über den MCP-Server ausführt, läuft durch dasselbe Chaindoc-Backend, das auch menschliche Aktionen abwickelt. Es gibt keinen Schattenpfad, kein separates Logging, keinen "KI-Bypass"-Modus. Der Audit-Trail erfasst dieselben sieben Pflichtfelder, die in unserem Leitfaden zur Audit-Trail-Compliance beschrieben sind, mit einer Ergänzung: Die Sitzung des KI-Agenten wird markiert, sodass du sehen kannst, welche Aktionen KI-initiiert versus menschlich initiiert sind.

Konkret bedeutet das:

• Identität: Der API-Schlüssel (in der Beta) oder das OAuth-Nutzer-Token (bei GA) identifiziert das menschliche Konto, in dessen Auftrag die KI handelt. Jede Aktion ist auf eine reale Person rückführbar, nicht auf eine generische "KI-Agent"-Identität.
• Authentifizierung: API-Schlüssel können scoped werden (nur lesen, schreiben, admin), sodass Beta-Nutzer bestimmten KI-Clients minimalen Zugriff erteilen können.
• Aktionsherkunft: Das Audit-Log hält fest, dass die Aktion über MCP kam, plus welcher Client (Claude Desktop, ChatGPT, Cursor usw.) und welches Werkzeug aufgerufen wurde. Wenn also ein Vertrag von Claude in deinem Auftrag versandt wurde, zeigt der Trail "über MCP gesendet, Client: claude-desktop, Werkzeug: chaindoc_create_signature_request, Nutzer: alex@chaindoc.example".
• Manipulationssicherheit: Jeder Audit-Eintrag ist hash-verkettet und an einer öffentlichen Blockchain verankert, exakt wie direkte menschliche Aktionen. KI-getriebene Verträge sind nicht weniger belastbar als manuell versandte; in mancher Hinsicht sogar belastbarer, weil der strukturierte Werkzeugaufruf neben der menschlichen Chat-Anweisung erhalten bleibt.

Für die zugrunde liegenden Compliance-Rahmen siehe unseren Beitrag zur Konformität digitaler Signaturen mit eIDAS, GDPR und NIST und zur rechtlichen Belastbarkeit von Blockchain-E-Signaturen. Für teamweite Zugriffskontrollen, die regeln, wer KI-Clients mit deinem Konto verbinden darf, siehe /team-management.

Stand Mai 2026 hat kein großer E-Signatur-Anbieter einen öffentlichen MCP-Server gestartet. Am nächsten kommen KI-Feature-Ankündigungen innerhalb bestehender Produkte (Docusign IAM und Docusign AI, die KI-Prüfwerkzeuge von Ironclad), aber keiner stellt diese Fähigkeiten externen KI-Agenten über einen offenen Standard bereit. Die folgende Tabelle fasst das Feld zusammen.

Die Beta läuft auf Einladung mit begrenzten Plätzen, bevorzugt für aktive Chaindoc-Kunden und entwicklerlastige Organisationen. Beta-Teilnehmer erhalten kostenlosen Zugang bis zur allgemeinen Verfügbarkeit, dedizierten Slack-Support direkt vom Engineering-Team und eine direkte Linie für Feature-Wünsche.

Drei Wege, Zugang zu beantragen

1. 1.
   Bestehende Kunden: Logge dich in dein Chaindoc-Dashboard ein und suche unter Einstellungen den Bereich "AI Agents". Dort befindet sich der Beta-Schalter.
2. 2.
   Neue Interessenten: Melde dich über /api-integration an und kreuze auf dem Entwickler-Onboarding-Formular die Option "MCP beta" an.
3. 3.
   Direkte Anfrage: Schreibe eine E-Mail an beta@chaindoc.io mit deinem Anwendungsfall (1-2 Sätze), Teamgröße und gewünschtem KI-Client (Claude Desktop, ChatGPT, Cursor, Zed). Wir antworten innerhalb von zwei Geschäftstagen.

Installation, sobald du Zugang hast

Die Beta wird als npm-Paket ausgeliefert. Nachdem du deinen API-Schlüssel erhalten hast, füge Folgendes zu deiner Claude Desktop-Konfiguration hinzu (`~/Library/Application Support/Claude/claude_desktop_config.json` unter macOS, entsprechende Pfade unter Windows und Linux):

Starte Claude Desktop neu. Das 🔌-Symbol sollte "chaindoc" mit sieben verfügbaren Werkzeugen verbunden zeigen. Der erste Werkzeugaufruf dauert üblicherweise 2-3 Sekunden.

Für Cursor, Zed und Windsurf ist die Konfiguration ähnlich; die vollständige Anleitung kommt mit deiner Beta-Einladung. Die ChatGPT-Unterstützung über das OpenAI Apps SDK befindet sich in privater Erprobung und wird ausgerollt, sobald Claude Desktop GA erreicht.

Die aktuelle Beta deckt Vertragserstellung, Unterzeichnung, Verifikation und Nachverfolgung ab. Drei Funktionen sind in aktiver Entwicklung für spätere Beta-Phasen und die allgemeine Verfügbarkeit:

Rechnungsautomatisierung

Ein Werkzeug `chaindoc_create_invoice`, das eine Rechnung erzeugt, die an einen unterzeichneten Vertrag gebunden ist, mit Zahlungsbedingungen, Positionen und Stripe- oder Überweisungsanweisungen. Das Werkzeug liest den Zahlungsplan des Vertrags, erstellt die Rechnung am richtigen Datum und versendet sie (optional) über den bestehenden Chaindoc-Audit-Trail. Siehe unseren bestehenden Beitrag zur vertragsgebundenen Zahlungs- und Abrechnungsautomatisierung für den menschlichen Workflow, auf dem das aufbaut, plus den Tiefgang zur Abrechnungsautomatisierung nach E-Signatur.

KYC-Orchestrierung

Ein Werkzeug `chaindoc_request_kyc`, das eine Identitätsprüfung für einen Unterzeichner auslöst, bevor dieser unterschreibt. Der KI-Agent kann überlegen, welche Unterzeichner volle KYC brauchen (hochwertige Verträge, regulierte Branchen) und welche eine leichte Prüfung (Standard-NDAs), und konfiguriert die Signaturanfrage entsprechend. Aktuell wird KYC auf Anfrageebene von Menschen konfiguriert; das Ziel ist, der KI diese Entscheidung zu überlassen.

Multi-Agent-Workflows

Weiter in der Zukunft erlaubt MCP die Kommunikation zwischen Agenten. Ein Chaindoc MCP-Server kann also einen CRM MCP-Server (HubSpot, Salesforce), einen Kalender MCP-Server (Google, Outlook) oder einen Zahlungs-MCP-Server (Stripe) anrufen. Ein unterschriebener Vertrag kann ein CRM-Update, eine Kalendererinnerung und eine Rechnungsstellung auslösen, alles vom KI-Agenten koordiniert statt von hartcodierten Webhooks. Diese Architektur macht aus KI mehr als ein Schreibwerkzeug, sie wird zu einer echten Operations-Schicht.

KI-Funktionen, die auf bestehende Produkte aufgesetzt werden, gibt es derzeit überall. Automatische Klauselentwürfe, smartes Redlining, Vertrags-Review-Zusammenfassungen: Jeder Altanbieter liefert das. Das ist nützlich, aber es sind Features. Sie leben in der Oberfläche des jeweiligen Anbieters und brauchen einen menschlichen Nutzer, der den Workflow treibt.

KI-native E-Signatur ist strukturell anders. Die Werteinheit ist nicht "was kann unser Produkt für dich tun", sondern "was kann dein KI-Agent in deinem Auftrag tun, egal wo er lebt" (Claude Desktop, ChatGPT, Cursor, dein eigener Custom-Client). Das verändert die Kaufkriterien. Geschwindigkeit der Vertragsausführung wird nicht mehr in Minuten pro Unterschrift gemessen, sondern in Chat-Anweisungen pro Ergebnis. Audit-Trails sind nicht mehr nur ein defensives Compliance-Feature, sondern eine Voraussetzung dafür, KI-getriebenen Workflows überhaupt zu vertrauen.

Chaindoc setzt früh darauf, dass diese Kategorie in den nächsten 24 Monaten dominieren wird. Der MCP-Server ist der erste konkrete Schritt. Wenn du Bestandskunde bist, findest du den Beta-Schalter jetzt in deinem Dashboard. Wenn du E-Signatur-Werkzeuge mit KI auf der Roadmap evaluierst, fordere Beta-Zugang über /api-integration an und sag uns, welchen KI-Client du anbinden möchtest.