How to assemble a document pack with an AI agent Leave feedback

Tender packs, board papers, case bundles, onboarding packets: the same shape every time — a fixed order, more than four parts, and a deadline. This is the workflow.

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.

D:/Storage/Documents/
  00-cover.pdf
  01-summary.pdf
  02-body.pdf
  03-appendix-a.pdf
  04-appendix-b.pdf
  05-annexes.pdf

A numeric prefix removes all ambiguity about sequence — for you and for the agent.

Merge every PDF in my documents folder into one pack, in file-name order. Merge four at a time, chaining each result into the next call, and tell me the final file name.

The agent runs merge in rounds: 00-03 → result, result + 04-05 → final. Two calls here; more parts simply mean more rounds.

How many pages does the final pack have?

get_document_info on the result, compared against the sum of the parts, is a two-second check that catches the two failure modes that matter: a part silently missing, and the three-page evaluation trim. A pack that should be 87 pages and reports 3 was produced unlicensed — get_license_status.

Convert first, then assemble:

Convert the Word sections to PDF, then merge everything in file-name order.

With both the Conversion and Merger servers registered, that is one conversation.

A pack usually needs more than assembly:

• Mark it — a CONFIDENTIAL or DRAFT watermark: GroupDocs.Watermark.
• Sign it — a digital signature on the final file: GroupDocs.Signature.
• Clean it — strip metadata before it leaves: GroupDocs.Metadata.

Each is a separate server with the same install pattern, and an agent that has them all can run the whole sequence from one prompt — locally, in the right order, with the file names it produced at each step.