Bitten Sie einen KI‑Agenten, „die Servicevereinbarung für Contoso zu schreiben“, und er wird dies in seinen eigenen Worten, mit eigenen Überschriften und einer Summe, die er im Kopf ausgerechnet hat, tun. Das ist die falsche Arbeitsteilung. Mit GroupDocs.Assembly.Mcp, das lokal läuft (dnx GroupDocs.Assembly.Mcp --yes), fragt Claude Desktop, Cursor oder Copilot Ihre Word‑Vorlage, welche Felder sie benötigt, füllt sie aus Ihren Notizen und die Engine rendert den Vertrag, die Tabelle und die Berechnungen, ohne dass das Modell das Layout berührt:

Erstellen Sie die Servicevereinbarung für diesen Auftrag mit contract-template.docx und speichern Sie sie als PDF: Contoso Pharma, Keizersgracht 210 Amsterdam, Kontakt Dr. Lena Brandt; 12 Monate Managed Hosting zu 4.800 EUR, 12 Monate Support zu 1.200 EUR, ein Onboarding‑Workshop zu 3.500 EUR; 5 Prozent Rabatt.

Die schrittweise Version mit Konfiguration und Fehlersuche finden Sie in der Dokumentation: Wie man Dokumente aus Vorlagen mit KI‑Agenten mittels MCP erzeugt.

Warum sollte das Modell das Dokument nicht schreiben?

Weil ein generiertes Dokument auf Arten versagt, die schwer zu erkennen sind. Das Layout weicht vom rechtlich genehmigten ab. Eine Klausel wird paraphrasiert zu etwas, das gut klingt, aber etwas anderes bedeutet. Eine Summe entsteht durch Next‑Token‑Vorhersage statt durch Multiplikation. Und jeder Durchlauf ist ein wenig anders, sodass die Überprüfung des letzten Monats Ihnen nichts über den Vertrag dieses Monats sagt.

Eine Vorlage kehrt das um. Die Rechtsabteilung besitzt contract-template.docx mit ihren Überschriften, ihrem Signaturblock und ihren <<[customer.Name]>>‑Tags. Die Aufgabe des Modells reduziert sich auf das, worin es gut ist: das Lesen einer E‑Mail oder einer Reihe von Notizen und deren Umwandlung in strukturierte Werte. Die Engine erledigt den Rest, jedes Mal auf dieselbe Weise.

Wie weiß der Agent, was er ausfüllen muss?

Er fragt die Vorlage. get_template_fields liest die Tags, ohne die Engine auszuführen, und gibt die vom Template verwendeten Namen, jedes gelesene Feld und ein JSON‑Skelett zum Ausfüllen zurück. Das hat der Server für unsere Vertragsvorlage zurückgegeben:

-> get_template_fields {"template":{"filePath":"contract-template.docx"}}
<- { "tagCount": 17,
     "dataSourceNames": [ "contract", "customer", "items" ],
     "dataSkeleton": {
       "contract": { "Number": "", "Date": "", "Discount": "" },
       "customer": { "Name": "", "Address": "", "Contact": "",
                     "Email": "" },
       "items": [ { "Title": "", "Quantity": 0, "UnitPrice": 0 } ] } }

Dieses Skelett ist der Vertrag zwischen dem Modell und dem Dokument. Der Agent füllt es aus dem Auftrags­text und übergibt es zurück als dataJson.

Was passiert, wenn der Agent ein Feld vergisst?

Er wird genau darauf hingewiesen. In unserem Test ließ der erste Versuch des Agenten die E‑Mail‑Adresse des Kunden weg. Der Server lehnte ab und nannte die Lücke:

-> assemble_document {"template":{...},"dataJson":"{... no Email ...}"}
<- Document assembly failed for 'contract-template.docx': ...
   Can not get the value of member 'Email' on type ''. The template
   reads 'Email', which the data does not have. Check the spelling
   (names are case-sensitive) with get_template_fields and add it to
   the data. ... pass allowMissingMembers=true to output nothing for
   missing members and empty lists.

Ein Modell, das freien Text schreibt, hätte die Zeile stillschweigend weggelassen. Hier kann der Agent Sie nach der Adresse fragen oder mit Ihnen entscheiden, dass das Feld leer bleiben darf.

Der gesamte Austausch

