Skip to main content
Glama
open-agreements

open-agreements

by open-agreements
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

OpenAgreements

npm version License: Apache 2.0 CI codecov

OpenAgreements helps people and software agents find primary-source-backed U.S. legal guidance and produce reviewable DOCX files from standard agreement templates.

What OpenAgreements does

  • Publishes jurisdiction-specific practice guides with citations to primary law.

  • Provides standard agreement templates with source and license metadata.

  • Fills templates locally through a CLI or over MCP.

  • Publishes review checklists and comparison surveys in human- and machine-readable formats.

OpenAgreements provides legal information and document mechanics, not legal advice. It does not decide whether a form or clause is right for a transaction, and generated documents are drafts for human review.

The project’s longer-term goal is a citable conformance layer for legal AI: primary law becomes inspectable requirements, an AI can check a document against them, and a lawyer owns the final call. Read Why OpenAgreements Exists for the rationale; this README stays focused on using the project.

Related MCP server: legal-docs-mcp

Fill your first agreement

Install the CLI locally, inspect the available forms, and fill the Common Paper Mutual NDA:

npm install -g open-agreements
open-agreements list
open-agreements fill common-paper-mutual-nda \
  --set party_1_name="Jane Doe" \
  --set party_1_company="Acme Manufacturing, Inc." \
  --set party_2_name="John Smith" \
  --set party_2_company="Northeast Logistics LLC" \
  --set effective_date="2026-07-15" \
  --set purpose="Evaluating a potential logistics relationship" \
  --output mutual-nda.docx

The last command writes mutual-nda.docx. Open it in Word or another DOCX viewer and review every filled term before signature. Defaults supply the standard one-year term, Delaware governing law, and other omitted cover terms; the CLI reports any priority fields that still need attention.

For a complete, copyable example and field-review steps, follow the quick start.

Understand the workflow

standard form + source and license metadata
  → supplied field values
  → validation and local rendering
  → reviewable DOCX
  → human legal and business review

The standard form is authoritative until rendering. Your supplied values become the transaction-specific inputs. The generated DOCX is an output for review; it is never automatically accepted or signed.

The legal-content path is separate: practice guides cite primary sources, surveys compare jurisdictions, and checklists turn requirements into review steps. Those materials can inform a decision, but they do not mutate an agreement.

Choose your next step

Links: Website | Template Catalog | Docs | Trust | npm

Privacy and document handling

  • Local CLI and local stdio MCP processing stay on your machine.

  • Hosted MCP template filling runs server-side; filled documents are not stored after the response is returned.

  • Some field-selector workflows download an official source document at runtime.

Choose an execution mode that matches your document-sensitivity and internal policy requirements. See the trust-boundary status and security policy.

License

Project code is licensed under Apache License 2.0. Content retains its source-specific license. See the licensing reference and each template's metadata.yaml before redistribution or modification.

Available Tools

3 tools
fill_templateBInspect

Fill a template using local OpenAgreements CLI and return local path or inline base64.

ParametersJSON Schema
NameRequiredDescriptionDefault
templateYesTemplate ID, e.g. "common-paper-mutual-nda".
valuesNoTemplate field values passed to the fill command.
output_pathNoOptional output DOCX path. Defaults to a temporary location.
return_modeNoReturn local file path or inline base64 document data.

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnly=false and destructive=false. The description adds valuable context not in annotations: it mentions reliance on a local CLI tool and specifies the two return modes (local path vs inline base64). However, it omits details about error handling, temp file cleanup, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no redundant words. It front-loads the action ('Fill a template') and immediately follows with mechanism and return value information. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 100% schema coverage and simple 4-parameter structure, the description adequately covers the core operation. However, for a tool that interacts with the local filesystem and external CLI, it lacks guidance on error conditions, the relationship to sibling tools in a workflow, or prerequisites (e.g., CLI installation).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description mentions 'return local path or inline base64' which aligns with the return_mode parameter, but this merely echoes the schema without adding syntactic details, examples, or cross-parameter constraints (e.g., output_path behavior when return_mode is inline_base64).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides a clear verb ('Fill') and resource ('template') and specifies the mechanism ('local OpenAgreements CLI') and return formats. However, it does not explicitly differentiate from sibling tools 'get_template' and 'list_templates' within the text itself, only implicitly via the verb choice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states what the tool does but provides no guidance on when to use it versus the sibling tools (e.g., whether to call list_templates or get_template first to identify valid template IDs and required fields). No prerequisites or workflow context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_templateA
Read-only
Inspect

