CiteLaw

Associate an existing contact with the user's CURRENT matter, optionally recording the role the contact plays on that matter. Returns the link's contact, matter, and role. ONLY call this when the user EXPLICITLY asks to add/associate/link a contact with the matter ("add Jane to this matter", "she's the client on this case"). NEVER call it proactively. The contact must already exist — search with query_contacts (or create it with create_contact) first, confirm the right match, then link it. The matter is always the session's current matter; you cannot link into a different one.

link_contact_to_matter

Find / list the documents in the user's active CiteLaw matter by METADATA (everything they've uploaded, created, or pulled in from connected storage). Returns references (id, name, source, type, date, indexed) — NOT content; use read_document to read one or search_documents to search inside their text. This is the metadata lookup: filter by name (`q`), file type, provenance, how it arrived, indexed status, and a created-date range, and sort. `indexed:true` means a doc is available to semantic search. All filters combine (AND). Scope is the session's active matter.

list_documents

List the matters (matters) in the active workspace. Use a returned `id` with switch_matter to change the working matter.

list_matters

List the user's saved CiteLaw workflows — their standardized, reusable processes (client letters, memo formats, contract review checklists, status updates). Covers CiteLaw's built-in workflows plus everything saved in the user's workspace, including colleagues' workflows. Use this when the user asks to run, follow, or use one of their workflows/templates, or asks what workflows they have. Then call get_workflow with the chosen id and follow its instructions in this conversation. Read-only.

list_workflows

List the workspaces the user belongs to (with the active one flagged). Use the returned `id` with switch_workspace to change the working workspace.

list_workspaces

Look up a FEDERAL JUDGE by name and get their complete profile: role, court, biography (appointing president, judicial service history, education, birth year), federal caseload statistics (assigned cases and referred matters from the docket archive), and — most importantly — their chambers STANDING ORDERS and INDIVIDUAL PRACTICES with full text. Covers ~1,200 federal district, magistrate, and bankruptcy judges whose chambers practices CiteLaw has collected. USE THIS WHEN the user asks about a judge: "what are Judge Anderson's summary judgment requirements?", "who is Magistrate Judge Pym?", "how do I schedule a conference before Judge X?", "tell me about the judge on my case". This is the ONLY tool with judge biographies and caseload stats; practice text is also reachable per-document via authority_lookup (source='judge_practices'). NOT for finding opinions a judge wrote (use search_authorities) and NOT for state court judges (federal only). Resolution: pass the name as given — honorifics and partial names are fine. If several judges match you'll get `multiple_matches` with slugs; re-call with the slug as judge_name. A `court` hint (any fragment: "SDNY", "C.D. Cal", "bankruptcy") disambiguates common surnames in one call. Citing: each practice document carries a `citelaw_cite` markdown link — use it verbatim when referencing the judge's orders, per the standard citing rules. Practice text is budgeted (~20K chars per call); `truncated: true` + the guidance field tell you when to follow up with authority_lookup for a specific document.

judge_lookup

Add to and maintain the firm's clause library: save a provision for reuse, correct one, archive language the firm has stopped using, or remove one saved by mistake. Use when the user asks you to remember a provision, or after drafting language they say they want to keep. Built-in clauses cannot be changed; create a new one from their text instead.

manage_clauses

Add or update MANY contacts at once — importing a client list, the parties from a pleading, or a set of opposing counsel. Use this instead of create_contact whenever there is more than one. Contacts already in the address book are matched and left alone rather than duplicated, so re-running an import is safe. The result reports created versus already-existed for every row: tell the user both numbers. Pass external_provider and external_id when importing from another system so a future sync updates the same records. For thousands of rows, the CSV import in the CiteLaw app is the better tool.

manage_contacts

Create, change and remove discovery sets and the numbered requests inside them. Use when the user pastes or shares discovery they were served, asks you to draft responses and objections, or wants to correct or remove something. Pair with read_document to load a served PDF: read it, work out where each request begins, then add them here. Always belongs to the current matter.

manage_discovery

Create, update, or convert prospective clients in the intake pipeline. Use create/update when the user describes someone who has enquired. Use convert when the user explicitly asks to open a matter for, sign, or convert a lead: it creates the matter from the lead's intake fields, promotes the lead to a client contact, and marks the lead converted, so prefer it over manage_matters create in that situation. Never convert unprompted.

