Casepoint

OUTPUT FORMAT — READ FIRST ══════════════════════════ Present results as concise Markdown tables; never paste raw JSON. Render zero counts as "0"; missing avg-days as "—". Use EXACTLY these column headers (copy character-for-character): component_abbreviation → "Agency/Component" total_requests_received → "Total Requests Received" total_requests_closed → "Total Requests Closed" fee_waivers_granted → "Fee Waivers Granted" fee_waivers_denied → "Fee Waivers Denied" avg_processing_days_simple → "Avg Processing Days (Simple)" avg_processing_days_complex → "Avg Processing Days (Complex)" avg_processing_days_expedited → "Avg Processing Days (Expedited)" avg_processing_days → "Avg Processing Days" previous_fy_backlogged_requests → "Previous Fiscal Year Backlogged Requests" current_fy_backlogged_requests → "Current Fiscal Year Backlogged Requests" fiscal_year → "Fiscal Year" (caption/heading — NOT a column) USE EXACT HEADERS — DO NOT PARAPHRASE, ABBREVIATE, OR REWORD ══════════════════════════════════════════════════════════════ Copy header strings character-for-character — capitalization, parentheses, spacing. Do NOT expand "Avg" to "Average", swap parentheses for colons, or add/drop words. FORBIDDEN variants: "Requests received", "Fee waivers granted", "Avg processing days (simple)", "Average Processing Days", "Backlog", "Current Year Backlogged", "Total Received". PURPOSE ═══════ Returns FOIA Annual Report aggregate metrics for a fiscal year, broken out by Agency/Component. All three families — FOIA, Appeal, Consultation — are always returned in a single call. Call this tool ONCE; no routing or multi-call logic is needed. AGENCY/COMPONENT DIMENSION ══════════════════════════ Every row carries a `component_abbreviation` (the short code, e.g. "NE"). Render it VERBATIM in the "Agency/Component" column — never use the full component name. Rows are per component. The default (no `component` argument) returns EVERY reportable component, each on its own row. When the user names one or more components, pass them via the `component` argument (comma-separated abbreviations, exact/case-insensitive); only those components' rows come back. AGENCY OVERALL ROW: Each family includes a synthetic total row with `component_abbreviation = "Agency Overall"` — the agency-wide roll-up. Render it as the LAST row in each family table. Do NOT drop it or move it. ROUTING — USE request_type_name FOR GROUPING ONLY, NEVER RENDER AS A COLUMN ═════════════════════════════════════════════════════════════════════════════ The response's `by_request_type` list contains rows for all three families. Each row has a `request_type_name` field — use it ONLY to route each row to the correct table: • "FOIA" → "### FOIA" table • "Appeal" → "### Appeal" table • "Consultation" → "### Consultation" table Do NOT render `request_type_name` as a column. It is internal routing data. THREE TABLES — ALWAYS, IN THIS ORDER ═════════════════════════════════════ Always produce exactly THREE separate Markdown tables, each with its own heading. Place "Fiscal Year: <value>" as a caption ABOVE the tables. 1. ### FOIA 2. ### Appeal 3. ### Consultation COLUMN SETS (fixed per family — never add or remove columns) ══════════════════════════════════════════════════════════════ ### FOIA — exactly 10 columns, in this order: (1) Agency/Component (2) Previous Fiscal Year Backlogged Requests (3) Total Requests Received (4) Total Requests Closed (5) Fee Waivers Granted (6) Fee Waivers Denied (7) Avg Processing Days (Simple) (8) Avg Processing Days (Complex) (9) Avg Processing Days (Expedited) (10) Current Fiscal Year Backlogged Requests ### Appeal — exactly 6 columns, in this order: (1) Agency/Component (2) Previous Fiscal Year Backlogged Requests (3) Total Requests Received (4) Total Requests Closed (5) Avg Processing Days (6) Current Fiscal Year Backlogged Requests NO fee-waiver columns. NO per-track Avg Processing Days columns. ### Consultation — exactly 3 columns, in this order: (1) Agency/Component (2) Total Requests Received (3) Total Requests Closed NO Backlogged Requests columns (DOJ does not track Backlogged Consultations). NO Avg Processing Days. NO Fee Waivers. HARD CONSTRAINTS — VIOLATIONS ARE REJECTED ═══════════════════════════════════════════ 1. NEVER render `request_type_name` as a column — it is routing data only. 2. NEVER emit ONE combined table with families as rows and metrics as columns. 3. NEVER pivot into a Metric/Value layout — rows are components, columns are metrics. 4. NEVER drop columns because values are zero or missing — render "0" (counts) or "—" (avg-days with no eligible closed rows). 5. NEVER reorder columns. 6. ALWAYS render the "Agency Overall" row LAST in each family table. 7. The FOIA table has EXACTLY 10 columns — no more, no less. 8. The Appeal table has EXACTLY 6 columns — no more, no less. 9. The Consultation table has EXACTLY 3 columns — no more, no less. 10. Each COLUMN is its OWN Markdown column with its OWN header cell. "Fee Waivers Granted" and "Fee Waivers Denied" are TWO separate columns. "Avg Processing Days (Simple)", "(Complex)", "(Expedited)" are THREE separate columns for FOIA. Forbidden layout (pivoted families as rows): | Metric | FOIA | Appeal | Consultation | |---------------------|------|--------|--------------| | Requests received | 593 | 69 | 26 | Forbidden layout (pivoted Metric/Value): | Metric | Value | | Requests received | 593 | CONCRETE LAYOUT STRUCTURE (copy this shape, substitute actual values) ══════════════════════════════════════════════════════════════════════ ### FOIA | Agency/Component | Previous Fiscal Year Backlogged Requests | Total Requests Received | Total Requests Closed | Fee Waivers Granted | Fee Waivers Denied | Avg Processing Days (Simple) | Avg Processing Days (Complex) | Avg Processing Days (Expedited) | Current Fiscal Year Backlogged Requests | |------------------|------------------------------------------|-------------------------|-----------------------|---------------------|--------------------|------------------------------|-------------------------------|---------------------------------|------------------------------------------| | <abbr> | <prev_backlog> | <received> | <closed> | <granted> | <denied> | <avg_s> | <avg_c> | <avg_e> | <curr_backlog> | | Agency Overall | <prev_backlog> | <received> | <closed> | <granted> | <denied> | <avg_s> | <avg_c> | <avg_e> | <curr_backlog> | ### Appeal | Agency/Component | Previous Fiscal Year Backlogged Requests | Total Requests Received | Total Requests Closed | Avg Processing Days | Current Fiscal Year Backlogged Requests | |------------------|------------------------------------------|-------------------------|-----------------------|---------------------|------------------------------------------| | <abbr> | <prev_backlog> | <received> | <closed> | <avg> | <curr_backlog> | | Agency Overall | <prev_backlog> | <received> | <closed> | <avg> | <curr_backlog> | ### Consultation | Agency/Component | Total Requests Received | Total Requests Closed | |------------------|-------------------------|-----------------------| | <abbr> | <received> | <closed> | | Agency Overall | <received> | <closed> | NOTES (always append after the tables) ═══════════════════════════════════════ Always append a "Notes" section below the tables: • "The FOIA rows include Privacy Act (PA), Combined FOIA and PA, and every FOIA-derived custom request type in their counts." • "The Appeal rows include every Appeal-derived custom request type in their counts." • "Consultation has no derived custom types — its numbers are the base type alone." • "Fiscal year runs Oct 1 – Sep 30. Figures come from the CP FOIA annual-report pre-aggregated tables and match the corresponding DOJ FOIA Annual Report sections." VALUE RENDERING ═══════════════ Render every value EXACTLY as it appears — do NOT sanitize, truncate, or replace. `component_abbreviation` can contain any character — put it in the cell unchanged. Escape Markdown-active characters that would break the table (a pipe `|` → `\|`). Do NOT show request_type_id or component_id anywhere — not in cells, columns, footnotes, or legends. WHAT THIS TOOL COUNTS ═════════════════════ Metrics come from pre-aggregated CP FOIA annual-report tables: • Total received and total closed — all three families • Fee waivers granted / denied — FOIA family only • Avg processing days per track (Simple / Complex / Expedited) — FOIA family • Avg processing days (overall) — Appeal family • Current / Previous Fiscal Year Backlogged Requests — FOIA and Appeal families (Consultation excluded) Tasks and Reports are never counted. Litigation is excluded entirely. Row ordering: components sorted by creation order (c_componentid ASC); "Agency Overall" last. Inputs: - fiscal_year — 4-digit fiscal year (e.g. 2026). Optional — defaults to the current federal fiscal year (Oct 1 – Sep 30). FISCAL YEAR CALL RULE: Make ONE call per fiscal year. • User specifies a year ("2025 annual report", "FY2024 data") → call once with that year. Do NOT also call for the current FY. • User says "current year" or omits a year → omit fiscal_year (defaults to current FY). Do NOT guess or supply a year. • User explicitly asks for multiple years → make one sequential call per year, presenting results year by year. Never combine years into a single call. - component — Agency/Component filter by component ABBREVIATION (short code, e.g. "NE"), matched EXACTLY and case-insensitively — NOT the full component name. Pass a single abbreviation or a comma-separated list ("NE, SW"). OMIT (or pass empty) to get EVERY component (one row per component, the default). Unknown abbreviations return no rows for that abbreviation. ERROR RESPONSES ═══════════════ When the report cannot be produced (fiscal year out of range, component too long, backend timeout, etc.), the tool surfaces a single message. Present it as plain text (do not wrap in a JSON block) and do not retry unchanged. SELF-CHECK before emitting the answer: 1. Did I call this tool ONCE? (Single call always — no routing needed.) 2. Did I use `request_type_name` ONLY to group rows into the three tables, not render it? 3. Are the FOIA / Appeal / Consultation tables each under their own "### " heading? 4. Does FOIA have exactly 10 columns? Appeal 6? Consultation 3? 5. Did I drop any column because values are all zero? Put it back with "0". 6. Is "Agency Overall" the last row in each family table? 7. Am I emitting a pivoted Metric/Value layout? Replace it with the column-per-metric layout. The first column in every table is ALWAYS "Agency/Component". Do NOT add "Request Type" as a column — it was deliberately removed. Do NOT add any column not listed in the family's declared set above.

get_annual_report

Custodian collection report for the connected eDiscovery workspace, grouped by custodian. Returns one entry per custodian (titled by custodian email) with the custodian-level roll-up — total documents collected, the data sources covered (email, OneDrive, Teams, Slack, mobile, archived mailboxes, shared drives, …), the collected data volume (GB/TB), and the file types collected — PLUS a per-datastore breakdown under "Data Stores": one entry per datastore the custodian has documents in, each carrying that datastore's own document count, date range, data sources, collected volume, and file types. Every custodian is returned even with no collected documents (empty breakdown). Use this when the user asks things like: "custodian collection report", "what did we collect per custodian", "collection volume by custodian", "data sources per custodian", "how much did each custodian contribute per datastore", "per-datastore breakdown by custodian". The optional date range filters by the collected document date; omit for all time.

get_custodian_collection_summary

The people (custodians) placed on ONE named legal hold — the hold's roster — including each person's directory information and hold-notification status, plus any custom fields configured for custodians (under customFields). Pass the exact hold name from get_legalhold_list. This tool returns each custodian's hold-notification status — whether they were added to the hold, notified (notice sent), and how they responded. A custodian is "on a legal hold" when they appear on the hold's roster (any HoldStatus value). CUSTODIAN HOLD STATUSES — meanings: • added — placed on the hold roster; no notice has been sent yet • sent — a hold notice was delivered to the custodian; awaiting their response • accepted — the custodian acknowledged and accepted the hold notice • rejected — the custodian declined / rejected the hold notice • released — the custodian has been removed from the hold • silent — added to the hold without any notice being sent (silent hold) CRITICAL DISTINCTION — hold-notification status ≠ data-preservation status: • HoldStatus (this tool) tracks whether the custodian was notified about the hold. A custodian with status 'accepted' has acknowledged the notice — this does NOT mean their data is preserved. • PreservationStatus (use get_legalhold_preservation_collections) tracks whether the custodian's actual data (emails, files, chats) is being preserved in the cloud system. Do NOT use this tool to answer questions about data preservation progress. PAGINATION RULES — follow strictly: • Sequential only. Start with navigate='first'. To move forward, call again with navigate='next' and current_page set to the 'page' value from the previous response; navigate='previous' goes back one step. You can move only ONE step at a time and CANNOT jump to an arbitrary page. • If the user asks for a specific page ("give me page 3", "go to page 5", "show page -1"), do NOT attempt it. Respond: "I can only move to the next or previous set of records, not jump directly to a specific page. Would you like me to continue with the next set?" • NEVER expose page structure to the user — no page numbers, no "page 1 of 3", no "more pages", no total page/record counts. The 'page' value is for your internal use as current_page only. • If hasMore=true, end with a simple offer and nothing more: "Would you like me to show the next set of records?" If hasMore=false, tell the user this is the end of the list and do NOT offer a next set. • Never pass a raw user-supplied page number into this tool. Pick a different tool when: the user wants ALL custodians org-wide (use get_people), or the hold's settings/roles rather than its people (use get_legalhold_details). RESPONSE PRESENTATION — how to show this result to the user: • The result is JSON for YOU to read; do NOT paste or display the raw JSON to the user. • Present results as a concise Markdown table/summary. • Keep the answer concise and human-readable, and offer to show more detail on request.

get_legalhold_custodians

Full briefing for ONE named legal hold: status, start/end/reminder/issued dates, matter and workspace, admin, issuer, total custodian count, every role assigned to the hold with its View or Edit permission, and any custom fields configured for the hold (under customFields). Use this when the user asks things like: "tell me about the Smith hold", "details of hold X", "what's the status/dates of hold X", "who has access to this hold and what can they do", "what roles/permissions are on hold X", "verify the settings of hold X". Pass the exact hold name from get_legalhold_list. Pick a different tool when: the user wants the LIST of holds (use get_legalhold_list), the custodians/people on the hold (use get_legalhold_custodians), or preservation progress (use get_legalhold_preservation_collections). RESPONSE PRESENTATION — how to show this result to the user: • The result is JSON for YOU to read; do NOT paste or display the raw JSON to the user. • Present results as a concise Markdown table/summary. • Keep the answer concise and human-readable, and offer to show more detail on request.

get_legalhold_details

Lists all legal holds in the connected Casepoint organization. A legal hold (a.k.a. hold, litigation hold, preservation notice, retention notice, "hold notice") is an instruction to preserve data for a matter. Returns each hold's name, matter name/number, description, status, custodian counts by notification state, start/end/issued dates, admin, issuer, and workspace. HOLD STATUS: Valid values are 'Active' ,'Inactive' and 'Draft'. The custodian count fields (AddedCustodians, SentCustodians, AcceptedCustodians, RejectedCustodians, ReleasedCustodians, SilentCustodians) reflect hold-notification state only — they say nothing about whether data is being preserved. Use this when the user asks things like: "what holds do we have", "show me our legal holds", "list litigation holds", "any active holds", "do we have a hold on matter X". This is usually the STARTING POINT — it returns hold names you then pass to the detail, roster, or preservation tools. PAGINATION RULES — follow strictly: • Sequential only. Start with navigate='first'. To move forward, call again with navigate='next' and current_page set to the 'page' value from the previous response; navigate='previous' goes back one step. You can move only ONE step at a time and CANNOT jump to an arbitrary page. • If the user asks for a specific page ("give me page 3", "go to page 5", "show page -1"), do NOT attempt it. Respond: "I can only move to the next or previous set of records, not jump directly to a specific page. Would you like me to continue with the next set?" • NEVER expose page structure to the user — no page numbers, no "page 1 of 3", no "more pages", no total page/record counts. The 'page' value is for your internal use as current_page only. • If hasMore=true, end with a simple offer and nothing more: "Would you like me to show the next set of records?" If hasMore=false, tell the user this is the end of the list and do NOT offer a next set. • Never pass a raw user-supplied page number into this tool. Note: takes no hold id (none are exposed); other tools are driven by the hold NAME returned here. For one hold's full settings use get_legalhold_details; for its people use get_legalhold_custodians. RESPONSE PRESENTATION — how to show this result to the user: • The result is JSON for YOU to read; do NOT paste or display the raw JSON to the user. • Present results as a concise Markdown table/summary. • Keep the answer concise and human-readable, and offer to show more detail on request.

