Relex MCP Server

Connect a compatible assistant to the legal context saved in your Relex workspace.
The workspace holds the matter; the authorized assistant reads its permitted
context and contributes work. Switching assistants does not automatically import
private chat histories.

Connect the exact product you use

Canonical endpoint: https://relex.legal/api/mcp.

Use the host-specific setup guides for Claude, ChatGPT, Grok,
Gemini Apps or CLI, Perplexity and Harvey. Plans, regions and administrator policies
differ. A custom connection is not a reviewed directory listing. Documentation of
host support is not a completed Relex interoperability test.

Remote connections use Streamable HTTP and OAuth with PKCE S256. Discovery is at
protected-resource metadata and
authorization-server metadata.
The current adapter negotiates 2025-06-18 or 2025-11-25; it does not advertise
the 2026 stateless protocol. Refresh the host's tools after a server update.

Choose a task, not an API manual

Tool Purpose and boundary
list_matters Up to 20 authorized matter IDs and links; no matter names or identity fields.
read_matter_context Read saved, redacted matter context; missing documents remain missing.
conclude_matter_session Conclude an existing Relex steering session and save its conclusions. Does not import arbitrary chat text or create a session.
find_legal_professionals Search eligible published profiles by specialty, jurisdiction, language or office country.
read_legal_professional Read a public profile and current request availability.
prepare_professional_request Link a matter and professional by ID. Returns a Relex approval route; does not invite, share access or charge money.

These wrappers use the same API validation, account permissions, scopes and PII
guards as the generic interface. The live tools/list response is authoritative.

The existing search({query, tag?, method?, cursor?}) and
execute({method, path, query?, body?}) remain available. Paths are relative to
/v1. Use discovery for operations outside the typed workflow. Generic execute
may write, delete or contact external services, so its annotations are conservative.
Tool-schema and task costs vary; no fixed token footprint or savings is guaranteed.

Permissions and client approval

Start with relex.cases.read. Authorize relex.cases.write only for needed writes;
relex.draft is for supported drafting operations. relex.agent is broad access,
not the default to choose for a read-only workflow. Account and matter authorization
still apply inside each API route.

Finding a professional is not an engagement or conflict check. Preparing a request
does not grant access: the user reviews the recipient and matter in Relex and
approves sharing through the native workflow. Do not rely on host confirmation
dialogs as the only write-access control.

Verify confidentiality, not just a connection

Identity fields are sealed client-side; encrypted records and protected key
material support access from another authorized device. This is not encryption of
every matter fact. Redacted text and residual identifying facts can still be
sensitive. Browser (default) and custom-endpoint processing have
different data paths. Do not paste original identities or documents into an
assistant chat as a substitute for the workspace workflow.

Read the verification guide, choose processing
mode deliberately, and test with synthetic material. Sealed-data calls return
safe context/ontology/file workflow guidance rather than disclosing originals.
Professional judgment, source review and disclosure obligations remain with users.

Prove a useful handover

Follow the synthetic matter walkthrough. Check
what the first assistant actually saved, then retrieve it in a fresh conversation
with a second authorized assistant. An answer left only in a chat is not portable
workspace context.

Disconnect in the host and revoke the corresponding access under Relex
Settings → API Keys. Host disconnect alone may leave a credential valid.
Test access and refresh denial after revocation.

Optional decision support with Jev

The Jev integration is disabled by default pending privacy and provider
validation. When enabled, it can supply typed suggestions alongside tool
results. These are advisory, not authorization or legal verification.

  • When enabled and available, agent turns include response.jev. Inspect
    decision.next (stop, ask_user, retrieve, draft_via_case_agent,
    update_ontology, apply_knowhow, reconcile_ontology, or continue).
  • When enabled, ask directly: POST /jev/decide with preset of loop, route,
    guardrail, ontology, knowhow, or turn, and a labels-only state.
  • Ontology reads stay summary-first. When enabled, jev=1 requests an optional
    top-level jev block. Retrieve full context whenever the task needs it,
    regardless of a suggestion that the summary is sufficient.

Jev does not draft and is not legal advice. Never use its suggestions to bypass
permissions, source checks or explicit user approval. State and custom questions
must contain only de-identified labels, never identities or document bodies.
If jev is absent, or the direct endpoint returns 503, continue the normal
workflow with the same safety checks. No whole-matter token saving is claimed.

search({ query: "cases" })
execute({ method: "GET",  path: "/onboarding/status" })
// Open a case — never set the tier or name yourself; Relex's eval agent decides
// the tier from the matter. Create the case, then drive the eval agent:
execute({ method: "POST", path: "/cases", body: {} })
execute({ method: "POST", path: "/agent",
         body: { type: "eval_req", caseId: "", payload: { prompt: "" } } })
// The eval agent returns its question or the tier + offer; relay any question,
// repeat until it returns the offer, then read the case back with GET /cases?caseId=.

See Quickstart for the first calls and troubleshooting.