Fetch a single template definition with field metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
template_idYesTemplate ID, e.g. "common-paper-mutual-nda".

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds value by specifying 'field metadata' as returned content, but omits error behavior (e.g., what happens if template_id is invalid) or cache characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely efficient at 7 words. Front-loaded with verb 'Fetch'. Every word earns its place: 'single' distinguishes from list operations, 'field metadata' clarifies what the definition contains. No redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple read operation with one parameter and good annotations. The description covers the core behavior and hints at return value content ('field metadata'). Could improve by noting error cases (e.g., template not found) since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage for the single parameter, the schema fully documents the input requirements. The description provides no additional parameter semantics, which is acceptable given the schema completeness, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Fetch' with clear resource 'template definition' and scope 'single'. The phrase 'field metadata' distinguishes it from list_templates (which likely returns summary data) and 'Fetch' distinguishes it from fill_template (which implies mutation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'single' implies this requires a specific ID versus browsing with list_templates, but there are no explicit when-to-use guidelines or named alternatives. The agent must infer the workflow from the sibling tool names and the parameter requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_templatesA
Read-only
Inspect

List OpenAgreements templates as a paginated compact catalog. Returns lightweight metadata for discovery — call get_template for full per-field detail. Templates are returned in stable lexicographic order by template_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
cursorNoOpaque pagination cursor returned by a prior call. Omit on the first page.
limitNoPage size (default 25, max 100).

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. The description adds value by specifying stable lexicographic ordering by template_id, returning lightweight metadata, and mentioning pagination (default page size 25, max 100). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences front-load the purpose and nature, with no wasted words. Every sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with two parameters and no output schema, the description is fairly complete: it covers the tool's goal, usage context, ordering, and links to the sibling get_template. It could optionally mention that it lists all templates, but that's implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description adds context about pagination but does not provide additional parameter-specific meaning beyond what the schema already offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'List', the resource 'OpenAgreements templates', and the nature 'paginated compact catalog'. It distinguishes from the sibling tool 'get_template' by clarifying that this returns lightweight metadata for discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states that the tool is for discovery and suggests using 'get_template' for full detail, implying when to use this vs. that. However, it does not explicitly mention when not to use it or address the sibling 'fill_template'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.7.7
    • Changedlist_templates3 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Opaque pagination cursor returned by a prior call. Omit on the first page.",
+  "type": "string"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "Page size (default 25, max 100).",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
      • removedInput schema / properties / mode
        Removed value: -{
-  "description": "Response detail mode. Defaults to \"full\".",
-  "enum": [
-    "compact",
-    "full"
-  ],
-  "type": "string"
-}
  2. 3 tool updatesv0.5.1
    • First observedfill_template
    • First observedget_template
    • First observedlist_templates
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, non-overlapping purpose: list_templates discovers templates, get_template retrieves full details, and fill_template executes the filling process. No ambiguity between them.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (list_templates, get_template, fill_template), making their action and target immediately clear.

Tool Count4/5

Three tools is a reasonable size for a focused domain like template management. It covers the core operations of discovery and execution without being overly minimal.

Completeness4/5

The set covers the main workflow: list, retrieve, and fill templates. Missing create/update/delete operations, but these may not be part of the server's scope if templates are predefined externally.

Maintenance

ActivityActive
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers