Chaindoc MCP Server: So wird jeder KI-Assistent zum Mitarbeiter für Dokumente

Ein MCP-Server ist ein kleines Programm, das einen KI-Assistenten 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 und allgemein verfügbar. Welcher Assistent auch immer bei dir läuft, er wird zur funktionierenden Oberfläche für den gesamten Vertragslebenszyklus: entwerfen, unterzeichnen, prüfen, nachverfolgen. Ehrlich gesagt, wenn du das erste Mal siehst, wie ein Assistent 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, welche Werkzeuge er bereitstellt und wie du ihn anbindest. 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 eingesetzt 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 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.

Verfügbare Werkzeuge

Authentifizierung

Der Zugang läuft über OAuth 2.0 mit Tokens pro Nutzer, sodass jede Aktion einem namentlichen Konto zuzuordnen ist und Multi-Tenant-Betrieb ohne gemeinsamen Schlüssel funktioniert. Rechnungsstellung und KYC-Orchestrierung sind zusammen mit den Vertragswerkzeugen ausgeliefert.

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, egal welches Modell dahintersteckt.

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: Das OAuth-Nutzer-Token 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: OAuth-Scopes (nur lesen, schreiben, admin) erlauben es, bestimmten KI-Clients minimalen Zugriff zu erteilen.
• Aktionsherkunft: Das Audit-Log hält fest, dass die Aktion über MCP kam, plus welcher Client verbunden war und welches Werkzeug aufgerufen wurde. Wenn also ein Agent in deinem Auftrag einen Vertrag versandt hat, zeigt der Trail "über MCP gesendet, Client: , 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 Verankerung von Signaturen auf einer Blockchain. Für teamweite Zugriffskontrollen, die regeln, wer KI-Clients mit deinem Konto verbinden darf, siehe unsere Team-Verwaltungsseite.

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.

Der MCP-Server steht jedem Chaindoc-Konto offen. Keine Einladung, keine Warteliste. Verbinde ihn im Bereich "AI Agents" unter Einstellungen in deinem Dashboard oder über unsere API-Integrationsseite.

Installation

Der Server kommt als npm-Paket und authentifiziert über OAuth 2.0, es landet also kein Schlüssel in deiner Konfiguration. Trag den Chaindoc-Eintrag in die MCP-Konfigurationsdatei deines Clients ein. Das Wissenswerte daran: Der Block unten ist in jedem MCP-fähigen Client identisch, nur der Pfad zur Datei ändert sich.

{
  "mcpServers": {
    "chaindoc": {
      "command": "npx",
      "args": ["-y", "@chaindoc/mcp-server"]
    }
  }
}

Starte den Client neu. Er sollte chaindoc jetzt mit 7 verfügbaren Tools listen, und der erste Tool-Aufruf dauert typischerweise 2-3 Sekunden. Clients ohne lokale Prozesse verbinden sich stattdessen mit dem gehosteten HTTP-Endpunkt; die aktuellen Pfade pro Client und die Endpunkt-URL stehen auf der API-Integrationsseite.

Zu Vertragserstellung, Unterzeichnung, Verifikation und Nachverfolgung kommen Rechnungsstellung und KYC-Orchestrierung, beide bereits ausgeliefert. Eine Funktion steht noch aus:

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" (ein Desktop-Assistent, eine Chat-App, ein Code-Editor, 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 Bereich "AI Agents" jetzt in deinem Dashboard. Wenn du E-Signatur-Werkzeuge mit KI auf der Roadmap evaluierst, starte auf unserer API-Integrationsseite.