get_legalhold_list

Preservation & collection activity under ONE named legal hold — one row per custodian per data source. Shows custodian name/email, cloud type, media type/label, overall and per-source preservation status (mail / drive or sites / chat / SharePoint), collection status, authorization status, preservation & collection dates and locations, collection size, workspace, descriptions, employment status, and any custom fields configured for the data source (under customFields). This is "what data is actually being held / collected" for the hold. KEY DISTINCTION — two separate status fields in each row: • PreservationStatus — whether the custodian's DATA is being preserved (NotStarted / InProgress / Preserved / Failed / Released / Ignored). This answers "is their data actually on hold in the cloud system?" • HoldStatus — the custodian's hold-NOTIFICATION status (added / sent / accepted / rejected / released / silent). This answers "were they notified about the hold?" A custodian can have HoldStatus='accepted' (acknowledged the notice) but PreservationStatus='NotStarted' (data not yet preserved) — these are independent. Use PreservationStatus to answer questions about data preservation progress. Use this when the user asks things like: "what's being preserved for hold X", "preservation status for X", "collection progress / status", "has custodian Y's data been collected", "what sources are on hold for X", "how much has been collected". Pass the exact hold name from get_legalhold_list. PAGINATION RULES — follow strictly: • Sequential only. Start with navigate='first'. To move forward, call again with navigate='next' and current_page set to the 'page' value from the previous response; navigate='previous' goes back one step. You can move only ONE step at a time and CANNOT jump to an arbitrary page. • If the user asks for a specific page ("give me page 3", "go to page 5", "show page -1"), do NOT attempt it. Respond: "I can only move to the next or previous set of records, not jump directly to a specific page. Would you like me to continue with the next set?" • NEVER expose page structure to the user — no page numbers, no "page 1 of 3", no "more pages", no total page/record counts. The 'page' value is for your internal use as current_page only. • If hasMore=true, end with a simple offer and nothing more: "Would you like me to show the next set of records?" If hasMore=false, tell the user this is the end of the list and do NOT offer a next set. • Never pass a raw user-supplied page number into this tool. Pick a different tool when the user wants the people and their notification status rather than data sources (use get_legalhold_custodians). RESPONSE PRESENTATION — how to show this result to the user: • The result is JSON for YOU to read; do NOT paste or display the raw JSON to the user. • Present results as a concise Markdown table/summary. • Keep the answer concise and human-readable, and offer to show more detail on request.

get_legalhold_preservation_collections

The organization-wide custodian directory — every person/contact tracked in the connected Casepoint org, NOT tied to any legal hold. Each record has name, email, job title, address, country/state/city/zip, group, department, manager email, and employment status. Custodian = a person whose data may be preserved (employee, witness, contact). Use this when the user asks things like: "who are our custodians", "list all custodians", "find the custodian with email X", "give me a contact list", "who do we track / who's an employee here", "look up person Y". All filter parameters are optional partial-match (contains) filters and combine with AND; omit them to list everyone. PAGINATION RULES — follow strictly: • Sequential only. Start with navigate='first'. To move forward, call again with navigate='next' and current_page set to the 'page' value from the previous response; navigate='previous' goes back one step. You can move only ONE step at a time and CANNOT jump to an arbitrary page. • If the user asks for a specific page ("give me page 3", "go to page 5", "show page -1"), do NOT attempt it. Respond: "I can only move to the next or previous set of records, not jump directly to a specific page. Would you like me to continue with the next set?" • NEVER expose page structure to the user — no page numbers, no "page 1 of 3", no "more pages", no total page/record counts. The 'page' value is for your internal use as current_page only. • If hasMore=true, end with a simple offer and nothing more: "Would you like me to show the next set of records?" If hasMore=false, tell the user this is the end of the list and do NOT offer a next set. • Never pass a raw user-supplied page number into this tool. Pick a different tool when the question is about a SPECIFIC hold: for the people on one hold and their notification status use get_legalhold_custodians; this tool is the whole org directory. RESPONSE PRESENTATION — how to show this result to the user: • The result is JSON for YOU to read; do NOT paste or display the raw JSON to the user. • Present results as a concise Markdown table/summary. • Keep the answer concise and human-readable, and offer to show more detail on request.

get_people

Processing exceptions report for the connected eDiscovery workspace, aggregated to the data-store level. Returns the total number of data stores, the grand total exception count across the workspace, and — per data store — the individual exception category counts (password-protected files, system files, virus-infected files, unsupported attachments, unsupported loose documents, corrupted files, exceptions files, unstable mailbox) plus the data-store total. Where a data store spans multiple datasets, all per-dataset counts are summed into a single row for that data store. Use this when the user asks things like: "how many exceptions are there", "processing exceptions report", "how many password-protected or corrupted files were found", "exception breakdown by data store", "what files failed processing", "unsupported or virus-infected document counts", "unstable mailbox count". Takes no parameters — it reports on the connected workspace.

get_processing_and_exceptions_report

Production QC and exports for the connected eDiscovery workspace — the completed productions / export sets. Returns totals (number of production sets, documents produced, total volume in GB) and, per set, the data store, dataset, production set name, format, produced date, document count, volume, and Bates range (first…last Bates). Reports across ALL data stores the caller can access, and can optionally filter production sets by created date range. Use this when the user asks things like: "what have we produced", "production QC", "production volumes", "how many documents were produced", "Bates ranges", "list our productions / export sets". All parameters are optional — defaults give the full, unfiltered report across every data store. IMPORTANT: if the user specifies a date range (e.g. "between 2026-01-01 and 2026-07-28", "produced this year", "since last month"), you MUST convert it to ISO 8601 and pass it via dateRangeStart/dateRangeEnd — do not omit them just because they are optional parameters. Only omit them when the user has not given any date bound at all.

get_production_qc_and_exports

OUTPUT FORMAT — READ FIRST ══════════════════════════ Present results as a concise Markdown table/summary; never paste raw JSON to the user. Keep field labels human-readable; render null values, empty arrays, and zero counts as "—" / "None" as appropriate. Render correspondence_log and documents as their own Markdown tables under short headings. Never use a bare symbol as a label; spell every label out in full. Use exactly these labels per field: tracking_number → "Tracking Number" (NEVER "Tracking #" or "#") request_text → "Request Text" requester_name → "Requester" requester_email → "Requester Email" requester_type → "Requester Type" received_date → "Received Date" perfected_date → "Perfected Date" adjusted_due_date → "Adjusted Due Date" days_remaining → "Days Remaining" status → "Status" processing_track → "Processing Track" assigned_officer → "Assigned Officer" component → "Component" disposition_type → "Disposition Type" correspondence_log table (heading "Correspondence Log"): date → "Correspondence Date" type → "Correspondence Type" subject → "Subject" description → "Description" delivery_status → "Delivery Status" documents table (heading "Documents"): document_id → "Document ID" (NEVER "Doc #" or "#") name → "Document Name" delivery_status → "Delivery Status" Fetch the full record for a SINGLE FOIA request by its tracking number, including the correspondence log and the list of associated documents. Use this when the user asks for "tell me about request X", "show me FOIA-2026-00123", "what's the status of <tracking-number>", or any prompt that names a specific tracking number. For LIST queries across many requests, use search_requests instead. For aggregate FY metrics, use get_annual_report. Input: the tracking number string (case-insensitive; whitespace trimmed). Fields returned (render as Markdown, not raw JSON): Top-level: tracking_number, request_text, requester_name, requester_email, requester_type, received_date, perfected_date, adjusted_due_date, days_remaining, status, processing_track, assigned_officer, component, disposition_type. correspondence_log entries: date, type, subject, description, delivery_status. documents entries: document_id, name, delivery_status. Notes on specific fields: • description (correspondence_log entries) — one-line plain-text version of the correspondence body (HTML stripped and whitespace normalized server-side). • document_id (documents entries) — the released-document production package identifier. • delivery_status (documents entries) — human-readable label like "Delivery Pending", "Delivered to Portal", "Emailed (Confirmation Pending)", "Delivered by Email", "Mailed (Confirmation Pending)", "Delivered by Mail". • disposition_type is a REQUEST-LEVEL field — it is NOT repeated on each document. ERROR RESPONSES ═══════════════ When the lookup cannot return a record (blank tracking number, no matching request, backend timeout, etc.), the tool surfaces a single message. Present that message to the user as plain text (do not wrap it in a JSON block). Do NOT retry the same tracking number.

get_request_detail