MCP-Verbindung einrichten

Output.Rocks stellt ausgewählte Dokumentations-, Konfigurations-, Prozess- und Testfunktionen über MCP bereit. Die Produktionsadresse lautet:

https://app.output.rocks/api/mcp

Für die Testumgebung ersetzen Sie in den folgenden Beispielen die Adresse durch https://app.staging.output.rocks/api/mcp. Verwenden Sie dafür eine Anmeldung auf Staging; Produktions- und Staging-Verbindungen sind getrennt.

Die Anmeldung erfolgt im Browser per OAuth 2.1. Verwenden Sie eine aktive, nicht delegierte Output.Rocks-Sitzung und genehmigen Sie nur die benötigten Scopes:

• mcp:read für Dokumentation, Konfigurationen, Prozesse, Test-Renderings und Simulationen
• mcp:ai zusätzlich für die KI-Fehleranalyse
• mcp:write für Änderungsvorschläge, die erst nach Ihrer Browser-Bestätigung ausgeführt werden

Eine MCP-Verbindung kann Business-Daten nicht unmittelbar verändern. Zulässige Änderungen erscheinen zuerst als 30 Minuten gültiger Vorschlag mit Vorher-/Nachher-Vergleich in der App. Löschen und sicherheitsrelevante Felder sind ausgeschlossen.

Verfügbarkeit und Prüfstand

Die Produktionsfreigabe vom 11. September 2026 bezieht sich auf die damaligen Datei-, Vorschau-, Konfigurations-, Prozess- und Report-/Archivfunktionen. Der damalige praktische Codex-Test belegt diesen Umfang.

Für den erweiterten Vorlagenablauf mit direkter Textänderung, Mehrfallvergleich, vollständiger Sichtprüfung und Wiederaufnahme ist die finale Codex-Abnahme noch offen: 0 von 5 aufeinanderfolgenden vollständigen Durchläufen auf dem finalen Stand (2. Oktober 2026). Die vorhandenen Einzelbelege vom 16. September bleiben historische Nachweise; sie zählen nicht zur neuen Serie. Die installierte native Codex-App hat Version 26.930.21537; ihre finale Abnahme steht noch aus.

Die unabhängige Claude-Abnahme wird in OR-244 durchgeführt und blockiert weder die Codex-Abnahme noch das Produktionsrelease. Ihre neue Serie beginnt ebenfalls bei 0 von 5; historische Claude-Belege bleiben in OR-188 erhalten. Automatisierte Tests und ein verfügbares Stagingdeployment ersetzen keine Clientabnahme. Produktions- freigabe und Live-Prüfung bleiben gesonderte Schritte. Prüfen Sie die tatsächlich gewählte Umgebung mit get_mcp_context; diese Anleitung schaltet keine Funktion frei.

GitHub Copilot in VS Code wurde praktisch nicht geprüft. Andere Copilot-Produkte gehören nicht zum Umfang dieser Anleitung. Die folgenden Einrichtungshinweise sind kein Nachweis einer erfolgreichen Clientabnahme.

Claude und Cowork

Öffnen Sie Anpassen > Connectors > Benutzerdefinierten Connector hinzufügen (je nach Oberfläche unter Einstellungen). Geben Sie einen Namen und die Produktionsadresse https://app.output.rocks/api/mcp ein. Falls der Dialog die Auswahl anbietet, wählen Sie Authentifizierung: Immer erforderlich und Keine Client-ID – automatisch eine registrieren. Eigene Client-Geheimnisse und zusätzliche Header sind nicht erforderlich.

Klicken Sie auf Hinzufügen, anschließend auf Verbinden, und schließen Sie die Output.Rocks-Anmeldung im Browser ab. Aktivieren Sie den Connector für die gewünschte Unterhaltung beziehungsweise Cowork-Aufgabe. In verwalteten Organisationen muss ein Eigentümer den Connector gegebenenfalls zuerst hinzufügen. Siehe Claudes Anleitung für Remote-Connectoren.

Claude Code

claude mcp add --transport http output-rocks https://app.output.rocks/api/mcp

Öffnen Sie danach in Claude Code /mcp, wählen Sie output-rocks und folgen Sie der Browser-Anmeldung.

Codex

codex mcp add output-rocks --url https://app.output.rocks/api/mcp
codex mcp login output-rocks

Schließen Sie die Anmeldung und Scope-Freigabe im geöffneten Browser ab. Starten Sie eine neue Codex-Sitzung und prüfen Sie über /mcp, ob die Werkzeuge geladen wurden. codex mcp get output-rocks zeigt lediglich die Konfiguration. Ein erfolgreicher Aufruf, beispielsweise eine Dokumentationssuche, prüft den Zugriff.

In der beobachteten Codex-App finden Sie die Server unter Plugins > MCPs (je nach Version unter Einstellungen > MCP-Server). Fügen Sie dort einen Server mit HTTP-URL hinzu. Fehlt eine Anmeldeoption, verwenden Sie den oben beschriebenen CLI-Anmeldeweg. CLI und App verwenden auf demselben Rechner dieselbe MCP-Konfiguration. Siehe MCP in Codex.

GitHub Copilot in VS Code

Legen Sie im Projekt die Datei .vscode/mcp.json an:

{
  "servers": {
    "output-rocks": {
      "type": "http",
      "url": "https://app.output.rocks/api/mcp"
    }
  }
}

Starten Sie den Server über die MCP-Verwaltung in VS Code, bestätigen Sie das Vertrauen und folgen Sie der angeforderten OAuth-Anmeldung im Browser. Öffnen Sie den Copilot-Chat und aktivieren Sie die Output.Rocks-Werkzeuge über die Werkzeugauswahl. Diese Anleitung bezieht sich auf GitHub Copilot in VS Code; andere Microsoft-Copilot-Produkte sind nicht Gegenstand dieser Integration. Siehe MCP-Server in VS Code verwalten.

Erweiterungen auf Produktion verwenden

Die historisch freigegebenen Erweiterungen benötigen zusätzliche Rechte. Melden Sie Ihre Verbindung erneut an und genehmigen Sie nur die benötigten Scopes. Für den neuen Vorlagenablauf gilt der oben genannte offene Prüfstand. Beispiel für Vorlagenbearbeitung mit Codex:

codex mcp add output-rocks --url https://app.output.rocks/api/mcp
codex mcp login output-rocks --scopes mcp:read,mcp:write,mcp:files,mcp:data

Für Prozessdiagnose und -aktionen zusätzlich mcp:process-data, für Reports und Archiv zusätzlich mcp:reports-archive ausdrücklich freigeben. Wählen Sie nur die benötigten Rechte. In Claude/Cowork und VS Code richten Sie entsprechend einen Server mit der Produktions-URL ein. Zusätzliche Scopes erfordern eine neue OAuth-Freigabe; vorhandene Verbindungen werden nicht automatisch erweitert.

Geeignete Aufträge nach erfolgreicher Anmeldung:

• „Verschiebe den Adressblock der Vorlage xxx passend zum vorhandenen Binect-Overlay. Zeige Original und Entwurf mit denselben Testdaten und erstelle anschließend einen Freigabevorschlag.“
• „Verringere die Tabellenzeilenabstände auf Seite 2 der Vorlage xxx. Prüfe alle Seiten mit kurzen und langen Testdaten, einschließlich Kopf- und Fußzeilen.“
• „Ermittle alle ausgesteuerten Dokumentprozesse mit nachgewiesenem Webhook-Fehler. Schlage die Wiederholung dieser festen Auswahl am fehlgeschlagenen Schritt mit ursprünglicher Konfiguration vor.“

