How to batch-compare document versions in a folder
Leave feedback
On this page
One prompt, a folder of version pairs, no uploads. The agent loops; the engine compares each pair locally; you get one consolidated report.
Note
The commands and config snippets on this page are for the .NET build of the server — the only platform available today. Installation and client setup: MCP server for .NET. Other platforms will expose the same tools with their own launch command; everything else on this page applies unchanged.
Setup
Name the pairs so the agent can match them. Any consistent convention works:
Point GROUPDOCS_MCP_STORAGE_PATH at that folder — configuration.
The prompt
For every -v1/-v2 pair in my documents folder, compare the two and tell me which invoices changed and how. One line per invoice.
The agent calls analyze_changes once per pair and reports each result. Use analyze_changes here rather than compare: a sweep over thirty pairs that renders thirty marked-up documents nobody opens is thirty times the work for the same answer.
Getting files for the ones that matter
Now produce marked-up copies for the three that changed.
The agent calls compare for just those three. Each result lands in your output folder as <source-stem>_compared<ext>; existing files are never overwritten — a new name is used instead.
Practical notes
Files are resolved by name from the storage folder, so the agent passes invoice-001-v1.pdf, not a full path from your machine.
A missing or mistyped name is not fatal — the tool answers with the list of files it can see, and the agent corrects itself and retries.
Compare like with like. Both files in a pair should be the same format; convert first if they are not (Conversion MCP server).
Mind the evaluation cap — two pages per document until a license is applied, which on a batch means a quietly incomplete report. Check with get_license_status before trusting a sweep.
Long sweeps take time. Each pair is a real comparison by a real engine; a folder of large PDFs is minutes, not seconds. Ask for progress as it goes rather than one silent batch.
Where this goes next
Sweeps like this are how teams check that a re-issued batch matches what was approved, that a vendor’s “unchanged” statements really are unchanged, and that a migration produced the same documents it started with — all without a single file leaving the machine (architecture).
Was this page helpful?
Any additional feedback you'd like to share with us?
Please tell us how we can improve this page.
Thank you for your feedback!
We value your opinion. Your feedback will help us improve our documentation.