Lexnus MCP Server — Documentation

On this page

At a glance
What the server does
Connecting a client
Authentication and scopes
Tool reference
Security model
Data handling and residency
Limits and operations
Reviewer checklist
Frequently asked questions

At a glance

Server URL	`https://app.lexnus.com/mcp`
Transport	Streamable HTTP. Stateless — every call is authenticated independently.
Protocol	Model Context Protocol. Server identifies as `lexnous`, version `1.0.0`.
Authentication	OAuth 2.1 authorisation code flow, or a personal access token issued in Lexnus.
Scopes	`lexnous:read`, `lexnous:write`, enforced on personal access tokens. An OAuth token carries the user's own authority, bounded by their Lexnus role. See Authentication and scopes.
Tools	23. Twelve read, eleven write. Full list below.
Tool manifest	`GET https://app.lexnus.com/mcp/tools` returns JSON Schema for every tool.
Data reachable	Only the account the token belongs to. Never another customer's data.
Outbound email	Only for e-signature, and only after the human ticks a server-issued confirmation box.
Audit	Every write is recorded to an append-only log: actor, account, workspace, entity, operation, and before-and-after changes, stamped with the MCP channel. Reads emit a tracing span rather than an audit row.
Hosting	EU only. Clever Cloud, France. Backups replicated to OVHcloud, Germany.
Operator	Precisely (Lexnus). Sweden.

The server URL is also shown inside the product, under Integrations → Connect via MCP. Copy it from there if your account runs on a different host.

What the server does

Lexnus holds three things for an organisation: a clause library of approved language, playbooks that define which clauses belong in which contract type, and rules that decide whether a given contract complies. The MCP server lets an AI client use all three.

There are four workflows.

1

Draft a new contract

The client maps a plain-language request ("I need an NDA for a Swedish supplier") to a published playbook, opens an assembly session, and answers the playbook's fields one at a time. Lexnus renders the document server-side from approved clauses. The model never writes the final legal text — it collects field values and Lexnus does the substitution.

2

Analyse a contract

The client passes a contract into Lexnus, which runs it against the matching playbook and returns a verdict per rule: compliant, violated, gap, or needs review. Each finding carries the rule that fired, the excerpt that triggered it, the reason, a risk level, and whether the rule blocks signature. The judgement is made by Lexnus's rule engine, not by the model.

3

Handle a counterparty revision

When a redline comes back, the client adds it as a new version of the existing contract. Lexnus parses tracked changes, diffs clauses and field values against the last generated version, and re-runs analysis. It reports untracked changes separately — edits made with revision tracking switched off.

4

Send for signature

Once analysis is clean, the client can send the contract through the account's connected e-signature provider and track its status. This is the only tool group that reaches outside Lexnus, and it is the most heavily gated. See Security model.

Connecting a client

Any MCP-compatible client can connect. Three setups cover most cases.

Claude.ai, ChatGPT, and other hosted clients

Add a custom connector pointing at the server URL. The client discovers the OAuth endpoints, registers itself, and opens a browser window where the user signs in to Lexnus and approves the connection. No token is copied by hand. Read the scope note below before treating that consent screen as a restriction.

https://app.lexnus.com/mcp

Claude Desktop, Cursor, VS Code

These clients can use the same OAuth flow. To use a personal access token instead, create one in Lexnus under Account Settings → Developers, then add this to the client's MCP configuration:

{
  "mcpServers": {
    "lexnous": {
      "type": "http",
      "url": "https://app.lexnus.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN_HERE"
      }
    }
  }
}

Scripts and CI

Use a personal access token. Scope it to lexnous:read unless the pipeline genuinely needs to write. OAuth is for interactive clients where a browser redirect is available.

Authentication and scopes

OAuth 2.1

An unauthenticated request returns 401 with a WWW-Authenticate header pointing at the discovery document. The client then follows the standard flow. Lexnus implements the relevant RFCs so no client-specific configuration is needed:

Endpoint	Purpose
`GET /.well-known/oauth-authorization-server`	Authorisation server metadata (RFC 8414)
`GET /.well-known/oauth-protected-resource`	Protected resource metadata (RFC 9728)
`POST /oauth/register`	Dynamic client registration (RFC 7591)
`GET /oauth/authorize`	Authorisation endpoint — user signs in and consents here
`POST /oauth/token`	Token endpoint

Access tokens expire after 15 minutes. Refresh tokens expire after 7 days. Clients refresh automatically. The consent screen names the scopes in plain language: "Read your contracts and playbooks" and "Create and modify contracts and playbooks".

Personal access tokens

A token is 24 bytes of cryptographic randomness, prefixed pat_. Lexnus stores only its SHA-256 hash — the raw value is shown once at creation and is never retrievable afterwards. Tokens carry an owner, an account, a scope set, and an optional expiry. New tokens default to lexnous:read. Creation, use, and revocation are all audited, and the token hash is deliberately excluded from the audit payload.

Scopes