Kleine Textänderungen erfolgen über die unten beschriebenen Textwerkzeuge direkt im Entwurf. Allgemeine Layoutänderungen benötigen einen DOCX-Editor und den geschützten Dateidialog. Output.Rocks liefert Kontext und Vorschauen und rendert mit dem bestehenden Template-Editor. Erst Ihre Browserfreigabe übernimmt eine Vorlage oder startet eine Prozessaktion. Prüfen Sie nach Freigabe die gespeicherte Version beziehungsweise die einzelnen Job-Ergebnisse. Temporäre Entwürfe und Vorschauen anschließend schließen.

Archiv und Untermandanten sind optionale Mandantenmodule. Auch mit OAuth-Freigabe sind diese Funktionen und Untermandanten-Zuordnungen nur bei aktiviertem Modul und ausreichenden Benutzerrechten verfügbar. Eine leere Treffermenge ist kein Nachweis der Modulfreischaltung.

Zusätzlicher Datei- und Inhaltszugriff

Für diese Erweiterungen verwenden Sie https://app.output.rocks/api/mcp und genehmigen bei einer neuen OAuth-Anmeldung zusätzlich mcp:files für Dateien beziehungsweise mcp:data für vollständige Konfigurations- und Testdaten. Diese Inhalte können personenbezogene Daten enthalten. Bestehende Verbindungen bekommen keine zusätzlichen Rechte.

• open_template_file lädt die DOCX-Datei einer konkreten Vorlagen-Versions-ID.
• create_artifact, upload_artifact_chunk und finalize_artifact übertragen einen temporären DOCX-Entwurf oder ein PDF-Overlay und prüfen seine SHA-256-Prüfsumme. Die Grenze beträgt 10 MiB pro Datei; bei DOCX zusätzlich 64 MiB entpackt und 2.000 Archiveinträge. Beschädigte oder verschlüsselte PDFs werden abgewiesen.
• read_artifact_chunk liefert jeweils höchstens 16 KiB als Base64. Folgen Sie nextOffset bis null und vergleichen Sie anschließend die gesamte Prüfsumme.
• get_entity_content liefert die vollständigen erlaubten JSON-Inhalte ebenfalls in Abschnitten. Übergeben Sie bei Folgeabrufen sha256; zwischenzeitliche Änderungen führen zu einem Konflikt. Geheimnisse, Binärfelder, interne Felder und verschachtelte Integrationsverbindungen bleiben ausgeschlossen. Mit ausdrücklich erteiltem mcp:data sind E-Mail-Adressfelder und reine Konfigurationskennungen lesbar. Bei Vorlagen, Bildern, PDF-Overlays und E-Mail-Anhängen enthält dieser Zugriff auch die Detailmetadaten, etwa Dateiname und Kommentar; get_entity behält seine bisherige kompakte Antwort.
• release_artifact entfernt nur die temporäre Datei dieser Verbindung.

Entwürfe verändern keine aktive Vorlage. Nach der Finalisierung ist eine Datei unveränderlich; weitere Bearbeitungen benötigen ein neues Artefakt. Der Zugriff endet mit Ablauf oder Widerruf der Verbindung, spätestens nach 23 Stunden. Die automatische Bereinigung läuft alle 15 Minuten. Pro Benutzer und Mandant sind höchstens 100 temporäre Dateien mit zusammen 64 MiB möglich.

Vorlagenentwürfe mit dem Template-Editor rendern

Mit der Rolle Template-Editor und den Berechtigungen mcp:read, mcp:files und mcp:data können Sie eine Vorlage bearbeiten lassen, ohne sie zu aktivieren:

1. Mit get_mcp_context Umgebung, Scopes und Voraussetzungen prüfen. Die konkrete Vorlagenversion mit list_entities auswählen; bei gleicher Kennung Marke und Untermandant klären. prepare_template_edit(templateId) zeigt Version, wirksame Vorschaumarke, Zuordnungen und benannte Testdaten. Mit testDataSearch, page, limit und pagination.nextPage die Auswahl eingrenzen. Testdaten sind nicht fest einer Vorlage zugeordnet; mehrdeutige Treffer ausdrücklich auswählen.
2. begin_template_edit mit templateId und ein bis fünf benannten testCases starten. Jeder Fall hat genau eine Quelle: gespeicherte testDataId, ein JSON-Objekt oder Array als testData, oder eine finalisierte testDataArtifactId. Fallbeispiel und Auswahlregeln. Alternativ bleibt die bisherige einzelne Quelle mit testDataName bei temporären Daten möglich. Die Daten bleiben im Entwurf; es entsteht kein dauerhafter Datensatz.
3. Das lesbare context prüfen. Bei contextAccess alle Abschnitte mit get_template_edit_context bis nextOffset: null lesen und Größe sowie SHA-256 prüfen. get_template_syntax liefert Syntaxhinweise. Auswahl und Testdaten bleiben unverändert; alle Falldaten zusammen dürfen höchstens 10 MiB umfassen.
4. Kleine Textänderungen mit find_template_text und replace_template_text anhand ausdrücklich gewählter Treffer und des Quellenhashs vornehmen. Für Layoutänderungen Original im Dateidialog herunterladen, im DOCX-Editor ändern und den Entwurf hochladen. get_artifact_status muss den Entwurf als ready: true ausweisen.
5. compare_template_edit mit editId, finalisierter draftArtifactId und neuer UUID als requestId starten. Ohne caseIds werden alle Fälle verglichen. get_template_comparison liefert Fortschritt und Ergebnisse. Original und Entwurf verwenden dieselben festen Daten und denselben Bezugszeitpunkt. Der bisherige render_template_edit-Einzelfallpfad bleibt verfügbar.
6. Nach erfolgreichem Rendering mit get_template_preview_info und get_template_preview_page alle Seiten aller gewählten Fälle prüfen. „Zuerst testen“ endet mit der Vorschau. Erst ein ausdrücklicher Speicherauftrag führt zu propose_template_update mit editId, draftArtifactId, comparisonId und konkreter summary. Im Freigabelink jeden Fall visuell prüfen und ausdrücklich bestätigen; Details zur Browserfreigabe. Danach die gespeicherte Version kontrollieren. Bis zur Entscheidung die Bearbeitung offen lassen.
7. close_template_edit entfernt die Originalkopie, verwaltete Textentwürfe, Vorschau-PDFs, temporäre Overlays und gegebenenfalls kopierte Wiederaufnahme-Eingaben. Extern hochgeladene DOCX-Entwürfe und JSON-Quellen grundsätzlich separat mit release_artifact aufräumen, auch nach ihrer Verwendung in einem Vergleich.

Rendering speichert oder aktiviert keine Vorlage. Geänderte Quellen oder Konfigurationen erfordern einen neuen Vergleich beziehungsweise eine neue Bearbeitung. Pro Benutzer sind zehn offene Bearbeitungen und pro Bearbeitung zwanzig Vorschauen möglich; die allgemeinen Datei- und Ablaufgrenzen gelten weiter. Größere Kontexte werden in 16-KiB-Abschnitten gelesen. Geheimnisse werden auch aus Testdaten entfernt.

Text direkt in einem Vorlagenentwurf ändern

find_template_text sucht mit editId und searchText den exakten Text (Groß-/Kleinschreibung beachten). Ohne sourceArtifactId wird das Original verwendet; für weitere Änderungen die ID des letzten Entwurfs angeben. Folgen Sie pagination.nextPage, bis alle relevanten Treffer geprüft sind. Jeder Treffer enthält matchId, Dokumentteil, Absatz, Kontext und canReplace mit einer möglichen Ablehnungsbegründung. Positionen zählen UTF-16-Codeeinheiten; übernehmen Sie die unveränderten Treffer-IDs statt Positionen selbst zu berechnen.

