MCP server › Sample workflows
Quarterly capacity review
The report an operator reads before buying storage: how much has been collected, which accounts are the biggest, and does that dashboard number actually agree with what is in the search index? A dashboard figure that disagrees with the index is worse than no figure at all, so the workflow ends by proving the two views match. The sample runs against the DataTap-hosted Enron corpus (6 collected Exchange mailboxes, one OneDrive account). Read-only throughout.
The tool sequence
Step 1 reports Exchange capacity and its account breakdown. Step 2 repeats it for OneDrive. Steps 3–5 use the search index to independently verify the dashboard's numbers rather than taking them on faith:
// 1 · Total bytes collected on the Exchange connector, plus the
// per-account breakdown, largest first.
{"tool": "get_collection_stats", "arguments": { "connector": "EXCHANGE" }}
// → { connector, totalBytes, largestAccounts: [{ DisplayName, NumberOfFiles, TotalFileSize }, …] }
// 2 · Same call for the OneDrive connector.
{"tool": "get_collection_stats", "arguments": { "connector": "ONEDRIVE" }}
// 3 · Drill-down: prove the dashboard's biggest account is really the
// biggest thing in the index, by document count.
{"tool": "summarize_content", "arguments": { "facets": "ownerId,count:10" }}
// → the ownerId with the highest count should be the account ranked #1
// in step 1's largestAccounts.
// 4 · Confirm that owner's identity via a sending address, rather than
// trusting a mailbox guid that can change on reprovisioning.
{"tool": "count_content", "arguments": {
"filter": "ownerId eq '<owner-id-from-step-3>' and fromAddress eq '<expected-address>'"
}}
// 5 · Cross-check every account row at once: the per-account file counts
// in get_collection_stats must equal the per-owner message counts
// in the index, compared as a set rather than by name or guid.
{"tool": "summarize_content", "arguments": {
"filter": "itemType eq 'MessageItem'",
"facets": "ownerId,count:10"
}}Results — Exchange account breakdown
get_collection_stats normalizes the underlying TotalEmailsSize/TotalFileSize split into a single totalBytes figure (1,210,402,156 bytes across the connector) and returns largestAccounts pre-sorted by size, not by file count — Fletcher Sturm has fewer files than Mike Maggi but outranks him because his files are larger on average:
| Account | Files | Total size |
|---|---|---|
| Darron C Giron | 4,802 | 753,612,012 |
| V Charles Weldon | 2,168 | 187,003,916 |
| Fletcher J. Sturm | 1,730 | 85,362,724 |
| Jay Reitmeyer | 892 | 75,271,298 |
| Mike Maggi | 1,881 | 69,416,981 |
| Eric Linder | 974 | 39,735,225 |
The OneDrive connector reports one account (Viewer, 925 files) against a connector total of 71,884,174 bytes.
Verifying against the index
Darron Giron's account leads the Exchange breakdown, and faceting the index on ownerId confirms the same mailbox owns the most documents in the corpus — 4,802 of them, matching largestAccounts[0].NumberOfFiles exactly. Repeating the facet scoped to itemType eq 'MessageItem' and comparing the six resulting counts against the six dashboard rows, as sets rather than by name, confirms every account reconciles: the six owners in the index account for all 12,447 collected messages, with no mailbox over- or under-counted on either side.
get_collection_stats calls on a schedule and diff the totalBytes figures to track growth per connector over time, or add SHAREPOINT/TEAMS once those connectors have collected content of their own.← Previous sample: Top conversation pairs · Back to MCP server →