Scope	Grants
`lexnous:read`	Read contracts, clauses, playbooks, rules, obligations, analysis results, and signing status.
`lexnous:write`	Create and modify contracts, run assembly, add versions, and operate the signing tools.

Scope is checked in-process at the top of every write tool, against the authenticated principal on the request — not in the tool description, and not in the client. A personal access token that lacks lexnous:write gets an error from every write tool, every time. New tokens default to lexnous:read.

Scopes constrain personal access tokens, not OAuth sessions. An OAuth access token is an ordinary Lexnus session token. It carries no scope claim, so the scope check treats it as holding the user's full authority, bounded by that user's Lexnus role rather than by the scope strings shown at consent. This is the same trust model the rest of the API applies to a signed-in browser session.

The practical consequence for a reviewer: ticking only the read scope on the OAuth consent screen does not produce a read-only connection. If you need a connection that cannot write, issue a personal access token scoped to lexnous:read and configure the client with that token. To bound an OAuth connection instead, bound the user — connect it as a Lexnus account whose role has only the access you are willing to grant.

Revocation

Revoke a personal access token from Account Settings → Developers. Revoke an OAuth grant from the connected-applications list. Revocation takes effect on the next call. Deactivating a user cuts off everything issued to them.

Tool reference

Twenty-three tools. Write means the tool enforces lexnous:write before it does anything.

Drafting

Tool	Scope	What it does
`lexnus_resolve_playbook`	Read	Maps a plain-language drafting intent to a published playbook, and returns the fields that need answering.
`lexnus_get_playbook_clauses`	Read	Returns the ordered clause structure of a playbook with placeholders intact.
`lexnus_get_playbook_rules`	Read	Returns every policy rule for a playbook, with conditions and escalation type.
`lexnus_check_rule_violations`	Read	Validates a collected field map against the playbook's rules before assembly.
`lexnus_start_assembly`	Write	Opens an assembly session for a playbook.
`lexnus_get_required_fields`	Read	Returns the fields still outstanding on a session.
`lexnus_answer_session_field`	Write	Stores one field answer on a session.
`lexnus_generate_document`	Write	Finalises the session and returns a link to the contract in Lexnus, or a single-use DOCX download valid for 15 minutes.

Analysis and review

Tool	Scope	What it does
`lexnus_ingest_contract`	Write	Persists a contract shared in chat and returns ranked playbook suggestions.
`lexnus_analyse_document`	Read	Runs a structured playbook analysis on a contract already in Lexnus. Returns immediately; the client polls for the result.
`lexnus_get_analysis_result`	Read	Fetches verdicts, confidence scores, and remediation suggestions.
`lexnus_get_analysis_findings`	Read	Per-rule detail: rule name, contract excerpt, reason, risk level, blocking status.
`lexnus_answer_field`	Write	Submits one field value for an imported contract awaiting field data.
`lexnus_search_clause_library`	Read	Searches the account's approved clause library by keyword and category.
`lexnus_list_obligations`	Read	Lists obligations across a workspace — payments, deliveries, notices, renewals.

Contracts and versions

Tool	Scope	What it does
`lexnus_create_contract`	Write	Creates an empty contract record in a workspace.
`lexnus_save_version`	Write	Snapshots the contract as a new version, tagged as agent-initiated.
`lexnus_upload_version`	Write	Adds a counterparty revision as a new version. Parses tracked changes, diffs clauses and fields, queues re-analysis.

Signature

Tool	Scope	What it does
`lexnus_get_signing_auth_methods`	Read	Lists the identification methods the connected provider supports, including qualified electronic signatures under eIDAS.
`lexnus_send_for_signature`	Write	Sends a reviewed contract for signature. Gated — see below.
`lexnus_get_signing_status`	Read	Reads overall and per-party signing status with timestamps.
`lexnus_cancel_signing_request`	Write	Withdraws an in-flight signing request. Gated.
`lexnus_remind_signing_parties`	Write	Re-sends the invitation to parties who have not signed. Gated.

Security model

The account boundary

Every call carries an authenticated principal: a user, an account, and a scope set. Tools resolve the account from that principal, never from a tool argument. A token cannot name a different account and be served its data. Workspace-scoped tools additionally check that the caller is a member of the workspace. Cross-account access is prevented by construction, and covered by tests.

The model cannot approve its own actions

Three tools reach a counterparty by email: sending for signature, cancelling a signing request, and reminding parties. All three are gated server-side, not by a convention written into the tool description.

On the first call, the tool returns before touching the signing provider. It hands back an input request that the client must put to the human, who ticks an explicit confirmation box. Only a retry carrying an accepted response gets past the gate. A client that ignores the request never reaches the provider. A client that cannot ask a human never reaches the provider. The model cannot satisfy the gate on its own, because the response is authored by the client's user interface rather than generated as tool arguments — and an empty form does not count as approval.

This matters for a specific risk: a contract is untrusted text. Text inside a document cannot cause Lexnus to email anyone, because no path to the provider exists that a human has not individually confirmed.

The signing gate is fail-closed