replace_template_text benötigt editId, eine neue UUID als requestId, sourceArtifactId, den zurückgegebenen sourceSha256, denselben searchText und eine ausdrückliche Auswahl replacements mit jeweils matchId und replacementText. Es gibt kein pauschales „alle ersetzen“. Nur gewählte Treffer werden geändert; gemischte Formatierung übernimmt am Ersatztext die Formatierung des ersten betroffenen Textabschnitts. Felder, Platzhalter, Änderungsmarkierungen, Strukturgrenzen und überlappende Treffer werden ausdrücklich abgewiesen.

Das Ergebnis enthält einen neuen, finalisierten draftArtifactId, dessen Hash und eine Änderungszusammenfassung. Die Quelldatei bleibt unverändert. Rendern, visuelle Prüfung und Freigabe erfolgen anschließend ausdrücklich über den oben beschriebenen Ablauf; Textänderungen starten sie nicht automatisch.

Dieselbe Request-ID mit identischen Eingaben liefert denselben Entwurf. Andere Eingaben oder eine andere Operation unter derselben ID ergeben einen Konflikt. Nach einem Timeout oder Abbruch erfolgt kein automatischer neuer Versuch: vorhandene Artefakte prüfen oder die Bearbeitung schließen. Ein bewusst neu beauftragter Versuch benötigt eine neue ID. Ein geänderter Quellhash erfordert zuerst eine neue Suche.

Grenzen: höchstens 50 Treffer pro Seite, 1.000 ausgewählte Ersetzungen und 64 KiB für sämtliche MCP-Eingaben zusammen pro Aufruf. Textänderungen akzeptieren keine neue Request-ID ab 100 gemeinsamen Aufträgen der Bearbeitung; Vergleiche bereits ab 50. Der Suchtext darf 4.096, ein Ersatztext 65.536 UTF-16-Codeeinheiten enthalten. Ersatztext ist einzeiliger Text ohne Tabulatoren oder Steuerzeichen. Die DOCX-Grenze bleibt 10 MiB. Verbindungs-, Rollen-, Mandanten- und Untermandantenrechte sowie Ablaufzeiten werden erneut geprüft. Abgeleitete Entwürfe bleiben an ihre Quellen gebunden; Quellartefakte deshalb bis zum Abschluss behalten. close_template_edit räumt auch ungerenderte oder unvollständig erzeugte Textentwürfe auf.

Vorschauseiten und Overlays

get_template_preview_info liefert mit editId und pdfArtifactId die Seitenzahl und alle Seitengrößen in Punkten. get_template_preview_page liefert mit denselben IDs und page ein direkt sichtbares MCP-Seitenbild. Die Seitennummer beginnt bei 1; beispielsweise prüft page: 2 gezielt die Tabelle auf der zweiten Seite.

Optional wählen Sie entweder overlayId für ein gespeichertes Overlay oder overlayArtifactId für ein zuvor hochgeladenes und finalisiertes PDF. Gespeicherte Overlays über list_entities mit entityType: "pdf_overlays" eindeutig auswählen. Ein Binect-Overlay darf nicht aus seinem Namen oder erfundenen Maßen abgeleitet werden. Der bestehende Overlay-Vergleich legt die passende Overlay-Seite mit 50 % Deckkraft auf die Vorschauseite und skaliert sie auf deren Größe. Fehlende Overlay-Seiten werden im Ergebnis mit overlayApplied: false ausgewiesen.

PDFs sind auf 200 Seiten und 14.400 Punkte je Seitenkante begrenzt, Bilder auf 1.600 Pixel an der längsten Kante. Zu große Bilder und aufwendige oder beschädigte PDFs führen zu einem ausdrücklichen Fehler. Pro Vorschau sind 20 temporäre Overlays möglich; verwendete Uploads werden beim Schließen der Sitzung mit entfernt.

Overlays gelten ausschließlich für das zurückgegebene Vergleichsbild. Original-PDF, Entwurf-PDF und DOCX bleiben unverändert. Wiederholen Sie den Vergleich für Original und Entwurf mit demselben Overlay.

Verbindungen und Vorschläge verwalten

Öffnen Sie Integration > MCP-Verbindungen, um Ihre eigenen Verbindungen, deren Scopes und offene Änderungsvorschläge zu sehen. Dort können Sie eine Verbindung sofort widerrufen oder einen Vorschlag nach Prüfung des Diffs bestätigen beziehungsweise ablehnen. Hat sich das Zielobjekt seit der Erstellung verändert, wird der Vorschlag als veraltet markiert und nicht ausgeführt.

Links aus dem OAuth-Dialog öffnen die passende Freigabe direkt. Die Bestätigung ist aus jeder aktiven, nicht delegierten Browser-Sitzung desselben Benutzers und Mandanten möglich. Die ursprüngliche MCP-Verbindung und ihre gebundene Browser-Sitzung müssen weiterhin gültig sein.

Teilen Sie keine Access- oder Refresh-Tokens. Bei einem unerwarteten Anmeldefenster, einer unbekannten Redirect-Adresse oder zu weitreichenden Scopes brechen Sie die Freigabe ab.

Geprüfte DOCX im Browser übernehmen

Zusätzlich ist mcp:write und die Schreibberechtigung auf die konkrete Vorlage erforderlich. propose_template_update bindet die Freigabe an genau den gerenderten Entwurf, seine Prüfsumme, Ausgangsversion und Testdaten. Ein neuer Entwurf benötigt einen neuen Vorschlag. Optional kann genau ein gespeichertes overlayId oder ein temporäres overlayArtifactId mitgegeben werden; das Overlay wird unveränderlich für den Vergleich festgehalten und niemals in die DOCX übernommen.

Die Browseransicht zeigt Ausgangsversion, Beschreibung, vollständigen Kontext, Testdaten und beide Vorschauen mit Seitennavigation. Freigeben speichert über die bestehende Vorlagenversionierung; Aktivierung und geplante Versionen folgen denselben Regeln wie im Template-Editor. Ablehnen speichert nichts. Doppelte Bestätigung erzeugt keine zweite Version. Paralleländerungen, entfernte Dateien, Ablauf und Widerruf verhindern die Übernahme. Vorschläge laufen nach 30 Minuten ab.

Bei unklarem Speicherausgang bleibt erneutes Speichern gesperrt. Verwenden Sie Speicherstatus prüfen; die Änderung bleibt auch nach Neuladen über ihren Link erreichbar. Ein Verbindungsfehler beweist nicht, dass nichts gespeichert wurde. Es erfolgt keine automatische Wiederholung.

Alle Vergleichsfälle ausdrücklich freigeben

Bei mehreren Testfällen erhält propose_template_update zusätzlich die comparisonId des abgeschlossenen Vergleichs. Der Vorschlag bindet alle dort gewählten Fälle, die exakten Original-/Entwurfs-PDFs, den Entwurf, den festen Bezugszeitpunkt und die aufgelösten Abhängigkeiten. Eine kleinere Freigabemenge innerhalb desselben Vergleichs ist nicht möglich. Fehlgeschlagene, unvollständige oder veraltete Vergleiche können nicht vorgeschlagen oder übernommen werden.

Im bestehenden Browserdialog wechseln Sie zwischen den benannten Testfällen. Original, Entwurf und echte transparente Überlagerung (50 %) sind pro Seite sichtbar; hinzugefügte oder entfernte Seiten werden ausdrücklich markiert. Die Einzelansichten zeigen die Seitenformate; die Überlagerung skaliert den Entwurf auf die Originalseite. Aufgezeichnete MCP-Textänderungen erscheinen als Zusammenfassung. Bei extern oder teilweise extern bearbeiteten DOCX-Dateien wird die fehlende vollständige semantische Änderungsliste ausdrücklich angezeigt.

