MCP Server für die E-Signatur: was sich ändert, wenn ein KI-Agent den Vertrag verschickt

Eine API ist eine Sammlung von Endpunkten, gegen die ein Entwickler Code schreibt. Ein MCP Server ist ein kleines Programm auf dieser API, das die Endpunkte als Werkzeuge beschreibt, die ein KI-Modell selbst finden und aufrufen kann. Das ist der Unterschied zwischen MCP und API in einem Satz: Die API ist für Ihren Code da, der MCP Server für einen Agenten. Bei der E-Signatur entscheidet das, wer den nächsten Schritt wählt. Mit der Chaindoc REST-API bestimmt Ihr Code, wann ein Vertrag rausgeht. Mit dem MCP Server von Chaindoc bestimmt der Agent das, innerhalb der Grenzen des Schlüssels, den Sie ihm gegeben haben. Die Unterschrift wandert nie zum Agenten, und darum dreht sich der Rest dieses Beitrags.

Was ist ein MCP Server? Er ist die Serverseite des Model Context Protocol (MCP), eines offenen Standards, den Anthropic am 25. November 2024 veröffentlicht hat, um KI-Anwendungen mit externen Werkzeugen und Daten zu verbinden. Im Dezember 2025 ist das Protokoll an die Agentic AI Foundation unter dem Dach der Linux Foundation übergegangen, es gehört also keinem einzelnen Modellanbieter mehr. Die aktuelle Spezifikation trägt das Datum 2026-07-28.

MCP kennt drei Rollen. Der Host ist die KI-Anwendung, mit der Sie sprechen, der Client der Connector darin, und der Server stellt bereit, was ein externes System kann, in drei Formen:

• Tools: Funktionen, die das Modell aufrufen darf, etwa «Signaturanfrage erstellen».
• Resources: Daten, die Modell oder Nutzer lesen können, zum Beispiel der Status eines Vertrags.
• Prompts, also benannte Aufgaben, die ein Nutzer starten kann.

Die Nachrichten sind JSON-RPC 2.0. Ein Server läuft entweder als lokaler Prozess, den der Client startet (Transport stdio), oder hinter einem HTTP-Endpunkt (Streamable HTTP).

Ist ein MCP Server dann ein echter Server? Manchmal. Ein stdio-Server ist ein Prozess auf Ihrem Rechner, der mit dem KI-Client startet und endet. Ein HTTP-Server ist ein Dienst, den jemand betreiben muss.

Warum ist «MCP oder API» also die falsche Frage? Weil fast jeder nützliche MCP Server eine API umhüllt, die es schon gibt. Der von Chaindoc bildet seine Tools auf dieselben REST-Endpunkte ab, die auch Ihr Backend aufrufen würde. Sie wählen nicht zwischen den beiden. Sie wählen, wer am Steuer sitzt: Ihr Code oder ein Modell.

Die Endpunkte darunter sind dieselben. Der Unterschied zwischen MCP und API ist alles rund um den Aufruf, und fünf Dinge davon zeigen sich, sobald ein Agent der Aufrufer ist.

1. 1.
   Discovery. Ihr Code kennt die API, weil ein Entwickler die Dokumentation gelesen hat. Ein MCP-Client fragt den Server zur Laufzeit nach seiner Werkzeugliste (tools/list) und gibt Namen, Beschreibungen und Eingabeschemata an das Modell weiter. Wer Function Calling kennt: Es ist dieselbe Idee in einem gemeinsamen Format, ein Server läuft deshalb in jedem MCP-Client.
2. 2.
   Wer den Aufruf wählt. In einer API-Integration steht die Abfolge im Code und läuft jedes Mal gleich. Über MCP wählt das Modell das Tool und füllt die Argumente aus Ihrem Satz, derselbe Auftrag kann also an zwei Tagen zwei verschiedene Wege nehmen.
3. 3.
   Fehler gehen zurück an das Modell. Die Spezifikation trennt Protokollfehler von Fehlern bei der Ausführung eines Tools, und die zweite Sorte soll das Modell erreichen, damit es ein Argument korrigieren und es noch einmal versuchen kann. Ein Backend würde sie loggen und anhalten.
4. 4.
   Zugangsdaten stehen in einer Konfigurationsdatei. Ein stdio-Server liest seinen Schlüssel aus einer Umgebungsvariablen, die Ihr KI-Client übergibt. Wer diese Datei ändern kann, bestimmt, was der Agent darf.
