Chiedi a un agente IA di “scrivere il contratto di servizio per Contoso” e lo farà, con parole proprie, con proprie intestazioni e con un totale calcolato nella sua testa. Questa è la divisione del lavoro sbagliata. Con GroupDocs.Assembly.Mcp in esecuzione locale (dnx GroupDocs.Assembly.Mcp --yes), Claude Desktop, Cursor o Copilot chiedono al tuo modello Word quali campi sono necessari, li compilano dalle tue note e il motore genera il contratto, la tabella e l’aritmetica inclusi, senza che il modello tocchi il layout:
Crea il contratto di servizio per questo ordine usando contract-template.docx e salvalo come PDF: Contoso Pharma, Keizersgracht 210 Amsterdam, contatto Dr. Lena Brandt; 12 mesi di hosting gestito a 4.800 EUR, 12 mesi di supporto a 1.200 EUR, un workshop di onboarding a 3.500 EUR; sconto del 5 percento.
La versione passo‑passo con configurazione e risoluzione dei problemi è nella documentazione: How to generate documents from templates with AI agents using MCP.
Perché il modello non dovrebbe scrivere il documento?
Perché un documento generato presenta errori difficili da individuare. Il layout si discosta da quello legalmente approvato. Una clausola viene parafrasata in qualcosa che suona bene ma significa altro. Un totale viene ottenuto dalla previsione del token successivo anziché da una moltiplicazione. E ogni esecuzione è leggermente diversa, quindi la revisione del mese scorso non ti dice nulla sul contratto di questo mese.
Un modello (template) inverte la situazione. Il reparto legale possiede contract-template.docx, con le sue intestazioni, il blocco di firma e i tag <<[customer.Name]>>. Il compito del modello si riduce alla parte in cui è bravo: leggere un’email o un insieme di note e trasformarle in valori strutturati. Il motore fa il resto, sempre allo stesso modo.
Come fa l’agente a sapere cosa compilare?
Chiede al modello. get_template_fields legge i tag senza eseguire il motore e restituisce i nomi usati dal modello, ogni campo che legge, e uno scheletro JSON da compilare. Questo è ciò che il server ha restituito per il nostro modello di contratto:
-> 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 } ] } }
Quel scheletro è il contratto tra il modello e il documento. L’agente lo compila dal testo dell’ordine e lo restituisce come dataJson.
Cosa succede quando l’agente dimentica un campo?
Viene avvisato, in modo preciso. Nel nostro test il primo tentativo dell’agente ha omesso l’indirizzo e‑mail del cliente. Il server ha rifiutato e ha indicato la lacuna:
-> 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.
Un modello che scrive testo libero avrebbe semplicemente omesso la riga. Qui l’agente può chiederti l’indirizzo, o decidere con te che il campo possa rimanere vuoto.
L’intera conversazione
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
Con l’e‑mail aggiunta, la seconda chiamata è riuscita:
-> 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
Il documento contiene una tabella delle tariffe a tre righe costruita da un <<foreach>> nella riga della tabella, importi calcolati dal modello (<<[item.Quantity * item.UnitPrice]>>), un totale di 75.500 EUR da items.Sum(...), e la frase “Si applica uno sconto del 5 percento.”, che esiste solo perché un tag <<if>> ha trovato uno sconto nei dati. Il modello non ha calcolato nulla di tutto ciò.
È meglio di un servizio di template ospitato?
È una scelta diversa. I servizi di template ospitati ricevono il tuo modello e i dati via HTTPS, li rendono nel loro cloud e addebitano per documento o per credito. Qui il modello, i dati e l’output rimangono in una cartella sul tuo computer; il motore è GroupDocs.Assembly in esecuzione in‑processo, e nulla ascolta su una porta. Ciò che viene inviato al provider del modello è il testo dell’ordine che incolli e lo scheletro che l’agente compila, non il contratto renderizzato. L’architettura è descritta nel post della famiglia su on-premise AI document processing.
Limiti onesti
- Modalità valutazione: ogni documento generato inizia con la riga “Evaluation Only. Created with GroupDocs.Assembly 26.7…”, i workbook salvati ottengono un foglio di lavoro extra, e i modelli e‑mail mantengono solo il corpo in testo semplice. Un file di licenza o chiavi a consumo rimuovono tutti e tre.
- La sintassi del modello è
<<[name]>>. I segnaposto{{name}}rimangono come testo;get_template_fieldslo indica. - I modelli sono input fidato: i tag immagine e documento caricano qualsiasi percorso o URL restituito dalla loro espressione. Monta una cartella per il server.
- Date: scrivile come
2026-11-12T00:00:00e formattale nel modello (<<[contract.Date]:"d MMMM yyyy">>). Una data solo"2026-11-12"viene stampata come 11 novembre su una macchina UTC+2 nel nostro test. - L’agente è la fonte dei dati. Chiedigli di elencare i valori estratti prima di renderizzare e rivedili.
FAQ
Un agente IA può compilare il mio modello Word senza caricarlo?
Sì. Il server gira localmente su stdio e legge il modello dalla cartella che configuri; l’output viene scritto accanto ad esso.
Quali formati può avere il modello?
Word, Excel, PowerPoint, Markdown, HTML, testo e modelli e‑mail; ciascuno può essere salvato nel proprio formato o in PDF e altri. get_supported_formats li elenca per modello.
E se il modello è gestito da qualcun altro?
Questo è il punto. Chiunque possieda il modello modifica clausole e layout; l’agente continua a compilare lo stesso scheletro, e get_template_fields gli mostra eventuali nuovi campi la prossima volta che chiede.
Approfondisci
- Documentazione, guida canonica: Come generare documenti da modelli con agenti IA usando MCP
- Da un’email o note a un documento: Come trasformare note o un’email in un documento finito con un agente IA
- Hub di documentazione: GroupDocs.Assembly MCP Server
- Correlato: Cento PDF personalizzati da un unico prompt: unione di posta con un agente IA
- Correlato: Di cosa ha bisogno questo modello? Chiedilo.
- Correlato: Il grafico proviene dal modello, i numeri dai dati
- Correlato: Il tuo repository ha già i dati; lascia che l’agente crei il PDF
- Novità del motore: GroupDocs.Assembly for .NET 26.7
- On‑premise e modello di sicurezza: 3 architetture per l’elaborazione di documenti IA, e quella che mantiene i file all’interno della tua rete
- Domande: GroupDocs Assembly forum
- Fonte: GroupDocs.Assembly.Mcp on GitHub · pacchetto NuGet