Öffnen und prüfen Sie sämtliche Seiten jedes Falls und bestätigen Sie anschließend „Ich habe alle Seiten dieses Testfalls visuell geprüft.“ Erst nach der ausdrücklichen Bestätigung aller Fälle ist die Übernahme möglich. Vollständig geladene Seiten bleiben auch während des Kontextladens vorgemerkt. Die Fallbestätigung und Übernahme bleiben jedoch gesperrt, bis der Kontext vollständig geladen ist. Fehler beim Laden von Kontext, Seiten oder Bildern verwerfen die bisherigen Prüfnachweise. Ein geänderter Vergleichsfingerabdruck verlangt eine neue Prüfung; ein Fallwechsel umgeht das nicht. Geladene Bilder oder erfolgreiches Rendering gelten allein nicht als Sichtprüfung. Die Fallauswahl dient nur der Navigation. Der Server verlangt die Bestätigung des exakten Vergleichs und der vollständigen Fallmenge; unmittelbar vor dem Schreiben prüft er erneut Rechte, Quellen, PDFs und Abhängigkeiten. Eine spätere Änderung erfordert einen neuen Vergleich und Vorschlag. Bestehende Einzelfallvorschläge bleiben lesbar; Ablehnung und wiederholte Bestätigung behalten ihre bisherigen Regeln. Dieser Ablauf bedeutet keine automatische Aktivierung oder Produktionsfreigabe.

Konfigurationen und Versionen bearbeiten

propose_configuration_change erweitert die bestätigte Bearbeitung auf Marken, Untermandanten, Dokumentvorlagen, Standardwerte, Vorlagenbausteine, E-Mail-Vorlagen, Standard-E-Mail-Vorlagen, Testdaten, Datenmappings, Validatoren, Diagramme, QR-Codes, Bilder, PDF-Overlays, Formularkonfigurationen und E-Mail-Anhänge. Die Feldlisten im Werkzeugschema enthalten die passenden Zuordnungen, Aktivierungsdaten und Dateifelder. Für E-Mail-Anhänge unterstützen die Lesewerkzeuge zusätzlich email_attachments. list_entities liefert eine pagination mit nextPage; wenn die Quelle keine Gesamtanzahl liefert, kann die letzte Folgeseite leer sein (nextPageMayBeEmpty).

Erforderlich sind mcp:read, mcp:write, mcp:data und die jeweiligen UI-Rechte. Für Untermandanten gelten zusätzlich die Admin-Rolle, Hauptmandantenzugriff und das aktivierte Untermandantenmodul. Benutzer-, Rollen-, Geheimnis- und Integrationsadministration sind keine Konfigurationsaktionen dieses Werkzeugs.

• operation: "create" legt zunächst nur einen Vorschlag an; operation: "update" benötigt die konkrete id. Umbenennen und allgemeines Löschen sind ausgeschlossen.
• Die Dateifelder heißen fileArtifactId beziehungsweise bei Bildern imageArtifactId. Laden Sie die Datei vorher mit den Artefaktwerkzeugen hoch und finalisieren Sie sie. Dafür ist zusätzlich mcp:files erforderlich. Bilder akzeptieren PNG/JPEG, PDF-Overlays PDF und Dokumentvorlagen DOCX; die akzeptierten Anhangsformate stehen im Schema von create_artifact.
• Zuordnungen templates und emailTemplates enthalten Vorlagenkennungen. Die betroffenen Vorlagen werden bei der Freigabe erneut auf Zustand und Rechte geprüft. Zwischenzeitliche Änderungen machen den Vorschlag ungültig.
• Eine neue Dokumentvorlage benötigt außerdem testDataId. Die Vorschau entsteht durch den vorhandenen Template-Editor, ohne bereits eine Vorlage zu speichern. Prüfen Sie die PDF-Datei und get_configuration_preview_page visuell und öffnen Sie anschließend den Freigabelink. Für DOCX-Änderungen an bestehenden Vorlagen verwenden Sie weiterhin den oben beschriebenen Bearbeitungsablauf mit propose_template_update.

Passt ein großes Feldobjekt nicht in das 64-KiB-Limit eines Werkzeugaufrufs, übertragen Sie es als UTF-8-JSON-Datei mit den Artefaktwerkzeugen. Übergeben Sie fieldsArtifactId anstelle von fields; maximal 10 MiB sind möglich. Ein umfangreicher Vorschlag verweist auf get_pending_change_content. Folgen Sie nextOffset bis null und senden Sie bei Folgeabrufen die erhaltene sha256. Felder und Unterschiede werden vollständig geliefert, nicht still abgeschnitten.

propose_configuration_version bietet restore für eine konkrete Versions-ID und cancel für eine noch zukünftige geplante Version. Bei restore kann activeFrom als Datum mit Uhrzeit und Zeitzone angegeben werden. Beide Aktionen benötigen Browserfreigabe, verwenden die bestehende Versionierung und verweigern die Ausführung, wenn sich die Versionshistorie inzwischen geändert hat.

Prozesse diagnostizieren

search_processes liest Dokument-, E-Mail-, XML- und Datensammler-Prozesse sowie Rendering-Requests. Dafür sind mcp:read, ausdrücklich erteiltes mcp:process-data und die Berechtigungen der jeweiligen UI-Ansicht erforderlich. Untermandanten bleiben getrennt. Die bisherigen Prozesswerkzeuge bleiben unverändert verfügbar.

Beispielauftrag: „Zeige die blockierten Dokumentprozesse mit nachgewiesenem Webhook-Fehler. Erkläre die Ursache eines Treffers anhand seines Workflow-Protokolls.“

• Verwenden Sie processType: document, email, rendering_request, xml oder data_collector. Das Werkzeug beschreibt die Filter je Prozessart.
• filters: {"failureCategory": "webhook"} verlangt einen beim fehlgeschlagenen Webhook-Aufruf erfassten Fehler und den dazu passenden aktuellen blockierten Zustand. Ein zugeordneter Webhook oder ein Texttreffer genügt nicht.
• Die strukturierte Fehlererfassung beginnt mit dieser Version. Ältere Fehler ohne Nachweis werden nicht automatisch als Webhook-Fehler eingeordnet. Lesen Sie dafür die blockierten Prozesse ohne failureCategory und prüfen Sie deren Protokolle.
• pagination.nextPage nennt die nächste Seite; null beendet die Auswahl. Wenn die UI keinen Gesamtzähler liefert, bleibt totalItems unbekannt. Ein eventuell leerer Folgeabruf wird mit nextPageMayBeEmpty ausdrücklich angekündigt.
• get_process_diagnostics liefert Zustand und Fehlernachweis eines konkreten Prozesses. get_process_content liefert vollständige Metadaten (metadata), das Workflow-Protokoll (workflow_log) oder berechtigte Nutzdaten (payload). Datensammler-Prozesse besitzen keinen eigenen Nutzdatenabschnitt.

Große Inhalte werden als Base64-kodierte JSON-Teile übertragen. Folgen Sie nextOffset bis null, geben Sie bei Folgeabrufen sha256 zurück und prüfen Sie die Prüfsumme der zusammengesetzten Datei. Ändert sich der Inhalt, beginnt der Abruf erneut bei Offset 0. Geheimnisse, Authentifizierungsheader, interne Pfade und Verbindungsdetails bleiben ausgeschlossen. Fehlermeldungen in der Übersicht können gekürzt sein; messageTruncated weist darauf hin, das Protokoll bleibt separat vollständig lesbar.

Diese Diagnosewerkzeuge verändern keine Prozesse. Für Aktionen verwenden Sie den nachfolgend beschriebenen browserbestätigten Ablauf.

Die neue Berechtigung mcp:process-data erfordert eine erneute OAuth-Zustimmung. Bereits erteiltes mcp:data umfasst keine Prozessnutzdaten.

Prozessaktionen und feste Stapel

Mit propose_process_action schlagen Sie eine Aktion für ausdrücklich ausgewählte Prozess-IDs vor. mcp:read, mcp:process-data und mcp:write sind erforderlich.

Beispielauftrag: „Wiederhole alle Dokumentprozesse mit nachgewiesenem Webhook-Fehler. Verwende die ursprüngliche Konfiguration und setze am fehlgeschlagenen Schritt fort.“

1. Lesen Sie mit search_processes und filters.failureCategory: "webhook" alle Seiten. Prüfen Sie die Ursachen und übernehmen Sie die konkreten IDs.
2. Erstellen Sie einen Vorschlag mit processType: "document", action: "retry", reason: "webhook_failure", ids und einer verständlichen summary. resolutionMode ist standardmäßig original. retry als Auflösungsmodus verlangt ausdrücklich eine erneute Konfigurationsauflösung.
3. Öffnen Sie approvalUrl. Der Browser zeigt Aktion, Anzahl, Auswahlgrund, jede ID mit Ausgangszustand sowie mögliche Neuberechnung oder Zustellung. Erst Änderung ausführen plant den Stapel ein. Ablehnen verändert nichts.
4. Lesen Sie den zurückgegebenen Auftrag (result.entityId) mit get_process_job. Folgen Sie nextPage, um alle Einzelergebnisse zu sehen.

Ein Vorschlag enthält maximal 500 IDs. Größere Treffermengen werden ausdrücklich in mehrere Stapel aufgeteilt. Später passende Prozesse kommen nicht hinzu. Veränderte Zustände, fehlende Rechte oder eine widerrufene Verbindung führen zum Überspringen. Doppelte Bestätigung erzeugt keinen zweiten Auftrag.

Eine E-Mail-Neuverarbeitung verwendet den bestehenden Ablauf für zurückgewiesene E-Mails: Sie erzeugt einen neuen Rendering-Request mit aktueller Auflösung. Optionale Parameter entsprechen der UI. Die ursprüngliche E-Mail wird dadurch nicht überschrieben. Erneuter Versand kann eine weitere Zustellung auslösen. Request- und XML-Korrekturen sind unten als eigene Aktionen beschrieben.

Der Auftragsstatus unterscheidet queued, running, successful, skipped und failed. successful bestätigt den abgeschlossenen Workflow-Aufruf, nicht den externen Zustellerfolg. Bei einer Neuverarbeitung nennt das Ergebnis den neu eingeplanten Request. Nach einem unklaren Worker-Abbruch wird die betroffene Aktion nicht blind wiederholt; prüfen Sie den Prozess vor einem neuen Vorschlag. Bereits vorbereitete Aktionen werden bei regulären Worker-Wiederholungen nicht erneut vorbereitet. Nicht betroffene Einträge können weiterlaufen.

Requests und E-Rechnungen korrigieren

Die folgenden Aktionen von propose_process_action benötigen jeweils genau eine ID, mcp:read, mcp:write, mcp:process-data und eine Browserfreigabe. Bis zur Freigabe bleiben Fachdaten unverändert. Die bisherige Funktion simulate_rendering_request bleibt kompatibel; für die bestätigte Simulation einer Korrektur verwenden Sie simulate_request.

Bei correct_request und simulate_request enthalten options die gewünschten Felder: renderData, metadata, templateIdentifier, format, externalId, webhookIdentifier, mailServerIdentifier und comment. Nicht angegebene Werte werden aus dem Quellrequest übernommen. null oder leerer Text löscht optionale Textwerte. Bei correct_xml enthält options.payload das vollständige JSON-Objekt, keinen XML-Text. Fehlende profile- und skipValidation-Werte werden wie in der UI übernommen und im Vorschlag angezeigt. Geheimnisse und eingebettete Binärdaten werden abgewiesen.

Beispiel eines Vorschlags (12345 durch die zuvor eindeutig gelesene ID ersetzen):

{
  "processType": "rendering_request",
  "action": "simulate_request",
  "ids": [12345],
  "summary": "Korrigierten Rechnungsbetrag vor Neuverarbeitung prüfen",
  "options": { "renderData": { "invoice": { "total": "123.45" } } }
}

renderData ersetzt den vollständigen Dateninhalt; laden Sie vorher den gesamten Payload mit get_process_content und übernehmen Sie unveränderte Felder. Für große Optionen eine JSON-Datei über die bestehenden Artefakt-Werkzeuge hochladen und finalisieren. Statt options dann optionsArtifactId übergeben (zusätzlich mcp:files, höchstens 2 MiB JSON). Der Vorschlag übernimmt eine feste Kopie des geprüften Inhalts. Änderungen daran erfordern einen neuen Vorschlag.

Der Browser zeigt ID, Ausgangszustand, Aktion und vollständige Parameter. Regenerierung und Neuzuordnung können einen angehaltenen Dokumentprozess fortsetzen und damit weitere Zustellungen auslösen. Eine neue Request-ID im Job bedeutet zunächst nur, dass dieser eingeplant wurde. Prüfen Sie dessen eigenen Endzustand.

get_process_job liefert den Status. Das vollständige zulässige Simulationsergebnis lesen Sie mit get_process_job_content und jobId/processId. Folgen Sie nextOffset unter Beibehaltung von sha256; prüfen Sie anschließend die Prüfsumme. Vorher-/Nachher-Daten und Zuordnungen bleiben vollständig verfügbar. Geheimnisse, Dateien, interne Pfade, Integrationskonfigurationen und rohe Wert-Diff-Einträge sind ausdrücklich ausgeschlossen; vergleichen Sie dataBefore und dataAfter. Rechte und Mandant des Quellrequests werden beim Ergebniszugriff erneut geprüft.

Reports, Archiv und Konfigurationstransfer

Diese MCP-Erweiterungen sind unter https://app.output.rocks/api/mcp auf Produktion verfügbar. Genehmigen Sie die jeweils benötigten zusätzlichen Rechte bei einer neuen OAuth-Anmeldung ausdrücklich.

Reports und Archiv lesen

read_reports liest Monatsberichte (kind: monthly), vorhandene Rendering-Berichte (kind: rendering, optional mit Job-id) oder die SLA-Auswertung (kind: sla). Es werden keine neuen Berichte erzeugt. read_archive listet berechtigte Archiveinträge oder liest einen Eintrag per id. Filter umfassen Suche, Zustand, Quelle, rechtliche Kategorie, Legal Hold, externe Kennung und Erstellzeitraum. Die bestehenden Rollen-, Modul- und Mandantenregeln gelten weiterhin.

Beide Werkzeuge liefern vollständiges zulässiges JSON in Base64-Teilen. Behalten Sie alle Filter bei und folgen Sie nextOffset mit derselben sha256, bis nextOffset leer ist. Prüfen Sie danach die Dateiprüfsumme. Für Listen enthält das zusammengesetzte JSON pagination.nextPage; damit wechseln Sie auf die nächste Seite und beginnen wieder bei Offset 0 ohne alten Hash.

