Integration details
Description
Syntheia brings two things lawyers do every day into ChatGPT. Compare: upload a counterparty's draft and your last version, and Syntheia returns a clause-by-clause list of insertions, deletions, and moved text, with a redlined document to download. Query: ask a question about one agreement, a group of agreements, or your whole workspace. Syntheia navigates each document's structure, follows cross-references, and returns the exact provision text with a link to the source clause, so every answer is grounded in the document rather than in a summary. Documents stay in your private Syntheia workspace, and results are scoped to your account.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Contract Lifecycle & Review
- Secondary Subcategories
- None listed
- Brand
- Syntheia
- Access
- Account required
- First tracked
- 2026-09-04
- Tool count
- 17
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like
Competing in ChatGPT Contract Lifecycle & Review
View Category17 tools agents can invoke
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 — ALWAYS call it when a connected user identifies two DOCX documents and asks to compare, redline, diff, tell the difference, show what changed, or mark up the differences. 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.
List all Syntheia workspaces accessible to this API key. Returns: A formatted list of workspaces with their workspace_id, status, name, and language.
Obtain a presigned MinIO URL so that a client application can upload a file directly to storage. WHEN TO CALL THIS TOOL — call it whenever the user wants to upload, ingest, add, import, index, or load a file into Syntheia. Trigger phrases include: "upload this file", "add this document", "ingest this contract", "load this PDF", "index this agreement", "add to the workspace", "read this file". This tool is intended for programmatic clients (e.g. a web app), NOT for the LLM itself — the caller must compute an MD5 hash and perform an HTTP PUT, which an LLM cannot do. Do not attempt to call this tool interactively. If a document with this title already exists, returns its doc_id immediately and no upload is needed. Otherwise returns a presigned URL and a storage key for the caller to use. Caller workflow after a successful response: 1. PUT the file binary to presigned_url (no auth headers, Content-Type: application/octet-stream) 2. Call register_document with file_name, file_hash, title, file_extension If the PUT fails for any reason (network restriction, blocked host, etc.), do NOT retry. Instead, tell the user they can upload the file directly via the Syntheia web interface at the web_upload_url included in the response. Args: title: Display title for the document in Syntheia. file_hash: MD5 hex digest of the file (computed by the caller). Returns: JSON with presigned_url, file_name, and web_upload_url, or {"exists": true, "doc_id": "..."}.
Register a document that has already been uploaded to storage. Call this after successfully PUT-ing the file binary to the presigned_url returned by prepare_upload. Returns immediately with a doc_id — indexing happens asynchronously. Do NOT automatically call check_document_ready after this; let the user decide when to check. Args: file_name: Storage key returned by prepare_upload. file_hash: MD5 hex digest of the file (same value passed to prepare_upload). title: Display title for the document. file_extension: File type without leading dot, e.g. "pdf", "docx", "txt". Returns: A string containing the doc_id, e.g. "doc_id: abc123"
Vector (semantic) search + cross-encoder rerank over document body text, to answer a question about clauses, terms, obligations, dates, or any other content actually written in a document. Runs a 4-step retrieval pipeline (vector search, cross-encoder rerank, cross-reference expansion, verbatim text fetch) and returns clause text. Answer the question from that text — no separate LLM call is made by this tool. WHEN TO CALL: - Similarity / text-block search — the user supplies a passage or clause and asks for similar or matching text elsewhere in the workspace. This is the direct entry point for that case; skip the index tools entirely. - Q&A — for ordinary questions ("what does the contract say", "what are the payment terms", "what is the notice period", "does the document allow X", "summarise the agreement"), the DEFAULT first step is get_index_json/get_index_provisions instead. Call this tool for Q&A only if, having seen the index, you judge vector search fits better than structural navigation, OR as a supplementary search run alongside get_index_json for requests that are neither clean Q&A nor a similarity search. Always retrieve via one of the two paths above before answering from general knowledge. WHEN NOT TO CALL — this tool only searches document BODY TEXT; it cannot read a document's tags. If the question asks for a document's metadata VALUE under a tag category (e.g. "who is the author of X", "what jurisdiction is X under", "what practice group is Y"), call `get_document_tags` instead — that value lives in the document's tags, not its text, and this tool cannot retrieve it. SCOPING WITH tag_names — narrow the search instead of scanning the whole workspace whenever the question names a tag category or value. Every workspace has these default categories: Author, Document Type, Clause Type, Client, Party, Matter Number, Practice Group, Sector, Jurisdiction, Document Date, Endorsed. - Check first whether the question names one of these categories (e.g. "documents under Jurisdiction") — pass the category name and it expands to every tag under it. - If the question also gives a specific value (e.g. "tagged NDA", "Party Colab"), pass that value instead/as well — it matches that exact tag. - A document is in scope if it has ANY of the resolved tags (OR, not AND). Omit `tag_names` to search the whole workspace. Step 1 — Vector search: candidates workspace-wide by embedding similarity, paging in more while results stay in the same relevance tier as the best match. Step 2 — Cross-encoder rerank: keeps the highest-precision nodes in the same relevance tier as the best match, across a diverse set of documents. Step 3 — Cross-reference expansion: adds clauses referenced by the selected clauses. Step 4 — Batch text fetch: verbatim text for the full expanded clause set. ANSWER POLICY: - Answer EXCLUSIVELY from the verbatim text returned by this tool — never from training knowledge or general expertise. - If the retrieved provisions don't contain enough information, say: "The documents in this workspace do not contain enough information to answer this question." - Cite the source document (doc_id) for every claim. - After calling this tool, always include the "[Retrieval summary]" block verbatim, unchanged, at the end of your reply — every time, regardless of whether you found an answer or said there's not enough information. Args: question: For direct similarity/text-block search, the user's supplied passage or question, VERBATIM — do not paraphrase, substitute synonyms, expand into domain/legal jargon, or reword it before searching, even if you believe a reworded version would retrieve better. For the Q&A-routing fallback case (see server instructions' RETRIEVAL DECISION TREE / HYDE sections — reached once a document group is too large to navigate, or scope is the whole workspace/unknown), pass a Hypothetical Document Embedding (HyDE) passage instead: a short passage (1-3 sentences) drafted the way an answer would actually read inside a document, not the literal question. Either way, call this tool at most once per question — never call it again with a different phrasing of the same question to refine or expand the search; if the result seems thin, try tag_names or a different tool instead of rewording. tag_names: Optional tag names and/or category names to restrict the search to documents carrying any of them, e.g. ["NDA"] or ["Jurisdiction"]. Returns: Raw retrieval material, NOT a finished answer — you must compose the answer yourself from this text (see Answer policy above): verbatim provision text from the matched clauses, followed by a retrieval summary (including the workspace name) and a link to view the source clauses in the Syntheia web app. If a requested tag name doesn't match any existing tag or category, returns a message saying so instead of silently searching the whole workspace.
Switch the active workspace for the rest of this session. Every other tool that operates on "the workspace" (search_provisions, list_documents, prepare_upload, register_document, check_document_ready) uses whatever workspace this points at, until it is called again or the server restarts. Use list_workspaces to find the workspace_id first. Args: workspace_id: The numeric workspace ID to switch to. Returns: Confirmation with the new workspace's name.
Update properties of a Syntheia workspace. Only provided (non-None) fields are sent in the update payload. Args: workspace_id: The numeric workspace ID to update. name: New display name. active: Set workspace active or inactive. language: Primary language (e.g. "english", "french"). protected: Restrict access to authorized users only. document_limit: Maximum number of documents allowed (None = no limit). Returns: Confirmation with the updated workspace name.
Upload and register one attached document in a single tool call. Use this path when the MCP client supplies an attachment as a pre-authorized file reference, as ChatGPT does. The server downloads the attachment, computes its MD5 hash, uploads it to Syntheia storage, and registers it for indexing. Claude clients that expose local file bytes instead should retain the prepare-syntheia-upload -> direct PUT -> register-syntheia-document workflow; do not place file bytes or base64 data in tool arguments. Args: document: The attached file reference supplied by the MCP client. title: Optional workspace display title; defaults to the attachment's filename, or its file ID when no filename is available. Returns: The existing or newly registered document ID.
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Syntheia alternatives on ChatGPT?
As of 2026-09-04, Syntheia competes with Contract Information Extractor, Ideals, Ironclad Contracts, Safe2Sign: Contract Risk Check, SeedLegals, Youtrust in ChatGPT Contract Lifecycle & Review, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.