A document pack, such as a board pack, a bid pack or a closing binder, can be assembled by an AI agent in a fixed order from one standing prompt, with the files merged locally on your machine. The order comes from your file names, the agent runs the merge in rounds, and you verify the result before it is sent:

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 step-by-step version with config and troubleshooting is in the documentation: How to assemble a document pack with an AI agent.

Why do document packs go wrong?

A pack has the same shape every time: a fixed order, more than four parts, and a deadline. The failures are also the same. A part is missing, two parts are swapped, or the final file was assembled from an older version of one section.

An agent that is told “put the files together” has to guess the order from the wording of your sentence. An agent that is given an ordering rule it can check does not. Automation here means removing the guess, not removing the person.

What is the workflow, step by step?

  1. Name the files so the order is obvious. Use a numeric prefix.
  2. Check the license first. Ask the agent for the license status.
  3. Run the assembly in rounds. The merge tool takes at most four documents per call.
  4. Verify the page count. Compare the result with the sum of the parts.
  5. Convert, mark and clean in separate steps. Other MCP servers handle those.

Step 1: Name the files so the order is obvious

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 ambiguity about sequence for you and for the agent. This is the enforcement mechanism: the rule lives in the folder, so the prompt can stay the same from one month to the next. Before a repeat run, set GROUPDOCS_MCP_OUTPUT_PATH to a separate folder. By default, outputs are saved in the storage folder, so last month’s pack and the intermediate results from each round would be picked up by “every PDF in my documents folder”.

Step 2: Check the license before a real run

What is the license status of the merger server?

The agent calls get_license_status, which takes no arguments and modifies nothing. In evaluation mode the result of every merge is trimmed to the first 3 pages, with a trial badge on each page, and nothing in the output says so.

Step 3: Run the assembly in rounds

Use the standing prompt shown at the top. With the six files above, the agent calls merge twice: files 00 to 03 produce an intermediate result, and that result plus files 04 and 05 produces the final pack. More parts simply mean more rounds. Order is slot order (file1 first, file4 last), so a chained round puts the previous result in the first slot.

Step 4: Verify the page count

How many pages does the final pack have?

get_document_info returns pageCount for the result. A part that went missing shows up as a count that is too low. A pack whose parts add up to many pages but which reports 3 was produced without a license.

Step 5: Convert, mark and clean in separate steps

Not every part is a PDF, and a pack usually needs more than assembly. merge accepts one format family per call, so convert Word sections to PDF first with GroupDocs.Conversion.Mcp. Other servers in the family can then mark the pack with a watermark (GroupDocs.Watermark), sign it (GroupDocs.Signature) or strip metadata (GroupDocs.Metadata). Each is a separate server with the same install pattern. If the pack needs a digital signature, apply it last: any later change, including a watermark or a metadata strip, invalidates it.

What does the agent decide, and what does the engine do?

Step Agent Engine
Pick the files Lists the folder and reads the numeric prefixes Resolves each name in the storage folder
Plan the rounds Groups the files four at a time Nothing
Merge Calls merge with files in slot order Combines the documents and saves the result
Chain Passes the previous result into the next call Combines it with the next files
Verify Calls get_document_info and compares counts Returns the page count

The engine never decides the sequence; it honors the slots it is given. That is why the naming rule matters.

Example session (abridged)

An illustration based on the documented tool behavior, not a captured screenshot.

You:   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.

Agent: Found 6 PDFs, 00-cover.pdf to 05-annexes.pdf.
       [calls merge: 00-cover, 01-summary, 02-body, 03-appendix-a]
       [calls merge: previous result, 04-appendix-b, 05-annexes]
       The final pack is saved in your output folder. I can check its
       page count against the six parts if you like.

Honest limits

  • Evaluation mode trims the pack to 3 pages. The result is trimmed to the first 3 pages, with a trial badge on each page. A multi-part pack merged without a license comes back as three pages and looks finished. Check get_license_status first, and compare page counts afterward.
  • Four documents per call. Rounds are the way around it; the agent has to be asked to chain them.
  • One format family per merge. Convert mixed parts first.
  • The order rule is a convention, not a lock. If a file is misnamed, the pack is misordered. The page-count check catches missing parts, not swapped ones.

FAQ

How do I combine multiple documents into one PDF in a set order? Put a numeric prefix on the file names and ask the agent to merge them in file-name order, four at a time. The merge tool honors the order of its file1 to file4 inputs.

Can an AI agent create a board pack every month? Yes. Keep the same naming convention and reuse the same prompt, with GROUPDOCS_MCP_OUTPUT_PATH pointing to a separate folder (or the previous outputs cleared) so old packs are not merged in again. Then verify the page count of the result each time.

What if some parts are Word files? Convert them to PDF first with GroupDocs.Conversion.Mcp, then merge. With both servers registered, it is one conversation.

Go deeper