open_report_file lädt die PDF-Datei einer Monatsberichts-ID; open_archive_file lädt das Original eines Archiveintrags und verwendet die bestehende Download-Protokollierung. Die Dateien werden als private Artefakte über read_artifact_chunk gelesen. Eine Datei darf höchstens 10 MiB groß sein. Größere oder nicht verfügbare Inhalte werden ausdrücklich abgewiesen und nicht gekürzt. Rechte werden bei jedem Teilzugriff erneut geprüft. Interne Speicherorte und Anmeldedaten werden nicht ausgegeben.

Konfigurationen exportieren und bestätigt importieren

Administratoren können mit export_configuration eine feste Auswahl von insgesamt 1–100 Versions-IDs als ZIP exportieren. Die Kategorien entsprechen dem vorhandenen UI-Transfer: brands, standardValues, images, charts, qrCodes, templates, emailTemplates, emailAttachments, standardEmailTemplates, templateComponents, dataValidators, testData. Beispiel einer Auswahl: {"testData":[123]}. IDs vorher eindeutig auflösen. Der Standard-Marken-Datensatz ist ausgeschlossen. Eine nicht berechtigte ID führt zum Fehler, statt unbemerkt aus der ZIP zu fehlen. Konfigurationen mit Geheimnissen oder nicht zuordenbaren eingebetteten Binärdaten werden abgewiesen; sie werden nicht still verändert exportiert.

Zum Import eine ZIP über die Artefakt-Werkzeuge hochladen und finalisieren:

1. preview_configuration_import mit artifactId aufrufen. Optional active (default, active, inactive) und activeFrom als ISO-Zeitpunkt angeben. Die Vorschau verändert keine Konfiguration.
2. Alle Vorschauseiten vollständig lesen. Jeder Eintrag enthält Kategorie, nullbasierten index, Inhalt, Datei-Prüfsummen und gegebenenfalls existingId. Die Vorschau verwendet dieselbe Konflikterkennung wie der UI-Import.
3. propose_configuration_import mit denselben Optionen, previewSha256, einer Beschreibung und einer Aktion für jeden Vorschau-Eintrag aufrufen. selection enthält Objekte mit category, index und action: neue Einträge erlauben create/skip, Konflikte overwrite/skip.
4. Im Browser die exakte ZIP-Prüfsumme, Aktivierung und feste Auswahl prüfen und freigeben. Erst dann importiert der bestehende Importdienst mit seinen Versionsregeln. Eine geänderte Datei oder Zielkonfiguration stoppt den Import.
5. Das Ergebnis mit get_pending_change lesen: imported, overwritten, skipped. Doppelte Bestätigung wiederholt den Import nicht. Temporäre Artefakte anschließend freigeben; ansonsten gilt ihr angezeigtes Ablaufdatum von höchstens 23 Stunden.

Datei- und Datenzugriffe benötigen ausdrücklich mcp:files und mcp:data, Importvorschläge zusätzlich mcp:write. Bestehende Verbindungen erhalten diese Rechte nicht automatisch. Allgemeines Löschen, Archivänderungen und eine freie REST-Schnittstelle bleiben ausgeschlossen.

Berichte und Archiv benötigen zusätzlich die neue OAuth-Berechtigung mcp:reports-archive. Melden Sie die Verbindung erneut an und bestätigen Sie den ausdrücklich beschriebenen Zugriff auf Berichte, Archivdaten und (mit mcp:files) Originaldokumente. Bestehende Verbindungen erhalten ihn nicht automatisch.

Archivzugriffe benötigen zusätzlich das aktivierte Archivmodul des Mandanten. Untermandanten verwalten, zuordnen oder Konfigurationen als Untermandanten-Standard freigeben setzt das aktivierte Untermandantenmodul voraus. OAuth-Rechte aktivieren keine dieser Funktionen. Modulfreigaben werden bei der Ausführung erneut geprüft.

Marken und Briefbögen

list_entities kann markenfähige Konfigurationen mit brandIdentifier auf eigene Markenzeilen oder mit effectiveBrandIdentifier einschließlich geerbter Standardwerte eingrenzen. Verwenden Sie jeweils nur einen dieser Filter. get_entity_content mit entityType: "brands" und section: "effective_configuration" zeigt Vererbung und Überschreibungen über alle neun markenfähigen Konfigurationstypen. Dafür ist die Datenfreigabe erforderlich.

run_test_render und begin_template_edit akzeptieren brandIdentifier. Gemeinsame Vorlagen werden damit im Kontext der gewählten Marke geprüft; markeneigene Vorlagen bleiben an ihre Marke gebunden. Die Bearbeitung speichert die Vorschau-Marke getrennt von der Vorlage.

Mit den erweiterten Konfigurationswerkzeugen lässt sich ein Briefbogen über propose_configuration_change (entityType: "brand", layoutFileArtifactId) hochladen oder mit removeLayout: true entfernen. Der Upload erfordert eine abgeschlossene DOCX-Datei und Dateifreigabe; Änderungen benötigen wie bisher die Browserbestätigung. Dabei gelten Briefbogenprüfung, Versionierung und das Verbot eines Briefbogens an default. Vorlagen unterstützen brandLayoutDisabled. Konfigurationsexporte und -importe enthalten auch die Briefbogendatei; die Importvorschau zeigt Dateityp, Größe und Prüfsumme.

Werkzeuge und fehlende Rechte prüfen

Rufen Sie zuerst get_mcp_context auf. Die Antwort nennt die tatsächliche Serveradresse, Mandant und Untermandant, gewährte Scopes, aktivierte Module, Ablaufzeit und Voraussetzungen der Funktionen. Zugangstokens werden nicht ausgegeben.

Testdaten erreichen Sie mit dem bestehenden Werkzeug list_entities:

{"entityType": "test_data", "page": 1, "limit": 20}

Folgen Sie pagination.nextPage, bis der Wert null ist. Wählen Sie mehrere Treffer nach Namen aus; technische IDs dürfen nicht geraten werden.

Client-Freigabe und Serverrechte sind getrennt. Claude/Cowork ruft ein im Connector als blockiert markiertes Werkzeug nicht auf. Prüfen Sie den für die Unterhaltung gewählten Connector, seine Adresse und die Werkzeugfreigaben. Der Server kann diese lokalen Einstellungen nicht auslesen. Im untersuchten Claude-Fehlerfall war List entities beim verbundenen Produktionsconnector sichtbar, aber blockiert; der Staging-Connector war nicht verbunden. Das belegt keine fehlende Testdatenfunktion auf dem Server.

Beim technischen Katalogvergleich alle tools/list-Seiten über nextCursor lesen und mit demselben Connector und derselben Umgebung vergleichen. Fehlende OAuth-Scopes lassen Serverwerkzeuge nicht verschwinden. Erweiterungsfunktionen setzen zusätzlich die Freigabe der Erweiterungen in der Umgebung voraus.

Strukturierte Werkzeugfehler nennen code, message, missingScopes und nextStep:

• MCP_SCOPE_REQUIRED: die konkret fehlenden Scopes freigeben.
• ROLE_REQUIRED: die genannte Benutzerrolle prüfen lassen.
• MODULE_DISABLED: das genannte Mandantenmodul oder die Umgebungserweiterungen prüfen lassen.
• ACCESS_DENIED: aktuelle Objekt- und Untermandantenrechte prüfen.
• CONFLICT: aktuellen Stand erneut laden; veraltete Vorschläge nicht wiederverwenden.
• RESOURCE_EXPIRED: eine neue Bearbeitung oder Dateiübertragung beginnen.

Eine erneute Anmeldung behebt keine blockierten Client-Werkzeuge, fehlenden Benutzerrollen oder deaktivierten Module. Ungültige Zugangstokens und OAuth-Anmeldefehler bleiben HTTP-/OAuth-Fehler.

