The way most freelancers write a contract is to open last year's signed one, save a copy, and change
every name. It works until the third find-and-replace, when a paragraph keeps the previous client's
jurisdiction and nobody notices for a year. MCP Clause Library replaces the copy with a library: the
paragraphs you reuse, kept as clauses with {{variables}} in them, searched, filled and
assembled into a numbered document.
Stated first because it decides how you should use the rest of the page. The 25 starter clauses are
generic freelance templates in plain language. They are not drafted for your country, your trade or your
deal, and no clause here has been reviewed by a lawyer. Every starter carries the note that it is a
generic template, and every document contract_assemble writes opens with the line: generic
template, not legal advice, have a qualified lawyer review this document before you sign it. That
sentence is a constant in the source, prepended to the .docx and to the markdown and
returned in the tool's own JSON response, so it cannot be lost by choosing a different output format.
Treat what comes out as the draft you take to a lawyer, not the contract you send to a client.
claude mcp add clauses -- npx -y @theluckystrike/mcp-clauses{
"mcpServers": {
"clauses": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-clauses"]
}
}
}The npm publish is pending, so until it lands use the .mcpb bundle from the latest
release or a clone and build. Per client paths are on the
setup pages. The document engine is shared with
MCP Docx, so a clone build lists both.
Twenty-five starter clauses across eleven categories, in assembly order: scope (scope of work,
revisions, acceptance of deliverables, change requests), payment (payment terms, late payment, kill fee,
rush fee), expenses, IP (assignment, portfolio and credit), confidentiality, data protection, term,
liability, warranty, disputes, and eight general clauses covering governing law, force majeure,
independent contractor status, non-solicitation, notices, entire agreement, severability and assignment.
clause_add puts your own next to them, and a deleted starter is not re-seeded on the next
call, so pruning the set to the ones you actually use is permanent.
A clause body holds placeholders such as {{client}}, {{contractor}},
{{project}}, {{fee}}, {{currency}},
{{payment_days}}, {{deposit_percent}}, {{late_fee_percent}},
{{liability_cap}}, {{notice_days}}, {{revision_rounds}},
{{acceptance_days}}, {{kill_fee_percent}},
{{rush_fee_percent}} and {{jurisdiction}}.
The tool that makes this usable is variables_list, which takes the clauses you picked and
returns every variable they need and which clause needs it, before you assemble anything. That
is the difference between filling in a form you can see and discovering a blank in Word. Variables are
read in first-appearance order, declared ones first and then any the body uses without declaring, so a
clause you wrote in a hurry still reports what it actually needs rather than what it claims to.
variables_list { clause_ids: ["scope-of-work", "payment-terms", "late-payment",
"intellectual-property-assignment", "governing-law"] }
-> client, contractor, project, fee, currency, payment_days,
late_fee_percent, jurisdictionAssemble with the values you have and the rest are not left as raw {{braces}}, not
blanked, and not invented. They come back as a visible bracketed prompt in the document text, such as
[late fee percent], and the response also returns the real names in
unfilled. The document you open is therefore readable by a human as a document, with the
unfinished parts obvious at a glance, while the machine-readable list of what is missing stays exact.
The prompt is printed with spaces rather than underscores for a measured reason. The shared document
engine parses inline markdown, so [late_fee_percent] reaches Word as
[latefeepercent]: the pair of underscores is read as an italic marker and dropped, taking
the word boundaries with it. Printing the prompt with spaces is both safe for the writer and easier for
a person to fill in, and unfilled keeps the underscored names for anything programmatic.
This is the sort of defect that never throws an error and never looks wrong enough to catch by eye.
clause_search ranks over titles, tags, categories and bodies, and a title match outranks
a body mention, so "late payment" finds the late payment clause rather than every clause that mentions
paying late. contract_assemble takes clause ids or whole categories, orders them by
category rank, numbers them, fills the variables, brackets what is missing, prepends the disclaimer and
writes .docx or markdown.
Assembling to markdown first is worth the extra call: it is the version you can read line by line in
an editor, and the .docx is the version you send. clause_export writes the
whole library to markdown on the free tier, which means the terms you reuse can live in a repository and
be diffed like anything else you maintain, rather than existing only inside one machine's data
directory. clause_import reads the same markdown shape back.
Free gives the 25 starters plus 10 clauses of your own, ranked search and category filtering, up to 8
clauses per assembled document, and markdown import and export. Pro ($19 once) gives unlimited clauses,
jurisdiction and tag filters, JSON import and export, unlimited clauses per document and version history
on clause_update. Everything stays on your machine and the server makes no network call at
all. Product page: MCP Clause Library. Side by side with the alternatives:
clause library comparison. The clause you agreed on payment terms is the
term you bill on: see recurring invoices and
Word proposals and contracts.
No. They are generic freelance templates in plain language, not drafted for your country, your trade or your deal, and no clause has been reviewed by a lawyer. Every assembled document opens with a line saying it is a generic template and not legal advice. Take the output to a qualified lawyer.
It is printed in the document as a visible bracketed prompt such as [late fee percent], never blanked and never guessed, and the response returns the exact names in unfilled. Run variables_list on your selection first and the document tells you what it needs before it exists.
Because the shared document engine parses inline markdown, so [late_fee_percent] reaches Word as [latefeepercent]: the underscore pair is read as an italic marker and dropped. The printed prompt uses spaces, and the machine-readable unfilled list keeps the real underscored names.
Yes. clause_export writes the whole library to markdown on the free tier and clause_import reads the same shape back, so the terms you reuse can be committed and diffed. JSON import and export is a Pro feature.
They do different things. MCP Docx writes a fixed freelance service agreement skeleton in one call. This server assembles a document from the specific clauses you keep and have edited, which is what you want once your terms have diverged from a generic template.