Sending a contract version that was never analysed fails with not_evaluated. Sending one with live blocking violations fails with sign_blocked. Recipient resolution runs as its own step: if the caller supplied no signatories, the server asks the user directly rather than accepting a recipient the model chose. Errors are not retryable states here — they mean the review is not finished.

Generation is server-side

The model does not author final contract text. It collects field values; Lexnus substitutes them into approved clauses and renders the document. Clause language comes from the customer's published library. This is the point of the integration: the model supplies language intelligence, Lexnus supplies policy authority.

Audit trail

Lexnus keeps one append-only audit log across the whole product, and MCP writes land in it alongside everything else. Rows are never updated or deleted, and there is no retention job that removes them. Each row carries the actor and the account, the workspace, the channel the action arrived through, the entity touched, the operation performed, a trace identifier that links the whole causal chain, and a payload holding the before-and-after changes.

Two limits worth knowing before you rely on this log:

Writes are audited; reads are not. Audit rows are emitted by the underlying services when they mutate data, so the eleven write tools produce them. A read tool emits a tracing span, not an audit row. If your requirement is a durable record of every read an AI client performed, this log does not meet it today.
Rows are not labelled with the individual tool. MCP actions are recorded with the channel mcp and the action kind mcp_tool, under a generic action name. The specific tool name is on the tracing span, which is operational telemetry rather than a retained audit record.

Contract versions written over MCP are separately marked at the record level: a version added by an AI client is stored with an agent-initiated flag and an agent source, so the contract's own version history distinguishes AI-made changes from human ones.

Because the channel is recorded, an administrator can separate what arrived over MCP from what someone did in the web application. Every tool call — read or write — emits a tracing span named for the tool, for operational review.

Rate limiting

MCP traffic is rate limited per account, separately from browser and direct API traffic. The default is 5 requests per second sustained with a burst of 20. A runaway agent is throttled at the account boundary and cannot degrade the service for anyone else.

Transport and storage

TLS in transit. AES-256 at rest. Contract files replicated to the backup region as sealed ciphertext. The MCP endpoint sits behind the same authentication middleware as the rest of the Lexnus API — an unauthenticated request never reaches the protocol layer.

Data handling and residency

Where Lexnus processes data

Lexnus runs on EU-sovereign infrastructure. There is no US CLOUD Act exposure. These are the sub-processors that handle customer content:

Service	Provider	Location
Hosting, database, object storage	Clever Cloud	France
Encrypted replication and backup	OVHcloud	Germany
Transactional email	Sweego	France / Netherlands
Monitoring and observability	Better Stack	Czech Republic
AI / LLM (default provider)	Mistral AI	France
Electronic signature (optional)	Scrive	Europe

Contract text sent to the default LLM provider is not used to train that provider's models. The full list, including optional sub-processors, is in the Data Processing Addendum.

Where your MCP client processes data

State this plainly, because it is the part reviewers most often miss. When you connect an AI client to Lexnus, contract text travels through that client. Claude, ChatGPT, or whatever you connect is your own arrangement with that vendor, under your contract with them — Lexnus is not their controller and does not appoint them as a sub-processor. Review that vendor on its own terms alongside this one.

Lexnus's obligations start at the server URL. Everything reached through a Lexnus tool call stays inside the infrastructure described above.

What the server does not do

It does not reach any account other than the token's.
It does not send email except through the e-signature provider, and only after human confirmation.
It does not return raw contract files to the client. Documents are returned as links into Lexnus, or as a single-use download valid for 15 minutes.
It does not write credentials to the audit log.
It does not accept an account or tenant identifier from the caller.

Limits and operations

Rate limit	5 req/s sustained per account, burst 20 (MCP channel)
Access token lifetime	15 minutes
Refresh token lifetime	7 days
DOCX download links	Single use, 15 minutes
Original-file attach links	Single use, 7 days
Analysis	Asynchronous. Trigger, then poll for the result.
Session model	Stateless. No server-side MCP session to hijack.

Analysis volume counts against the account's plan limits, the same as analyses run in the web application. Rate limits are configurable for enterprise accounts.

Reviewer checklist

If you are deciding whether to approve this server, these are the answers you are probably looking for.

Who can it reach? One account — the one the token belongs to. Account and workspace come from the authenticated principal, never from a tool argument.

Can it act without a human? It can read, draft, and analyse under a granted token. It cannot email a counterparty without a human ticking a confirmation box that the server itself issues.

Can we limit it to read-only? Yes, with a personal access token scoped to lexnous:read — all eleven write tools reject it. Not by unticking the write scope at OAuth consent, which does not restrict the resulting token.

Is there a record? For writes, yes — append-only, with actor, account, entity, operation, and before-and-after changes, stamped as MCP. Reads leave a tracing span, not an audit row.

Can we turn it off? Yes. Revoke the token or the OAuth grant in Lexnus. Effective on the next call.

Where does data go? EU only on the Lexnus side. Through your chosen AI client on the other side — review that vendor separately.

Who do we ask? security@lexnus.com for security review, DPAs, and sub-processor questions.