List Package Attachments
Inventories every document attached to a package, across every run, with the role inferred for each file from its name, how many pages it has, and which run it arrived in.
Overview
Nobody uploads documents tidily. A package accumulates files over days and over several runs: the client emails a spreadsheet, somebody drops in last quarter's completed submission "for reference", a scanned letter arrives, then two more photos and a revised scope sheet. By the time the agent runs, the upload pile is a mixed bag with filenames like scan 0043 and FINAL v2 (1).
This tool is how the agent finds out what is actually there. It enumerates every attachment on the package — across every run, not just the current one — and reports, for each file, the role that was inferred for it from its filename, its file type and size, which run it arrived in, and, for a PDF, how many pages it has.
A flat scan and a fillable form look identical to a human scrolling past thumbnails, yet they lead to completely different work: one is a source to read from, the other may be a template to write into. Each PDF entry carries a finding on that — whether interactive form fields were found — though it is a hint rather than a verdict, for the reasons in Limits.
What It Does
| Capability | What it means for you |
|---|---|
| Complete inventory | Every document attached to the package, including files uploaded in earlier runs and files a workflow derived from an upload — not only today's batch, and not only what a person sent |
| Inferred role | Each file carries a role worked out from its filename, with a confidence value beside it |
| Page counts | How long each PDF is, which is what sizes per-page work later in the run — how many pages get carried through, and where they go |
| Interactive fields | Each PDF entry says whether interactive form fields were found in it |
| Cheap first pass | An overview of the whole pile without any document's text, so orientation costs little |
| Stable ground truth | The same inventory every run, so a second pass sees the same files plus whatever was added since |
When the Agent Chooses This Tool
All three workflows — appraisal, contractor pre-bid and coating QA — can call this, and in each of them it is step one, before anything else happens. It is the only tool all three share.
What each does with the answer is where they diverge:
- Which parts of the deliverable to build. In the appraisal workflow a section is only created when at least one of its mapped inputs shows up in the listing, and the page counts in the listing decide how many copies of the repeating parts are needed.
- Finding the one file that matters. The pre-bid workflow looks for the invitation to bid by role. The coating workflow looks for the spreadsheet by file extension and is told to ignore the role labels entirely, then goes on to read its records.
- Recognising a prior filled package. Where a file carries the role that marks it as an already-completed deliverable, the appraisal workflow splits that package so each part can feed the matching section. The trigger is the role label, not how the document reads.
- Deciding what a second run has to redo. Every entry says which run it arrived in. The pre-bid workflow compares that against the current run number and, when the file is not new, skips the whole stamp-parse-embed sequence rather than repeating it.
- Nothing useful at all. An empty inventory is a real answer, and two of the three workflows act on it directly: with no invitation, pre-bid stops and asks for one; with no spreadsheet, coating stops and asks for that. Appraisal does the opposite for an individual file — an expected document that is missing is skipped, not treated as a failure.
Filenames lie, and roles are inferred rather than declared — so the label on an entry is a starting point, not a conclusion.
Inputs and Outputs
Takes: nothing. The package being worked on is the one that gets listed; there are no options.
Returns: one entry per attached document, with its name, its file type and size, the role inferred for it and how confident that match was, which run it arrived in, and — for PDFs — its page count and whether interactive form fields were found.
Nothing is modified. No document's content is fetched, nothing is filled, and no section is created. The output is purely an orientation aid that the agent reasons over before it takes its first real action.
Example
A contractor pre-bid package, on its second run. The listing comes back with the invitation-to-bid PDF the contractor uploaded first time round, tagged with the role its filename earned it and marked as having arrived in run 1 — alongside the page images the first run derived from that same PDF, which are in the inventory too.
Because the invitation says run 1 and this is run 2, the agent knows the file is not new and skips the entire sequence it already performed on it. The page count on that same entry is what told the first run where the signoff block goes and which middle pages get carried into the deliverable; the filename on it is what the package was named after.
None of that was configured for this package. It came from one call that returned a handful of properties per file.
Limits
- Role comes from the filename. A name that matches a known pattern gets that role; anything else is labelled as unrecognised, and only for a PDF with readable text is the document's own text then used to guess. A misleadingly named file gets a misleading role, and an unusual one can be characterised wrongly.
- Roles belong to a workflow. The vocabulary was written for appraisal packages, and the coating workflow is instructed to disregard the labels for exactly that reason.
- It does not read content. The listing carries no text from any document. Finding a specific value means inspecting the individual attachment, which the appraisal and pre-bid workflows can do, or — for a spreadsheet in the coating workflow — reading its records.
- Page counts are for PDFs only. A spreadsheet, an image or a text file has no page count in the listing, and neither does a PDF that could not be opened.
- The interactive-fields finding is not a verdict. A PDF whose fields only begin further in can be reported as having none, and so can one that could not be read at all — and so is anything that is not a PDF, which reports no fields for the simple reason that it was never examined. All three look identical in the listing.
- It is scoped to one package. This lists what is attached to the package being worked on. It is not a search across a workspace or an account.
FAQ
Does the agent need to be told what each uploaded file is?
Partly, and it already is. The role on each entry is worked out from the filename when the file is stored, then read back here — the agent does not derive it. Each workflow's instructions also say what to look for before this call happens: the appraisal workflow lists the filenames it expects and what each one means, and the coating workflow says the spreadsheet is the file with a spreadsheet extension. What the listing supplies is which of those files are actually present, how long they are, and which run each arrived in.
Does it include files uploaded in previous runs?
Yes. The inventory covers every document ever attached to the package, not just the current run's uploads, and every entry says which run it arrived in. That is what lets a second pass see the files a reviewer added since, alongside the originals.
How does it tell a scanned PDF from a fillable one?
Each PDF entry reports whether interactive form fields were found in it, and that is all it reports on the question — a scan, an image-only export and a file that could not be opened all come back the same way. A document whose fields only begin further in can come back that way too. It is a hint worth having on a first pass, not a substitute for opening the file.
Does listing attachments read the text of every document?
No, and that is deliberate. This is a cheap first pass over the whole pile, and the entries carry file properties only — no document text. Reading content is a separate step, and each workflow's instructions name the cases that call for it rather than leaving it open: the appraisal workflow reads a package that has to be decomposed, the pre-bid workflow reads the invitation to find the date on it.
What happens if the roles are guessed incorrectly?
The listing is a starting hypothesis, not a verdict, and it says as much: every role comes with a confidence value, which is at its lowest when the filename matched no known pattern at all. A workflow can also disregard the labels entirely — the coating workflow is instructed to, because the vocabulary they come from was written for a different kind of package.