5. 5.
   Die Freigabe ist Sache des Clients. Die Tools-Seite der MCP-Spezifikation empfiehlt (SHOULD), dass ein Mensch bei Tool-Aufrufen eingreifen und sie ablehnen kann, und dass Clients bei sensiblen Vorgängen um Bestätigung bitten. Ein Aufruf aus Ihrem Backend kennt diesen Schritt nicht, solange Sie ihn nicht selbst bauen.

Ehrlich gesagt: Punkt zwei ist der, der bei Verträgen zählt. Ein Skript, das einen NDA verschickt, verschickt genau den NDA, für den es geschrieben wurde. Ein Agent verschickt, was er als Ihre Absicht verstanden hat. Bei einem Dokument, das jemand unterschreiben soll, braucht diese Lücke eine Schranke.

Der Chaindoc MCP Server ist Open Source. Den Code gibt es auf GitHub unter der MIT-Lizenz, das Paket heißt @chaindoc_io/mcp-server auf npm, Version 0.2.0 bei unserer Prüfung am 14. Oktober 2026. Die meisten Tools bilden genau einen REST-Endpunkt ab und geben das Ergebnis in einer Form zurück, die das Modell lesen kann.

Die Tools nach Gruppen

Die Kerntabellen der README führen 35 Tools in zehn Gruppen auf:

• Dokumente: anlegen, ändern, Zugriffsrechte setzen, eine Version prüfen, ihren Prüfstatus lesen.
• Signaturen: Anfrage erstellen, Status lesen, eigene Anfragen auflisten und signieren.
• Verträge, die längste Gruppe: anlegen, auflisten, lesen, senden, stornieren, beenden, Aktivität lesen, ein Zahlungs-Setup anhängen.
• Rechnungen und Transaktionen für die Abrechnung aus einem unterschriebenen Vertrag: erstellen, senden, abbuchen, als bezahlt markieren, Zahlungen auflisten.
• Vorlagen: in ein Dokument oder einen Vertrag verwandeln oder direkt zur Unterschrift senden.
• Medien-Upload, eingebettete Signatursitzungen, zwei Kontoprüfungen und ein Webhook-Prüfer.

Version 0.2.0 hat Suche, Versionen, Erinnerungen, Stornierungen, Downloads der unterschriebenen Datei samt Zertifikat und den Lebenszyklus von Vorlagen ergänzt.

Resources und Prompts

Nur lesbare Resources wie chaindoc://contracts/{id}/status stehen neben benannten Prompts wie prepare_signature_request, die das Modell durch eine längere Aufgabe führen.

Zwei Dinge tut er nicht. Er registriert keine Webhooks: Die werden pro API-Schlüssel im Dashboard gesetzt, und das Webhook-Tool prüft nur ein Ereignis, das Sie schon erhalten haben. Und es gibt keinen von Chaindoc gehosteten Endpunkt, Sie betreiben ihn also über stdio oder hosten den HTTP-Modus selbst.

Die Verifikation ist der Chaindoc-spezifische Teil. Der Server hasht eine Datei beim Upload; wird eine Version veröffentlicht, kommt dieser Hash auf die Blockchain, und der Nachweis jedes Unterzeichners wird festgehalten, wenn die Unterschrift abgeschlossen ist. Die Verify-Tools prüfen eine Version gegen diesen Eintrag. Ein Agent kann so beantworten, ob dies die Datei ist, die unterschrieben wurde, ohne dass jemand die App öffnet.

Einen eigenen MCP-API-Schlüssel gibt es nicht. Der Server läuft mit einem normalen Chaindoc-API-Schlüssel, und Schlüssel lassen sich im Business-Tarif anlegen. Team-Konten können API-Zugang anfragen; Free und Personal können keine Schlüssel erstellen, und Webhooks gibt es nur im Business-Tarif.

Zwei Grenzen prägen das Verhalten eines Agenten. Der Server drosselt sich standardmäßig selbst auf 10 Anfragen pro Minute, das Limit, das Chaindocs API-Leitfaden vorgibt; ein Agent, der fünfzig Dokumente nacheinander abarbeitet, ist also absichtlich langsam. Und Agentenverkehr läuft über Ihr Konto wie jeder andere API-Aufruf: Die Anfragen, die er sendet, zählen gegen dasselbe monatliche Signaturkontingent. Prüfen Sie die aktuellen Preise, bevor Sie einen Agenten in großer Zahl senden lassen.

Kurz gesagt: Ein Agent kann auf den Knopf drücken, aber das Recht behandelt ihn nie als Unterzeichner. Unterzeichner ist, für wen der Agent handelt, und dort enden die meisten Sorgen rund um KI-Verträge.

In den USA: ESIGN und UETA

