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.

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 Codex-App können Sie alternativ unter Einstellungen > MCP-Server einen Server mit HTTP-URL hinzufügen und die Anmeldung starten. 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 folgenden Erweiterungen sind auf Produktion freigegeben. Melden Sie Ihre Verbindung erneut an und genehmigen Sie die benötigten zusätzlichen Rechte. 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.“

Der Client bearbeitet die DOCX lokal; Output.Rocks liefert Datei, Kontext und Vorschauen über MCP 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.

Praktisch getestet: Codex. Claude/Cowork und GitHub Copilot in VS Code wurden nicht praktisch getestet.

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. Die konkrete Vorlagenversion und Testdaten mit list_entities auswählen. Bei gleichen Kennungen zuerst Marke und Untermandant klären; die Bearbeitung beginnt immer mit einer eindeutigen Versions-ID.
2. begin_template_edit mit templateId und testDataId aufrufen. Die Sitzung enthält die Original-DOCX, ihre Prüfsumme und einen festen Kontext.
3. get_template_edit_context vollständig in Abschnitten lesen. Der Kontext enthält Metadaten, Zuordnungen und Testdaten. get_template_syntax liefert die zugehörigen Syntaxhinweise; die Originaldatei bleibt vollständig erhalten.
4. render_template_edit ohne draftArtifactId erzeugt die Ausgangs-PDF. Der Client lädt die Originaldatei, bearbeitet sie und überträgt den Entwurf mit den oben beschriebenen Dateiwerkzeugen.
5. Derselbe Aufruf mit draftArtifactId rendert den Entwurf. Beide Fassungen verwenden den bestehenden Template-Editor, dieselben gespeicherten Testdaten und dasselbe Datum. Die PDF ist über read_artifact_chunk vollständig abrufbar.
6. Nach visueller Prüfung propose_template_update mit editId, draftArtifactId und einer konkreten summary aufrufen. Der zurückgegebene Freigabelink öffnet Original und Entwurf im Browser. Bis zur Entscheidung die Sitzung offen lassen.
7. close_template_edit beendet die Sitzung und entfernt Originalkopie, verwendete Entwürfe und Vorschau-PDFs. Nicht verwendete Uploads separat mit release_artifact entfernen.

Das Rendern speichert oder aktiviert keine Originalvorlage. Erst die Browserfreigabe übernimmt den Entwurf. Geänderte Vorlagenkonfigurationen führen zum Konflikt; starten Sie dann eine neue Sitzung. Pro Benutzer sind zehn Sitzungen und pro Sitzung zwanzig Vorschauen möglich; die allgemeinen Datei- und Ablaufgrenzen gelten weiter. Kontexte über 2 MiB werden ausdrücklich abgewiesen. Geheimnisse werden auch aus Testdaten entfernt.

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. Die bestehenden 14 Werkzeuge behalten ihr Verhalten. Claude/Cowork und GitHub Copilot in VS Code wurden für diesen Ablauf nicht praktisch getestet.

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.

Die praktische Client-Abnahme erfolgt mit Codex; Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet.

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. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet; die Client-Abnahme erfolgt mit Codex.

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.

Codex dient der praktischen Abnahme. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet.

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.

Die praktische Abnahme erfolgt mit Codex; Claude/Cowork und GitHub Copilot in VS Code werden nicht als praktisch getestet ausgewiesen.

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. Die praktische Client-Abnahme erfolgt mit Codex; Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet.

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.