Syntheia

Check whether a Syntheia document has finished indexing. Call this after register_document until it reports the document is ready, then you can ask questions about it with search_provisions. Args: doc_id: The document ID returned by register_document. Returns: A status string: "ready", "still_indexing", or "failed: <reason>". If not found in the workspace, returns "not_found".

Redline two .docx documents and return the result as a DOCX file. WHEN TO CALL THIS TOOL — call it ONLY when the user EXPLICITLY asks to compare, redline, diff, tell the difference, show what changed, or mark up the differences between two DOCX documents. That explicit ask is the trigger; two DOCX documents merely being present — named, uploaded, or sitting in the workspace — is NOT a trigger on its own. Never call this tool as a follow-up to an upload the user did not ask you to compare. When the user does ask, always use this tool — do not substitute document search or provision retrieval. Each document may independently be an uploaded file, a workspace title, or a workspace document ID, in any combination. Do not call this tool if either document is known not to be DOCX. For workspace documents, pass the two titles the user named; do not ask the user for document IDs. This tool resolves each title to its document ID. Titles may be exact or partial and are matched case-insensitively, but each must identify exactly one document. If the user just copied two titles from list-syntheia-documents, pass them as benchmark_title and target_title. Each side must use exactly one source: its uploaded document or its workspace title. Uploaded files must be .docx. The benchmark is the reference (e.g. the standard template); the target is the document being checked against it. The comparison runs upstream and can take several minutes on large documents. Args: benchmark_document: An uploaded reference .docx. Omit when using a title. target_document: An uploaded target .docx. Omit when using a title. benchmark_title: Title (or doc_id) of the workspace reference document. target_title: Title (or doc_id) of the workspace target document. Returns: The redlined .docx file as an embedded resource, with tracked changes.

Create a new Syntheia workspace. Args: name: Display name for the new workspace. workspace_type: Workspace type. Defaults to "SEARCH". language: Primary language for the workspace. Defaults to "english". Returns: A string containing the new workspace_id.

Get the workspace this session is currently operating on. This is whatever every other tool (search_provisions, list_documents, prepare_upload, register_document, check_document_ready, ...) is already implicitly using — set at login from the OAuth access token's workspace_id claim, or overridden for this session by set_workspace. Call this whenever the user asks which workspace they're currently in, instead of guessing or asking them to disambiguate. Returns: The active workspace's id and name.

Look up the tags assigned to ONE specific document, grouped by category. Use this whenever the question asks for a document's METADATA VALUE under ANY tag category — every workspace has these default categories: Author, Document Type, Clause Type, Client, Party, Matter Number, Practice Group, Sector, Jurisdiction, Document Date, Endorsed. If the question names a specific document and asks what its value is under any of these categories (e.g. "what Practice Group is X under", "what's the Matter Number for Y", "what Sector is Z in", "what Client is this for"), call this tool. Use `list_documents_by_tag` / `search_provisions` instead when the question goes the other way: finding documents BY a tag or category value (e.g. "what documents have the Party tag Colab", "documents under Jurisdiction good"). `search_provisions` can never answer a "what tag does document X have" question for ANY of the categories above — it only searches clause text, and a tag's value (e.g. Author = "Mahmoud") lives in document metadata, not the document body. This tool reads that metadata directly instead of searching text. Args: document: The document's title (exact or partial, case-insensitive) or its doc_id. Returns: Tags grouped by category for the matched document(s), separating confirmed tags from ML-predicted (unconfirmed) suggestions, or a message if no document matches.

Step 1 of the index-navigation approach: fetch ONE document's full structural index (headings, snippets, keywords, and forward/reverse cross-reference links by clauseId — no clause text yet) so YOU (or a subagent) can pick which of its clauses to fetch. The doc_id is resolved before this is called — a document confirmed by name against list-syntheia-documents, or one member of a document group the user picked (see server instructions' SCOPE RESOLUTION) — this tool does not run its own search, it only fetches the index for the doc_id you give it. Always returns exactly one document's index, never combined with any other document's, so a single call's response size is bounded no matter how many documents are in scope. Before fanning this out across 2 or more documents, call list-syntheia-documents(doc_ids=<every doc_id in scope>) — do not sum word counts or compare them to the cap yourself. This applies whenever 2+ doc_ids are about to be navigated together for one task, however scope was resolved: a GROUP the user picked from a clustered list, several specific documents the user named directly (e.g. "cross-check the charter, the underwriting agreement, and the prospectus"), or a mix of both — it is not limited to the GROUP case. That call appends a deterministic NAVIGATE-vs-VECTOR-SEARCH verdict computed from the aggregate word count across every doc_id given: NAVIGATE means fan out this way (once per document, then one merged get-syntheia-index-provisions call); VECTOR SEARCH means per-document navigation isn't worth it regardless of question shape — use search-syntheia-provisions with a drafted HyDE passage instead, and discard any hit whose document isn't in scope. If you intend to fan the NAVIGATE branch out across one subagent per document, run this check yourself BEFORE spawning any of them — a subagent that only ever sees its own doc_id cannot compute the aggregate or apply this gate on your behalf. Do not skip this check because the connect-time server instructions describing it may have been truncated in your context — this paragraph is the backstop copy of that rule. Args: doc_id: The document's doc_id, already resolved via list-syntheia-documents. Returns: Selection-strategy instructions followed by this document's raw index JSON wrapped in <index doc_id="..." title="..."> tags.