Für die Vorlagenprüfung folgen Sie dem zusammenhängenden Ablauf oben. DOCX-Binärdaten nicht manuell im Chat rekonstruieren.

Temporäre Testdaten auswählen

Auch ohne gespeicherte Testdaten können Sie einen benannten Vorschaufall bereitstellen:

{
  "templateId": 123,
  "testDataName": "Kurze Beispielrechnung",
  "testData": { "customer": { "name": "Musterkunde" }, "items": [] }
}

Die Beispiel-ID vor dem Aufruf durch die tatsächlich ausgewählte Versions-ID ersetzen. Große Ganzzahlen, bei denen der Client Genauigkeit verlieren könnte, als Zeichenketten übergeben. Große JSON-Dateien über die vorhandenen Dateiwerkzeuge hochladen und finalisieren, dann ihre testDataArtifactId übergeben. Ein skalarer JSON-Wert genügt nicht.

context.testCases enthält beim bisherigen Einzelaufruf den festen Fall default; context.testData bleibt als kompatibler erster Fall verfügbar. Während der Bearbeitung ändern sich diese Daten nicht. Die aktuellen Zugriffsrechte werden weiterhin geprüft. Ein Entwurf mit JSON-Artefakt läuft spätestens mit seiner Quelle ab und kann nach Löschen oder Ablauf der Quelle nicht weiterverwendet werden. Diese Grenzen gelten auch für direkte Downloads der abgeleiteten PDF-Vorschauen. Eigentümer können den Entwurf und seine Dateien auch nach Wegfall der Quelle oder ihrer Zugriffsrechte aufräumen. Das Schließen entfernt keine separat hochgeladene JSON-Quelle; diese kann anschließend mit release_artifact entfernt werden.

prepare_template_edit verändert weder Vorlagen noch Dateien. Große Vorlagenkontexte verweisen mit templateContentAccess auf den vorhandenen vollständigen Inhaltszugriff.

Mehrere Testfälle gemeinsam vergleichen

begin_template_edit akzeptiert alternativ testCases mit ein bis fünf Fällen. Jeder Fall benötigt eine eindeutige caseId, einen eindeutigen name und genau eine Quelle: testDataId, testData oder testDataArtifactId. Diese Liste darf nicht mit der einzelnen bisherigen Testdatenquelle kombiniert werden. Die gesamten gespeicherten Falldaten dürfen höchstens 10 MiB groß sein. Nach Beginn bleiben Auswahl, Namen und Daten unverändert; context.testData zeigt weiterhin den ersten Fall.

{
  "templateId": 123,
  "testCases": [
    { "caseId": "kurz", "name": "Kurze Rechnung", "testData": { "items": [1] } },
    { "caseId": "lang", "name": "Lange Rechnung", "testDataId": 456 }
  ]
}

Nach einer Änderung startet compare_template_edit mit editId, einem finalisierten draftArtifactId und einer neuen UUID als requestId den Vergleich. caseIds wählt explizite, unterschiedliche Fälle aus dieser Bearbeitung; ohne Auswahl gelten alle Fälle. Für jeden ausgewählten Fall werden Original und Entwurf mit denselben gespeicherten Daten, derselben Marke und demselben festen Bezugszeitpunkt gerendert. Bei einer Wiederaufnahme bleibt der ursprüngliche Bezugszeitpunkt erhalten. Auch Diagramme, QR-Codes, Bausteine und Anhänge verwenden diesen Kontext. Die bisherigen Einzelaufrufe von render_template_edit bleiben verfügbar.

Der Start liefert sofort comparisonId und queued. get_template_comparison mit editId und comparisonId liefert den Fortschritt: completedSteps, totalSteps, currentStep und alle steps mit Fall, Seite (original/draft), Phase, privater PDF oder konkretem Fehler. Mit get_template_preview_info und get_template_preview_page lassen sich nach Abschluss des gesamten Vergleichs diese PDFs einschließlich der vorhandenen Overlay-Funktion prüfen. Während ein Rendering die Bearbeitung sperrt, können Seitenabrufe CONFLICT melden; warten Sie auf den Abschluss, statt einen neuen Renderauftrag zu starten.

completed bedeutet, dass alle ausgewählten Paare erfolgreich erstellt wurden. partial kennzeichnet vorhandene Ergebnisse mit Fehlern; failed, interrupted und stale sind ebenfalls keine erfolgreiche Abnahme. Änderungen oder fehlende Abhängigkeiten machen eine erneute Vergleichserstellung erforderlich. Die kompakte Statusantwort enthält Original-/Entwurfshashes, Fallhashes, fixedDate, payloadSha256 und pro Ergebnis den Fingerabdruck der aufgelösten Abhängigkeiten. Die vollständigen IDs, Versionen und Datei-/Konfigurationshashes bleiben für die aktuelle Rechte- und Quellenprüfung erhalten. Im späteren Vorschlag sind sie über get_pending_change_content unter fields.comparison.steps[].dependencies vollständig lesbar; folgen Sie dem gelieferten Inhaltszugriff mit nextOffset und sha256. Diese Belege zeigen, was dem Rendering übergeben wurde; sie beweisen nicht, dass jede Variable im PDF sichtbar ist. Die erneute Prüfung eines abgeschlossenen Vergleichs erzeugt keine neuen PDFs.

outputBudgetBytes reserviert vor dem Start ein Gesamtbudget, standardmäßig 32 MiB, ausdrücklich höchstens 64 MiB innerhalb der noch verfügbaren gemeinsamen Quote. Es zählt zusammen mit allen temporären Dateien und anderen Vergleichen zur bestehenden 64-MiB-Quote. Jede PDF bleibt auf 10 MiB begrenzt, pro Bearbeitung sind höchstens 20 Vorschauen erlaubt. Verbrauchte Bytes ersetzen die Reservierung; ungenutztes Budget wird am Ende freigegeben. Auch unvollständige Ausgabedateien gehören zur Bearbeitung und werden beim Schließen aufgeräumt. PDFs übernehmen die kürzere Ablaufzeit ihrer Quellen und bleiben an deren aktuelle Zugriffsrechte gebunden.

Ein identischer requestId wiederholt keinen Renderauftrag. Derselbe Bezeichner mit anderen Eingaben oder einer anderen Bearbeitungsoperation wird abgewiesen. Bei unklarem Ausgang eines externen Aufrufs werden auch Baustein-Renderings nicht automatisch wiederholt. Ohne bestätigten Fortschritt läuft die Reservierung nach 15 Minuten aus; Statusabfragen und die normale Dateiverwaltung erkennen solche Unterbrechungen. Nach Prüfung der Teilergebnisse ist für einen bewusst neuen Versuch eine neue UUID erforderlich.

Erfolgreiches Rendering ersetzt keine visuelle Prüfung und speichert oder aktiviert keine Vorlage automatisch.

Dateien im Browser übertragen

Mit Dateien an einer aktiven Verbindung öffnen Sie den geschützten Datei-Dialog. Diesen Dialog erreichen Sie auch über fileTransferUrl aus get_mcp_context oder browserUrl aus einer Artefaktantwort. Die Links enthalten keine Zugangstokens; Sie benötigen dieselbe aktive Browseranmeldung, mit der Sie die Verbindung bestätigt haben, und die Dateiberechtigung mcp:files.

Eine aktive Verbindung mit passenden Scopes allein genügt nicht: Nach einer neuen Browseranmeldung kann die bisherige Verbindung weiterhin aktiv sein, aber nur Widerrufen anbieten. Für Dateien genehmigen Sie eine neue OAuth-Verbindung in der aktuellen Browser-Sitzung. Alte Dateien werden dadurch nicht übernommen; für frühere Vorlagenarbeit verwenden Sie die ausdrückliche Wiederaufnahme. Schließen Sie einen laufenden Prüfablauf zuerst ab, bevor Sie die Verbindung wechseln.