ESIGN definiert die elektronische Signatur als Ton, Symbol oder Verfahren, das von einer Person mit der Absicht ausgeführt oder übernommen wird, die Aufzeichnung zu unterschreiben (15 U.S.C. § 7006(5)). Die Absicht gehört einer Person. Für Software sagt 15 U.S.C. § 7001(h), dass ein Vertrag nicht deshalb unwirksam ist, weil ein elektronischer Agent an seinem Zustandekommen beteiligt war, solange dessen Handlung der gebundenen Person rechtlich zuzurechnen ist. UETA, in jedem Bundesstaat außer New York übernommen, rechnet eine Signatur der Person zu, deren Handlung sie war (§ 9, etwa über das eingesetzte Sicherheitsverfahren, bei einem MCP Server der API-Schlüssel), lässt Verträge zwischen elektronischen Agenten ohne menschliche Prüfung zustande kommen (§ 14) und erlaubt dem, der mit Ihrem Agenten zu tun hatte und einen Fehler nicht korrigieren konnte, die fehlerhafte Aufzeichnung bei zügigem Handeln anzufechten (§ 10). Ein Ablauf ohne Prüfschritt ist ein selbst gebautes Risiko.

In Deutschland und der EU: eIDAS, BGB und AI Act

Die Verordnung (EU) Nr. 910/2014 (eIDAS) ist auf dem Papier strenger. Artikel 3 Nummer 9 definiert den Unterzeichner als «eine natürliche Person, die eine elektronische Signatur erstellt», ein Modell kann das also nicht sein. Wer als Unternehmen Dokumente ohne eine Person hinter jedem einzelnen markieren will, hat ein anderes Instrument: das elektronische Siegel, das nach Artikel 3 Nummer 24 eine juristische Person erstellt. Wann das passt, steht in unserem Beitrag über elektronische Siegel für Unternehmen.

Das deutsche Recht kommt zum selben Ergebnis. Eine KI hat keine Rechtsfähigkeit und kann deshalb kein Stellvertreter sein. Die herrschende Lehre rechnet eine automatisiert abgegebene Erklärung dem zu, der das System einsetzt (Computererklärung), und das Ergebnis liegt nah an § 164 Abs. 1 BGB: Eine Willenserklärung, die jemand innerhalb der ihm zustehenden Vertretungsmacht im Namen des Vertretenen abgibt, wirkt unmittelbar für und gegen den Vertretenen. Maßgeblich ist also, was Sie dem Agenten erlaubt haben, bei einem MCP Server der Umfang des Schlüssels.

Bei der Form lohnt eine Unterscheidung. Die meisten Verträge, die ein Agent verschickt, ein NDA oder ein Dienstleistungsvertrag, sind formfrei. Eine einfache elektronische Signatur genügt, und Artikel 25 Absatz 1 eIDAS verbietet, ihr die Rechtswirkung nur deshalb abzusprechen, weil sie elektronisch ist. Verlangt das Gesetz Schriftform, ersetzt § 126a BGB sie nur, wenn der Aussteller seinen Namen hinzufügt und das Dokument mit seiner qualifizierten elektronischen Signatur versieht. Diese Signatur gehört dem Aussteller persönlich (Artikel 25 Absatz 2 eIDAS stellt sie der handschriftlichen Unterschrift gleich). Ein Agent kann sie nicht als eigene Erklärung setzen.

Noch ein Stichwort: der AI Act. Artikel 14 der Verordnung (EU) 2024/1689 verlangt für Hochrisiko-Systeme, dass natürliche Personen sie wirksam beaufsichtigen und entscheiden können, sie nicht zu nutzen oder ihre Ausgabe zu übergehen. Ob ein Einsatz als Hochrisiko gilt, hängt vom Zweck ab (Anhang III); ein Agent, der NDAs verschickt, fällt meist nicht darunter. Die Wertung passt trotzdem: Ein Mensch muss eingreifen können.

Für einen MCP-Workflow ist die praktische Linie einfach. Lassen Sie den Agenten vorbereiten, senden, nachfassen und prüfen. Die Unterschrift bleibt bei der Person, deren Willen sie festhält. Ob Sie einem bestimmten Agenten für eine bestimmte Art von Dokument die Signatur überlassen, entscheiden Sie schriftlich und bewusst, nie als Voreinstellung. Verstehen Sie das als Rahmen, nicht als Rechtsberatung für Ihren Vertrag.

Vier Stellen in einem Signaturablauf verdienen einen Menschen. Die langweilige Mitte gehört nicht dazu.

