Docusign MCP Server

Der Docusign MCP Server ist Docusigns offizieller Remote-Dienst für das Model Context Protocol. Er verbindet einen MCP-fähigen KI-Client mit Docusign-Funktionen, damit Teams Vereinbarungen, eSignature-Umschläge und Workflows per natürlicher Sprache abfragen oder – soweit die Berechtigung reicht – auslösen können. Docusign führt den Dienst als Open Beta und stellt Endpunkte für Demo- und Produktionsumgebungen bereit. Das ist kein lokal installierbares Paket: Der Client spricht per Streamable HTTP mit https://mcp-d.docusign.com/mcp für Demo oder https://mcp.docusign.com/mcp für Produktion. Die offizielle Produktdokumentation veröffentlicht für diesen gehosteten Server kein direkt zugehöriges Quell-Repository; deshalb bleiben Repository-Link und GitHub-Stars im Katalog leer.

Vereinbarungen, Dokumente und Umschläge

Der Nutzen liegt im Agreement- und Dokumentkontext, nicht im allgemeinen Dateisystemzugriff. Die offizielle Tool-Referenz nennt für Agreement Manager das Abrufen einzelner Vereinbarungsdetails und das Auflisten der Vereinbarungen eines Docusign-Kontos. Für eSignature lassen sich Konten, Vorlagen, Nutzer, einzelne Umschläge und gefilterte Umschlagslisten lesen. Ein Create-Envelope-Werkzeug erstellt einen Umschlag aus einer Vorlage mit Dokumenten, Empfängern und Tabs. Damit kann ein Assistent etwa eine freigegebene Onboarding-Vorlage vorbereiten, statt Dokumente außerhalb des Docusign-Prozesses zu verschicken.

Der Schreibzugriff ist wesentlich: Update Envelope kann Entwürfe senden, Umschläge ungültig machen oder E-Mail-Angaben ändern; Update Envelope Recipients kann Empfänger hinzufügen, aktualisieren oder entfernen. Send Reminder benachrichtigt offene Empfänger. Diese Werkzeuge sind keine bloßen Textvorschläge, sondern können den Status eines Geschäftsvorgangs und die Kommunikation mit Unterzeichnenden verändern. Workflow-Builder-Werkzeuge können Instanzen starten, pausieren, fortsetzen oder abbrechen. Der produktive Server unterstützt laut Docusign nur einen begrenzten Satz von API-Gruppen; in Developer-Kontexten können weitere APIs und Endpunkte zur Erkundung verfügbar sein. Vor einem produktiven Einsatz gehören Zielkonto, Vorlage, Empfängerliste und gewünschter Umschlagsstatus in eine explizite Prüfung.

Token, Konten und Rollen

Für die Verbindung verlangt Docusign ein gültiges OAuth-Access-Token. Laut offizieller Entwicklerdokumentation akzeptiert der MCP Server Access Tokens des Confidential Authorization Code Grant. Ein Docusign-Developer-Konto ist die Ausgangsbasis für Entwicklung und Demo; der Server ist inzwischen auch für Produktionskonten verfügbar. Docusigns Connector-Anleitung unterscheidet außerdem Standardnutzer, die ein Produktionskonto über die Client-Oberfläche verbinden, von Entwickler:innen mit Demo-Konto für eigene Integrationen.

Ein Token erweitert keine vorhandenen Docusign-Rechte. Die Tool-Referenz sagt ausdrücklich, dass jedes Werkzeug durch bestehende Docusign-Berechtigungen und OAuth gesteuert wird; der Assistent soll nur Informationen sehen, zu denen die authentifizierte Person berechtigt ist. Das ist eine Grenze, keine Freigabeempfehlung. Verwende für Tests ein Demo-Konto und für Produktion ein separates, möglichst niedrig privilegiertes Nutzerkonto mit nur den benötigten Konto-, Vorlagen- und Umschlagsrechten. Den OAuth-Token nie in Chat, Quellcode oder MCP-Konfiguration mit Versionskontrolle ablegen und nach Personal- oder Rollenwechsel widerrufen.

Personenbezogene Daten, Modellpfad und Nachvollziehbarkeit

Umschlags- und Empfängerdaten können Namen, E-Mail-Adressen, Status, Kontokontext sowie Tab-Werte enthalten. Auch Vereinbarungsdetails und Dokumentfelder können vertrauliche Vertrags- oder Identitätsdaten transportieren. Der praktische Datenpfad lautet: Eine Person schreibt eine Anfrage in den gewählten KI-Client; dessen Assistent beziehungsweise Modell entscheidet über einen Tool-Aufruf; Parameter gehen an den gehosteten Docusign MCP Server und die autorisierten Docusign-APIs; Ergebnisse kehren zum Client zurück und können dem Modell zur Antwort bereitgestellt werden. Docusign verbindet damit zwar seine APIs, bestimmt aber nicht die Datenschutz-, Speicher- oder Trainingsbedingungen des gewählten KI-Clients und Modellanbieters. Diese müssen vor der Freigabe sensibler Vertragsdaten separat geprüft werden.