Wählen Sie eine Datei bis 10 MiB und starten Sie den Upload. Browser und Server prüfen Größe und SHA-256; nach vollständigem Empfang folgt die vorhandene Formatprüfung. Abbrechen pausiert die Übertragung. Zum Fortsetzen wählen Sie dieselbe Datei erneut aus; die App ermittelt den bestätigten Serverstand. Bereits übertragene Blöcke werden nicht doppelt angehängt. Eine geänderte Datei benötigt einen neuen Upload. Datei freigeben entfernt nur die temporäre Datei.

get_artifact_status zeigt ohne artifactId alle aktuell erlaubten Dateien der eigenen Verbindung samt Quote. Mit ID liefert es den gezielten Status einschließlich receivedBytes, chunkBytes und nextOffset; null bedeutet, dass keine weiteren Uploadblöcke fehlen. Erst ready: true bestätigt die erfolgreiche Prüfung. So kann der Assistent einen im Browser hochgeladenen Entwurf finden, ohne seine Binärdaten zu lesen. Bestehende Chunk-Werkzeuge bleiben für programmatische Clients verfügbar. Lassen Sie Binärdateien nicht durch das Sprachmodell manuell in Base64 rekonstruieren.

Wählen Sie bei einer geprüften Datei Herunterladen. Die App prüft Größe und SHA-256, bevor sie den normalen Browserdownload startet. Ein MCP-Dateiabruf ersetzt keinen Nachweis der tatsächlich heruntergeladenen Datei.

Es gelten weiterhin 100 Dateien und 64 MiB reservierter Speicher je Nutzer/Mandant, maximal 23 Stunden beziehungsweise die kürzere Verbindungsdauer. Widerruf oder fehlende aktuelle Objektberechtigungen sperren den Zugriff. Eine andere Browseranmeldung übernimmt bestehende Dateien nicht automatisch. Upload und Download verändern keine aktive Vorlage; Test und bestätigte Freigabe folgen separat.

Offene Vorlagenarbeiten wiederaufnehmen

list_open_template_work zeigt bis zu zehn aktuell zugängliche Bearbeitungen mit Vorlagennamen, benannten Testfällen, Dateien, offenen Vorschlägen, aktiven Vergleichsreferenzen, Status und Ablaufzeit. Einzelne nicht mehr verfügbare Quellen verstecken keine anderen Arbeiten. In derselben gültigen Verbindung verwenden Sie die vorhandenen Bearbeitungs- und Datei-IDs weiter. Unvollständige Uploads können nur in dieser Verbindung fortgesetzt werden; eine Wiederaufnahme nach neuer Anmeldung kopiert ausschließlich finalisierte Eingaben.

Nach einer neuen Browseranmeldung genehmigen Sie zunächst eine neue OAuth-Verbindung mit mcp:read, mcp:files und mcp:data in dieser Browser-Sitzung. Öffnen Sie dann Integration → MCP-Verbindungen → Offene Arbeiten bei dieser neuen Verbindung. Wählen Sie die frühere Arbeit und den gewünschten DOCX-Entwurf ausdrücklich aus. Übernahme prüfen zeigt alle nötigen Eingaben einschließlich JSON-Testdaten und Quelldateien. Erst Diese Eingaben jetzt kopieren erstellt eine neue Bearbeitung und neue Datei-IDs. Ein Abbruch erzeugt keine Kopien; nach einem Antwortverlust kann derselbe Bestätigungsschritt wiederholt werden, ohne weitere Kopien zu erzeugen.

Die Übernahme ist nur im aktiven, nicht delegierten Browser desselben Nutzers und Mandanten möglich. Die neue Verbindung benötigt Lese-, Datei- und Datenfreigabe sowie aktuelle Vorlagenbearbeitungsrechte. Alle Quellen, Untermandantenrechte, Prüfsummen und Fristen werden erneut geprüft. Veränderte Vorlagen oder ein anderer wirksamer Untermandant erfordern eine neue Bearbeitung. Laufende Aufträge müssen zuerst einen stabilen Abschluss erreichen. Abgelaufene Vergleichsaufträge werden bei der Vorbereitung als unterbrochen behandelt; sie werden nicht automatisch neu gestartet.

Original, gewählter Entwurf und benötigte Eingabequellen erhalten neue IDs und unveränderte Bytes. Der ursprüngliche Bezugszeitpunkt für Rendering und Markenauflösung bleibt erhalten. Die neue Bearbeitung hat ihren tatsächlichen Erstellzeitpunkt; ihre Aufbewahrung endet spätestens mit der kürzesten ursprünglichen Quellfrist. Wiederholte Übernahmen verlängern diese Frist nicht. Die Bestätigung ist höchstens fünf Minuten gültig. Originale und Kopien zählen gemeinsam zur bestehenden Dateiquote (100 Dateien, 64 MiB); höchstens zehn Bearbeitungen bleiben offen.

PDF-Vorschauen, Vergleichsaufträge, alte Vorschläge und Freigaben werden nicht übernommen. Erstellen und prüfen Sie einen neuen Vergleich und danach einen neuen Änderungsvorschlag. Der Status alter Verbindungen bleibt unverändert. Widerrufene oder abgelaufene Verbindungen und Tokens werden nicht reaktiviert.

Frühere temporäre Arbeit verwerfen

Nach einer neuen Anmeldung können Sie eigene frühere Arbeit ausdrücklich bereinigen, ohne sie zuvor zu übernehmen. list_open_template_work zeigt dafür die Aufräumaktion. close_template_edit verwirft eine Bearbeitung einschließlich ihrer temporären Dateien; release_artifact verwirft eine eigene Datei und gegebenenfalls die zugehörige frühere Bearbeitung. Auch unvollständige Uploads können so entfernt werden. Die aktuelle Verbindung benötigt mcp:files; Nutzer und Mandant müssen übereinstimmen. Sind Quellenrechte entfallen, enthält die Anzeige nur Aufräum-IDs, keine Quellinhalte. Lesen und Bearbeiten bleiben an die ursprüngliche Sitzung gebunden.

Laufende Operationen müssen zuerst enden; ein Konflikt ist keine erfolgreiche Bereinigung. Erfolgreiches Verwerfen entlastet die Dateiquote, wird protokolliert und verändert keine gespeicherte Vorlage. Gemeinsam verwendete Testdateien werden beim Schließen einer einzelnen Bearbeitung nicht versehentlich mitgelöscht.

Sitzungsablauf und parallele Anmeldung

Der Ablauf oder Widerruf einer Verbindung sperrt den Zugriff sofort. Vorhandene Änderungsvorschläge bleiben innerhalb ihrer bisherigen Aufbewahrungsfrist im Browser für ihren Eigentümer und Mandanten sichtbar; dadurch wird die Verbindung nicht reaktiviert und keine Freigabefrist verlängert.

Bei paralleler Token-Erneuerung erhält derselbe Client für den unmittelbar vorherigen Refresh-Token innerhalb von weniger als 60 Sekunden dasselbe bereits ausgegebene Tokenpaar. Die angegebene Access-Token-Laufzeit nimmt entsprechend ab. Ältere Tokens, ein anderer Client, Ablauf, Widerruf oder geänderte Rechte bleiben gesperrt. Ab 60 Sekunden greift der Replay-Schutz. Betrieblich kann diese Ausnahme mit MCP_REFRESH_RETRY_GRACE_SECONDS auf 0–60 Sekunden begrenzt werden; 0 deaktiviert sie.