LexPact MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LEXPACT_API_KEY | Yes | Your LexPact API key. | |
| LEXPACT_API_BASE_URL | No | Override the API base URL. Useful for testing against a local dev server. | https://lexpact.co.uk/api/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_contract_templatesA | List the 5 contract types LexPact can generate, their required/optional fields, and party role labels. Call this first if you don't already know the field requirements for a contract_type. |
| generate_contractA | Generate a UK jurisdiction-aware contract (nda, service_agreement, freelance_agreement, recruiter_terms_of_business, or ir35_agreement). Collect all required fields through conversation before calling — never invent party names, addresses, dates, or amounts. On a validation error, read error.suggestion in the response and fix the request yourself. |
| get_contractA | Retrieve a contract by id. Returns status "processing" while generation is still running (call again in about 30 seconds) and "completed" with the contract once done. content_markdown is always populated regardless of the original output_format — PDF URLs are only returned once, inline, by generate_contract. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a distinct phase of the lifecycle: discovery (list_contract_templates), creation (generate_contract), and retrieval (get_contract). The descriptions explicitly sequence them ('call this first', 'retrieve by id'), leaving no plausible misselection.
All three tools follow a strict verb_noun snake_case pattern (list_/generate_/get_ + contract object). Terminology is stable across names and descriptions.
Three tools is on the lean side, but each covers a necessary step and the server's scope is deliberately narrow (contract generation only). No tool feels redundant or padded.
The create-and-poll workflow is covered, but there is no way to list existing contracts, re-fetch a PDF URL after the initial generate response, or update/cancel a contract. Agents that lose the generate response or need an inventory are left with dead ends.