Behandle Chat-Protokolle nicht als belastbaren Audit Trail. Für nachvollziehbare Vorgänge sollten Teams Umschlags-ID, Vorlage, Konto, Auftraggeber, bestätigte Empfänger und Ergebnis im eigenen Prozess festhalten und die vorhandenen Docusign-Umschlags- beziehungsweise Vereinbarungsdaten prüfen. Besonders bei Versand, Void oder Empfängeränderungen ist ein menschlicher Abgleich vor und nach dem Tool-Aufruf sinnvoll. Docusign warnt ausdrücklich: Vollautomatisierte Agenten erhöhen die Anfälligkeit für Prompt-Injection-Angriffe, und ein bösartiger Remote-MCP-Server kann sensible Daten abziehen.

Sicherheitsbetrieb

Aktiviere im KI-Client Bestätigungen für schreibende Werkzeuge, soweit der Client sie anbietet. Gib einer Anfrage aus einem Vertrag, einer E-Mail oder einem Tool-Ergebnis nie automatisch dieselbe Autorität wie einer menschlichen Anweisung: Eingebettete Texte können versuchen, den Agenten zum Senden, Ändern oder Offenlegen von Daten zu verleiten. Beschränke die Tools, die Automatisierung und den Kontoumfang; prüfe Entwurf, Empfänger und Konsequenz sichtbar vor dem Versand. Docusign empfiehlt einen Human in the Loop für Werkzeuge sowie für Richtigkeit und Angemessenheit der KI-Ausgabe. Die Beta-Kennzeichnung bedeutet außerdem, dass Verhalten und Verfügbarkeit geändert werden können; produktive Freigaben brauchen deshalb einen getesteten Rückfallweg außerhalb des Chats.

FAQ

Ist dies ein selbst hostbarer Open-Source-Server? Nein. Docusign dokumentiert einen gehosteten Remote-Endpunkt; die offizielle Produktdokumentation verlinkt kein separates Server-Repository. Deshalb gibt es hier keine GitHub-Sternzahl.

Kann ein Prompt wirklich einen Umschlag versenden? Ja, wenn der Client das passende Werkzeug aufruft, das OAuth-Token und die Docusign-Rolle die Aktion erlauben und der Auftrag entsprechend formuliert ist. Vor Senden, Void oder Empfängeränderungen ist eine menschliche Bestätigung erforderlich.

Gehen Unterzeichnerdaten an ein KI-Modell? Tool-Ergebnisse können Empfänger- und Vertragsdaten enthalten und werden an den gewählten KI-Client zurückgegeben. Ob und wie der Client sie an sein Modell übergibt, hängt vom Client und Modellanbieter ab; prüfe diesen Datenpfad vorab.

Docusign-Developer- oder Produktionskonto, eine OAuth-Integration mit Confidential Authorization Code Grant und ein MCP-Client mit Streamable-HTTP-Unterstützung. Für Produktion ein niedrig privilegiertes, dediziertes Nutzerkonto verwenden.

Demo: Remote-URL https://mcp-d.docusign.com/mcp; Produktion: https://mcp.docusign.com/mcp. Den Client mit Streamable HTTP konfigurieren, einen OAuth-Token per Confidential Authorization Code Grant beziehen und nur nach Prüfung des richtigen Kontos verbinden. Den konkreten Konfigurationsdialog des verwendeten Clients in der offiziellen Docusign-Anleitung nutzen.

Gültiger OAuth-Access-Token aus dem Confidential Authorization Code Grant. Zugang und Aktionen bleiben an das authentifizierte Docusign-Konto sowie dessen bestehende Berechtigungen gebunden.

Werkzeuge folgen laut Docusign bestehenden Docusign-Berechtigungen und OAuth. Sie können je nach Rolle Vereinbarungen, Umschlags- und Empfängerdaten lesen sowie Umschläge, Empfänger oder Workflows ändern. Nur dedizierte Least-Privilege-Konten verbinden.

Prompts werden im gewählten KI-Client verarbeitet; Tool-Parameter gehen an Docusigns gehosteten MCP Server und autorisierte APIs. Resultate können Vereinbarungs-, Dokument-, Umschlags- und Unterzeichnerdaten enthalten und zum KI-Client beziehungsweise dessen Modell zurückkehren. Datenschutz und Aufbewahrung des Client- und Modellanbieters separat prüfen.

Schreibwerkzeuge können Entwürfe senden, Umschläge voiden, Empfänger ändern oder Workflows auslösen. Docusign warnt vor Prompt Injection bei vollautomatisierten Agenten und vor Datenabfluss durch bösartige Remote-MCP-Server. Chat-Verlauf ist kein Audit Trail: Umschlags-ID, Empfänger, Bestätigung und Ergebnis außerhalb des Chats nachvollziehbar dokumentieren; bei jeder Mutation menschlich bestätigen.