• Bevor etwas gesendet wird. Die Bestätigungsabfrage Ihres Clients sollte jedes Tool abdecken, das sendet, signiert, storniert, beendet oder abbucht. Lesende Aufrufe dürfen ohne Rückfrage laufen.
• Unterzeichner und ihre Reihenfolge. Eine vom Agenten angelegte Anfrage lädt alle Unterzeichner auf einmal ein. Kommt es auf die Reihenfolge an (erst genehmigt die Führungskraft, dann unterschreibt der Kunde), ist das ein Freigabeweg, den Sie in der Chaindoc-App im Business-Tarif einrichten, nichts, was der Agent improvisiert.
• Identität, wenn der Einsatz es verlangt. KYC-Prüfungen der Unterzeichner sind optional, über Chaindocs Identitätsprüfung mit einem monatlichen Kontingent je Tarif. Entscheiden Sie das pro Vertragsart, überlassen Sie es nicht dem Modell.
• Was der Agent liest. Text kann Anweisungen tragen, die Sie nicht geschrieben haben: eine Zeile in einem hochgeladenen PDF, eine Notiz in einem CRM-Eintrag. Die MCP-Spezifikation behandelt Tool-Annotationen von einem Server, dem Sie nicht vertrauen, aus demselben Grund als nicht vertrauenswürdig.

Was darf unbeaufsichtigt laufen? Statusabfragen, Erinnerungen an Personen, die das Dokument schon haben, die Prüfung einer Datei gegen ihren Eintrag auf der Blockchain. Jedes Dokument führt seinen eigenen Audit-Trail, selbst die unbeaufsichtigten Aufrufe hinterlassen also eine Spur, die Sie nachlesen können.

DocuSign hat am 4. September 2026 angekündigt, dass sein MCP Server ab dem 30. September allgemein verfügbar ist und sich aus Claude, ChatGPT, Gemini, Copilot, Slack und jedem MCP-Client aufrufen lässt. DocuSign betreibt ihn selbst, und die Verbindung läuft über eine OAuth-Anmeldung mit Zustimmungsbildschirm statt über einen Schlüssel in einer Konfigurationsdatei. Das ist ein echter Vorteil für ein Unternehmen, das keine API-Schlüssel auf Laptops liegen haben will, und Chaindoc bietet heute keinen gehosteten Endpunkt an.

Auf der Achse MCP vs API gleichen sich beide: Jeder Server umhüllt die API seines Anbieters. Bei der Kontrolle läuft der Tausch allerdings andersherum. Der Server von Chaindoc ist MIT-lizenzierter Code, den Sie lesen, forken und im eigenen Netz betreiben können, und seine Tools erreichen neben dem Signieren auch den Verifikationseintrag auf der Blockchain. Wenn Sie für einen Agenten eine DocuSign-MCP-Verbindung gegen die von Chaindoc abwägen, stellen Sie drei praktische Fragen: Wer hält die Zugangsdaten, wo läuft der Server, und welche Aktionen darf der Agent ohne Freigabe durch einen Menschen ausführen?

Nutzen Sie die API, wenn der Ablauf feststeht. Ein Deal springt auf «gewonnen», ein Vertrag geht aus einer Vorlage raus, ein Webhook aktualisiert das CRM, sobald unterschrieben ist. Das ist Code, er soll sich jedes Mal gleich verhalten, und ein Agent bringt dort nur Streuung. Wollen Sie KI-Dokumentenautomatisierung innerhalb eines festen Ablaufs, rufen Sie ein Modell aus Ihrem eigenen Code auf und lassen die API das Senden übernehmen. Unser Vergleich von E-Signatur-APIs sagt, worauf Sie auf dieser Seite achten sollten.

Nutzen Sie den MCP Server, wenn die Anfrage jedes Mal anders ist und ohnehin ein Mensch im Gespräch sitzt: «Schick den Dienstleistungsvertrag an die beiden aus dem gestrigen Call», «Welche NDAs vom letzten Monat sind noch offen?», «Ist dieses PDF die Version, die wir unterschrieben haben?». Das lässt sich schwer skripten und leicht sagen. Ein Beispiel aus dem Mittelstand: Ein Vertriebsteam lässt einen Agenten NDAs aus dem CRM versenden, und die Signatur setzt der Geschäftsführer selbst, per Link, mit seinem Namen.

Die meisten Teams enden bei beidem, auf getrennten Schlüsseln, und das ist die ehrliche Antwort auf die Frage MCP Server oder API. Die API führt aus, was Sie schon entschieden haben. Der Agent kümmert sich um das, was Sie noch nicht entschieden haben. In beiden Fällen bleibt die Unterschrift bei einer Person.