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 every token. An OAuth token carries the scopes the user approved at consent. See Authentication and scopes.
Tools	27. Fifteen need `lexnous:read`, twelve need `lexnous:write`. Full list below.
Tool manifest	`GET https://app.lexnus.com/mcp/tools` returns JSON Schema for every tool. It needs a token, the same as the server.
Data reachable	Only the accounts the token was granted: one for a personal access token, the ones the user ticked at consent for OAuth. Never another customer's data.
Outbound email	Only for e-signature, and only after a server-issued confirmation step.
Audit	Every tool call, read or write, is recorded to an append-only log under the tool's own name, with its outcome. Writes also record the entity, the operation, and before-and-after changes. Tool inputs and outputs are not stored.
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 reason, the contract excerpt behind a violation, 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. The consent screen lets the user withhold write access; see Authentication and scopes.

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", which is always granted, and "Create and modify contracts and playbooks, and analyse documents", which the user can untick.

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. List and switch between the accounts and workspaces the connection was granted.
`lexnous:write`	Create and modify contracts, run assembly, add versions, analyse documents, and operate the signing tools.

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

Scopes constrain OAuth connections the same way. The scopes the user approved are signed into the access token, and the scope check reads them from there. A refresh cannot add a scope the user did not approve. Within those scopes, the user's Lexnus role still applies.

The practical consequence for a reviewer: unticking write access on the OAuth consent screen produces a read-only connection. Every write tool refuses it and tells the client how to reconnect with write access. A personal access token scoped to lexnous:read does the same for scripts and clients configured by hand. Scopes govern MCP tool calls only: the same token used against the REST API is limited by the person's Lexnus role, not by its scopes.

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-seven tools. Write means the tool enforces lexnous:write before it does anything. Read tools need lexnous:read.

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_resolve_appendices`	Read	Reports which of a playbook's appendices — DPA, SLA, general terms, price list — apply for a set of field values, in document order, and which still depend on an unanswered field.
`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	Files a contract shared in chat. Given a playbook, starts its analysis; otherwise returns ranked playbook suggestions.
`lexnus_analyse_document`	Write	Runs a structured playbook analysis on a contract in Lexnus, or on pasted text without filing it as a contract. Write, because it stores the result and counts toward the account's analysis usage. Returns immediately and the client reads the result when it is ready. Pass `wait_seconds` (0 to 40) to get the result in the same call.
`lexnus_get_analysis_result`	Read	Fetches verdicts, the compliance score, 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.

Accounts and workspaces

Tool	Scope	What it does
`lexnus_list_accounts`	Read	Lists the accounts the signed-in user can reach, and which of them this connection may use.
`lexnus_switch_account`	Read	Moves the connection to another account the user approved at consent. It cannot reach an account the user did not approve, and it does not widen the token's scope.
`lexnus_list_workspaces`	Read	Lists the workspaces in the active account that the caller is a member of.

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. The one tool that names an account, lexnus_switch_account, can only move a connection between accounts the user approved at consent. A token cannot name any other 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. How the confirmation then happens depends on the protocol version the client speaks.

Clients on protocol version 2026-07-28 or later get 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. The model cannot satisfy this 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.

Older clients cannot be asked a question in the middle of a call. For them, the first call returns the full description of what is about to happen — the contract and every email address — together with a signed confirmation token. The tool proceeds only when called again with that token and exactly the same arguments, within about ten minutes, and only if the signing request has not changed in the meantime. This path is weaker, and we say so: the server cannot prove a human read the description before the second call. What it does guarantee is that the token authorises only what the description showed.

This matters for a specific risk: a contract is untrusted text. Text inside a document cannot quietly change who Lexnus emails. The confirmation is bound to the exact contract and recipients it described, so a changed recipient needs a new confirmation.

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 activity lands 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.

What an MCP client leaves in the log:

Every tool call, read or write. Each call writes one row with the event mcp.tool_called, the tool's name, its outcome (ok; failed for a refusal or validation error; confirmation_required or input_required when the call stopped to ask the person; or error), and how long it took. A read an AI client performed is on the record, not only in operational telemetry.
What each write changed. Writes also produce the ordinary audit rows for the records they touch, with before-and-after changes, filed under the same tool name. So one query shows a call and everything it changed.
Not the conversation. Tool inputs and outputs are not stored in the log. It records what an AI client did, not the contract text or prompts it passed through.

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 the token was not granted.
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 reach an account the token was not granted, even if a caller names it. lexnus_switch_account is the one tool that takes an account, and it moves only between accounts the user approved at consent.

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 by default. `wait_seconds` (up to 40) returns the result in the same call.
Session model	Stateless. No server-side MCP session to hijack.

Analyses run over MCP count toward the account's usage the same way as analyses run in the web application.

Reviewer checklist

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

Who can it reach? Only the accounts the token was granted: one for a personal access token, the ones the user approved at consent for OAuth. Account and workspace come from the authenticated principal on every call. The one tool that takes an account, lexnus_switch_account, moves only between those approved accounts.

Can it act without a human? It can read, draft, and analyse under a granted token. It cannot email a counterparty without a confirmation step the server itself issues. On current clients a human ticks that box; older clients must call again with a confirmation token bound to what was shown. See Security model.

Can we limit it to read-only? Yes. Untick write access on the OAuth consent screen, or use a personal access token scoped to lexnous:read. All twelve write tools reject either.

Is there a record? Yes, of every call — append-only, under the tool's own name, with the outcome. Writes also record the entity, the operation, and before-and-after changes. Tool inputs and outputs are not stored.

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.