manage_leads

Create and maintain matters: open a new one, rename it, describe it, archive one that is finished (or restore it), and control which workspace members can see it. Use when the user asks to set up a matter for a new client or piece of work, tidy up their matter list, or give a colleague access. A new matter does NOT become active on its own; follow create with switch_matter if the user wants to start working in it. Ids must come from list_matters. Archiving is reversible and hides nothing permanently; matters cannot be permanently deleted here.

manage_matters

Create, update, or delete the user's schedule items: matter DEADLINES (the litigation timeline) or CALENDAR EVENTS (their CiteLaw calendar — changes mirror to the user's Outlook automatically when it's connected). One action + one item_type per call; `items` takes many at once, so a whole scheduling order is ONE call. ONLY call this when the user explicitly asks to add, change, complete, or remove schedule items, or confirms dates you proposed (e.g. after you read a scheduling order). Never write proactively. For update/delete, `id` must come from a query_schedule result THIS session — query first, never invent or recall ids. Dates are ISO 8601; give calendar events concrete UTC start/end times unless all_day.

manage_schedule

Create, update, or complete tasks (assignable work) in the current matter or at the firm level. Use when the user asks you to note something that needs doing, assign work, or mark work finished. Cannot approve or reject items in the review queue — those are decided by a person in the app.

manage_tasks

Create, update, or delete the user's own CiteLaw workflows — their saved, standardized processes. Use it to turn an existing template the user pastes or describes (a client letter, a memo format, a review checklist) into a reusable workflow, or to refine one they created. `workflow` takes: name (required on create), description, mode ("ask" research | "draft" document | "review" analyze-a-document), inputs (fields the user fills per run: name, label, type [text|textarea|document|number|currency|select|radio|multi_select|date|jurisdiction|authority_reference|contact_reference], required, help, options), system_addendum (extra standing instructions; may reference inputs as {{input_name}}), and output — {shape: "document"|"conversational", sections: [{label, key, content_type [paragraph|multi_paragraph|bullet_list|numbered_list|verbatim_quote|summary_sentence|verbatim_text], description, required, verbatim_text}], header, footer} or {shape: "extraction_table", columns: [...]}. Put fixed boilerplate (signature blocks, notices) in verbatim_text sections so it reproduces exactly. Updates may pass just the fields to change. Only the user's own workflows can be changed — never CiteLaw's built-ins, never a colleague's. Confirm with the user before deleting.

manage_workflows

Set up and run the firm behind a workspace: create a new team workspace, rename one, invite colleagues, set what each member is permitted to do (workspace role) and what they do at the firm (firm role), set billing rates, and remove people who have left. Every action except create requires workspace owner or admin permission. Inviting emails a real person and consumes a firm seat immediately; removing someone ends their access and their entitlement. Use query_firm first to see who is there, what they hold, and how many seats are free. Accepting invites, leaving, and billing changes are done by the person themselves in CiteLaw.

manage_workspace

Search the firm's clause library — its own standard contract and letter language, plus a built-in starter set. Use BEFORE drafting a provision the firm likely has standard wording for (confidentiality, indemnity, governing law, arbitration).

query_clauses