user            agent                       Assembly MCP server
 | "Make the contract for this order: ..."                      |
 |-------------->|                                              |
 |               |-- get_template_fields {"template":          |
 |               |     "contract-template.docx"} ------------->|
 |               |<- dataSkeleton: contract, customer, items --|
 |               |   (fills the skeleton from the order text)  |
 |               |-- assemble_document {"dataJson":"{...}",    |
 |               |     "format":"pdf"} ----------------------->|
 |               |<- Saved to: .../contract-template_          |
 |               |   assembled.pdf ----------------------------|
 |<- "Contract ready: 3 items, total 75500 EUR, 5% discount."  |
   layout, table and arithmetic come from the template

Mit der hinzugefügten E‑Mail schlug der zweite Aufruf erfolgreich an:

-> assemble_document {"template":{"filePath":"contract-template.docx"},
     "dataJson":"{...}","format":"pdf"}
<- Assembled 'contract-template.docx' with inline JSON (JSON object)
   as PDF
   Saved to: .../contract-template_assembled.pdf

Das Dokument enthält eine dreizeilige Gebühren‑Tabelle, die durch ein <<foreach>> in der Tabellenzeile erzeugt wird, Beträge, die von der Vorlage berechnet werden (<<[item.Quantity * item.UnitPrice]>>), eine Summe von 75500 EUR aus items.Sum(...) und die Zeile „Ein Rabatt von 5 Prozent wird angewendet.“, die nur existiert, weil ein <<if>>‑Tag einen Rabatt in den Daten gefunden hat. Das Modell hat nichts davon berechnet.

Ist das besser als ein gehosteter Vorlagen‑Dienst?

Es ist ein anderer Kompromiss. Gehostete Vorlagen‑Dienste übernehmen Ihre Vorlage und Daten über HTTPS, rendern sie in ihrer Cloud und berechnen pro Dokument oder pro Credit. Hier bleiben Vorlage, Daten und Ausgabe in einem Ordner auf Ihrem Rechner; die Engine ist GroupDocs.Assembly, die im Prozess läuft, und es lauscht kein Port. Was zu Ihrem Modell‑Anbieter gelangt, ist der Auftrags­text, den Sie einfügen, und das vom Agenten ausgefüllte Skelett, nicht der gerenderte Vertrag. Die Architektur wird im Familien‑Beitrag zu On‑Premise‑KI‑Dokumentenverarbeitung beschrieben.

Ehrliche Grenzen

  • Evaluierungsmodus: jedes generierte Dokument beginnt mit der Zeile „Evaluation Only. Created with GroupDocs.Assembly 26.7…“, gespeicherte Arbeitsmappen erhalten ein zusätzliches Arbeitsblatt, und E‑Mail‑Vorlagen behalten nur ihren Nur‑Text‑Body. Eine Lizenzdatei oder nutzungsbasierte Schlüssel entfernen alle drei.
  • Die Vorlagensyntax ist <<[name]>>. {{name}}‑Platzhalter bleiben als Text; get_template_fields gibt das an.
  • Vorlagen sind vertrauenswürdige Eingaben: Bild‑ und Dokument‑Tags laden jeden Pfad oder jede URL, die ihr Ausdruck zurückgibt. Binden Sie einen Ordner für den Server ein.
  • Daten: schreiben Sie sie als 2026-11-12T00:00:00 und formatieren Sie sie in der Vorlage (<<[contract.Date]:"d MMMM yyyy">>). Ein reines Datum "2026-11-12" wird auf einer UTC+2‑Maschine in unserem Test als 11 November ausgegeben.
  • Der Agent ist die Datenquelle. Bitten Sie ihn, die extrahierten Werte aufzulisten, bevor er rendert, und prüfen Sie sie.

FAQ

Kann ein KI‑Agent meine Word‑Vorlage ausfüllen, ohne sie hochzuladen?
Ja. Der Server läuft lokal über stdio und liest die Vorlage aus dem von Ihnen konfigurierten Ordner; die Ausgabe wird daneben geschrieben.

Welche Formate kann die Vorlage haben?
Word, Excel, PowerPoint, Markdown, HTML, Text‑ und E‑Mail‑Vorlagen; jede kann in ihr eigenes Format oder in PDF und andere gespeichert werden. get_supported_formats listet sie pro Vorlage auf.

Was ist, wenn die Vorlage von jemand anderem gepflegt wird?
Genau das ist der Punkt. Wer die Vorlage besitzt, ändert Klauseln und Layout; der Agent füllt weiterhin dasselbe Skelett, und get_template_fields zeigt ihm jedes neue Feld beim nächsten Aufruf.

Weiterführende Informationen