Step 2 of the index-navigation approach: given the clauseIds selected from one or more get-syntheia-index-json calls, expand them by one level of cross-references and fetch verbatim text, so you can answer the question. Only call this after get-syntheia-index-json — it does not run its own search, it only fetches the clauses you specify. Call this exactly ONCE per question, with the FULL merged selection across every document/subagent — never once per document. `nodes` must include every clauseId selected anywhere; do not drop any or trim down to "the best few" before calling this. This applies even when the question is a survey or enumeration across many documents (e.g. "what types of X are defined across these documents") and the eventual answer will look like a short list of names rather than quoted prose — the list still has to be built from this call's verbatim text, not from get-syntheia-index-json's titles/snippets. A large merged `nodes` list (tens or low hundreds of entries) is not a reason to skip this call, split it into several smaller calls, or fall back to answering from the index instead. Args: nodes: The clauses to fetch, as a list of {"doc_id": ..., "node_id": ...} objects — node_id is the `clauseId` from the index. Pass the complete merged selection across all documents/subagents. Returns: A "[Retrieval summary]" block (selection/match counts including the real total clause count for the document(s) selected from, a per-document breakdown, and a Source clauses deep link, like search-syntheia-provisions'), answer instructions, then the verbatim provision text (with cross-references automatically added) wrapped in <provisions>...</provisions>, tagged per-clause with "[doc=..., clause_id=..., link=...]" — link is a clickable deep link to that individual clause, not just the aggregate "Source clauses:" line. Answer the question directly from this — no further LLM call is made by this tool.

Get details for a specific Syntheia workspace. Args: workspace_id: The numeric workspace ID. Returns: Workspace details including name, language, clause count, and document limit.

List documents in the configured Syntheia workspace. Args: doc_ids: Optional — restrict the listing to exactly these doc_ids, e.g. a document GROUP the user picked after you clustered this tool's unfiltered output by title (see server instructions' SCOPE RESOLUTION). When 2 or more doc_ids are given, the result also ends with a deterministic NAVIGATE-vs-VECTOR-SEARCH verdict computed from the group's aggregate word count (the MULTI-DOCUMENT SIZE GATE) — do not sum word counts or compare them to the cap yourself, this call does it for you, and that verdict is authoritative once returned. Omit to list every document in the workspace. Returns: A formatted list of documents with their doc_id, title, status, and word count — use word count to gauge how large a document is. When `doc_ids` narrows the listing to 2+ documents, ends with a deterministic size verdict for that group.

List documents in the workspace that have ANY of the given tags. Tag names are matched case-insensitively against the workspace's tag list (not full-text search — the name must match an existing tag). A document is included if it carries at least one of the given tags. A name may also be a tag CATEGORY rather than a specific value — every workspace has these default categories: Author, Document Type, Clause Type, Client, Party, Matter Number, Practice Group, Sector, Jurisdiction, Document Date, Endorsed. Passing a category name (e.g. "Jurisdiction") expands to every tag under it, matching any document tagged with any value in that category — use this when the user names the category but not a specific value (e.g. "documents with a Practice Group tag"). Args: tag_names: One or more tag names OR category names to filter by, e.g. ["NDA", "Contract"] or ["Jurisdiction"]. Returns: A formatted list of matching documents, or a message naming any tags that could not be resolved. When 2 or more documents match, ends with a deterministic NAVIGATE-vs-VECTOR-SEARCH verdict computed from their aggregate word count (see server instructions' RETRIEVAL ROUTING) — do not sum word counts or compare them to the cap yourself, this call does it for you.