Search the firm's shared address book for a person or organization — a client, opposing party, opposing counsel, court, witness, or vendor. Returns each match's `contact_id`, name, type, organization, and email, plus `merge_fields`: everything the firm has on file for addressing this contact in a document (salutation, formal_name, phone, address lines, and a ready-to-print multi-line address_block). When drafting a letter or document to a contact, use merge_fields values verbatim. A field absent from merge_fields is NOT on file — ask the user for it, never invent it. By default (scope "matter") this searches only the contacts associated with the CURRENT matter, and each result includes a `matter_role` (the contact's role on this matter). Pass scope "workspace" to search the firm's entire address book instead — use that when the person may not be linked to this matter yet. Search also matches a contact's PRIOR names and organizations, so a client now named "Miller" still surfaces when searched as "Johnson". When a result matched on an old value it carries `former_names` / `former_organizations` — surface that to the user (e.g. "Jane Miller, formerly Johnson") so the match is clear. Use this whenever the user refers to someone who might be on file ("my client Jane Smith", "opposing counsel at Acme") or when a workflow needs a contact_reference — search first, then confirm the right match with the user before relying on it. Never invent a contact_id; only use ids returned here. NOT the same as query_leads. A CONTACT is someone on file for work the firm has already taken on. A LEAD is a prospective client who has not been signed and has no matter yet. If you cannot tell which the user means, search BOTH before saying the person is not on file.

query_contacts

List discovery served on or by the firm for the current matter, or open one set to read its numbered requests and responses. Use for 'what discovery is outstanding', 'what's due', or before drafting responses.

query_discovery

Look up the firm behind the active workspace: who its members are, what workspace role and firm role each one holds, how many seats the firm plan provides and how many are in use, which invitations are still outstanding, and (for owners and admins) recent workspace activity. Read-only. Use it before inviting someone (to check seats), before changing anyone's permissions (to see what they hold today), or when the user asks who is on their team. To CHANGE any of it, use manage_workspace. This is about the workspace you are in; list_workspaces is about which workspaces you belong to.

query_firm

List prospective clients in the firm's intake pipeline. Use for 'what leads are open', 'has anyone followed up with X', or to find a lead before running a conflict check. NOT the same as query_contacts. A LEAD is a prospective client the firm has not taken on: no matter exists yet, and converting the lead is what creates one. Someone the firm already acts for or against — client, opposing party, opposing counsel, witness, court, vendor — is a CONTACT; use query_contacts for those. A lead that has already converted usually exists in both places. If you cannot tell which the user means, search BOTH before saying the person is not on file.

query_leads

Search/list the user's saved notes in the active CiteLaw workspace/matter. Returns note text + any linked authorities. The scope (workspace/matter) is the session's active matter — you control only `q` (search text), `sort`, and paging.

query_notes

Read the user's schedule: matter DEADLINES (the litigation timeline of the active workspace/matter) and CALENDAR EVENTS (their CiteLaw calendar, including Outlook-synced events), merged chronologically over a date window. Default window: today through +90 days; pass start/end for a different range (past ranges are fine). Every item carries its `id` and `item_type` — exactly what manage_schedule needs to update or delete it. Call this BEFORE any update/delete so you act on real ids, never remembered or invented ones. Re-run it whenever you summarize or report the schedule, even if earlier results are visible in this conversation — the schedule may have changed since (other sessions, the calendar tab, Outlook sync); this call is the live source of truth. When events carry `start_local`/`end_local`, quote THOSE times to the user, never convert UTC timestamps yourself.

query_schedule

Look through the user's past CiteLaw chats in the active matter — the research they did in the CiteLaw app itself. Read-only. Call with no arguments (or `q` to search titles) to LIST the matter's chats. Then pass `session_id` from that list to READ one in full: every question asked and every answer given. Use it before repeating work — to pick up where the user left off, or when they refer to something they 'already looked into' in this matter.

query_search_history

List tasks (assignable work) in the current workspace. Use for 'what's on my plate', 'what's outstanding on this matter', or to find items waiting for approval. Covers both matter work and firm-wide admin work. Read-only.

query_tasks

Read the full text of one of the user's documents, by id, paged by character. Pass `id` for a document from list_documents (an uploaded or connected-storage file). Returns a window of text from start_char; page long documents via has_more / next_start_char. Use this when you need a document's actual wording; use search_documents to find content across documents.

read_document

Look up authorities by BIBLIOGRAPHIC METADATA (title, citation, code, section, docket, court) — NOT by content. Use this when the user describes WHICH authority they want by how it's catalogued, not by what it discusses. THIS IS THE TOOL FOR FINDING A SPECIFIC, ALREADY-NAMED AUTHORITY. Always prefer it over `search_authorities` for known-item lookups (a case name, a citation, a code + section): it matches the catalogued title/citation/section directly, while semantic search ranks by topic and can bury or miss the exact case the user named. Pick this tool when the user: • names a case ("Roe v Wade", "Smith v Jones") • pastes a citation ("410 U.S. 113", "123 F.3d 456", "CPLR § 3013") • cites a statute by code + section ("NY UCC 2-201", "22 NYCRR 205.23") • gives a docket number ("21-1234") Do NOT use this for content questions — for "What's the law on X?" use `search_authorities`. For "Find passages that mention exact phrase X" use `search_authorities_keyword`. To read the full text of a result, use `authority_lookup` with the `id` returned here. Do NOT use this to VERIFY or CHECK a LIST of citations — a Table of Authorities, a brief's cites, "are these citations real?" — that is `verify_citations`' job, in ONE bulk call (up to 50 at once). Per-item metadata lookups are the wrong tool for verification: they burn a round per citation and a bare title search returns loose near-matches (same party name in another state, a different era) with no confirmed / possible_match / no_match verdict. This tool is for finding ONE authority the user wants to use, not for auditing many. `source` is REQUIRED — pick the one that matches the kind of citation/metadata you have (a case citation only finds cases, etc.). For cases: provide at least one of `title`, `citation`, `docket_number`. For statutes: REQUIRES `jurisdiction` (state abbrev, or "US" for the U.S. Code) plus at least one of `code_name`, `section_number`, `section_name` — or just pass the whole `citation` ("42 U.S.C. § 9601") and it will be split for you. For court_rules: at least one of `code_abbrev`, `section_number`. Returns ranked candidates — top result is usually the right one but always inspect.

authority_search_metadata

Search CiteLaw's US legal corpus with a free-text query. Searches case law, statutes, and court rules by default; pass `sources` to reach court-specific local rules, individual judges' standing orders, immigration agency decisions and guidance, or administrative regulations. Returns matching authorities with ids for use with the fetch tool and citelaw.org URLs for citation.

search

Search the firm's document templates — their OWN uploaded .docx letterhead, pleading, and letter shells with {{token}} placeholders that merge into perfect-fidelity Word documents. Use when the user names a firm document to generate ('our engagement letter', 'the standard fee agreement'). This is a single fill, not a process: for multi-step firm procedures use list_workflows instead, and for reusable paragraphs of language use query_clauses.

query_templates

Search the user's OWN documents (the files attached to their CiteLaw matters — uploads and documents pulled in from connected storage). Two modes: - mode:"semantic" (default) — meaning-based passage search; covers ONLY documents the user has indexed for AI search. Best for "what does my contract say about termination". - mode:"keyword" — exact term/phrase search over EVERY document's extracted text (no indexing needed). Best for "where does my contract say 'indemnify'". Pass `document_id` to scan one document. For published law use search_authorities; to read one document in full use read_document. Scope is the workspace; set `scope`:"matter" to limit to the active matter.

search_documents

Change the active matter (matter) within the current workspace. Pass a `matter_id` from list_matters — NOT an id you guessed. Notes and saved work after this attribute to the new matter. Only switch when the user asks to work in a different matter.

switch_matter

Change the active workspace to one the user belongs to. Pass a `workspace_id` from list_workspaces — NOT an id you guessed. Starts a fresh session scoped to that workspace's default matter. Only switch when the user asks to work in a different workspace.

switch_workspace

Verify that citations refer to authorities present in the CiteLaw corpus — and catch typos. Covers case law, statutes, court rules, administrative regulations (C.F.R. / state admin codes), and immigration agency decisions (BIA / AAO, "I&N Dec.") — auto-detected per citation, so just pass them all. ONE call does everything: pass EVERY citation at once. If the user gave a DOCUMENT, run `extract_citations` with its `document_id` first, then pass each citation here as an object { citation, title, year, court, docket_number } (title from plaintiff/defendant). If the user PASTED citations directly into chat (a Table of Authorities, a citation list), pass them straight here — `extract_citations` is NOT required for pasted lists, and NEVER verify a list via per-item `authority_search_metadata` lookups (slower, costlier, and bare title searches return unranked near-misses, not verification verdicts). Docket-only citations are valid — pass docket_number with no citation. Each citation is classified: "confirmed" (we have this exact authority), "possible_match" (a near-miss — the cite resolves to a slightly different case, or a strong title match exists under a different cite; almost always a TYPO, returned with ranked `candidates` and per-field `field_matches` so you can say "did you mean…?"), or "no_match" (not in our database — which is NOT the same as the citation being fake or invalid). This tool is COMPLETE on its own. Never re-call it with fewer fields, and never follow it with search_authorities / authority_search_metadata to hunt for no_match citations — report them as not-in-database and stop. After one call, summarize the results for the user. NOT a treatment-status check (overruled, criticized) — that's a separate tool. Max 50 citations per call; run in parallel.

verify_citations