Skip to main content
Glama
carolyn-beep

ClauseWise

by carolyn-beep
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ClauseWise

Open-source, MCP-native, state-aware contract explainer for employees and independent contractors. It reads the paper the stronger party handed you, flags the clauses that deserve attention, explains what each one does in plain language, and cites the relevant state or federal rule with a primary-source link and an "as of" date.

ClauseWise provides legal information and education, not legal advice. It does not tell you whether to sign, does not predict how a dispute would end, and is not a substitute for a qualified attorney licensed in your state.

See docs/PLAN.md for the full project plan and docs/adr/ for the architecture decisions.

What it is

  • Jurisdictions: a federal overlay plus six priority states — California, New York, Texas, Washington, Illinois, Massachusetts.

  • Documents: NDAs, offer letters and employment agreements, separation/severance agreements, invention-assignment agreements (PIIAs), independent-contractor agreements, SOWs and payment terms.

  • Surface: one MCP server, shipped two ways — a local stdio package (your LLM does the reasoning, the contract never leaves your machine except to the model you already use) and a remote Streamable HTTP endpoint (required for ChatGPT).

Related MCP server: Plain English

What it is not

Not a lawyer, not legal advice, not a prediction of how a dispute would end, and not a recommendation to sign or not sign. The product name and tagline never use the words "lawyer" or "attorney".

Repository layout

packages/core      parsing, clause segmentation, schemas, retrieval, citation verification
packages/corpus    versioned rule cards (YAML) + loader/lookup + snapshot build
packages/mcp       FastMCP server (stdio + Streamable HTTP)
packages/evals     Inspect AI tasks, legal-fact suite, golden sets, red-team
packages/monitor   deterministic collectors + human-gated updater agent
packages/ft        fine-tuning benchmark (QLoRA clause classifier)
site/              Astro landing page

Quickstart

Requires uv and Python 3.12 (uv will fetch it).

uv sync --all-packages          # create the venv and install every workspace package
uv run ruff check .             # lint
uv run pytest -q                # unit + legal-fact tests
uv run clausewise-mcp           # run the MCP server over stdio
uv run clausewise-mcp --http    # run it over Streamable HTTP on :8000

Register the local server with an MCP client

Claude Code — already wired up via .mcp.json at the repo root; approve the server when prompted, then ask it to call lookup_rule.

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "clausewise": {
      "command": "uv",
      "args": ["run", "--directory", "/Users/carolyndriscoll/clausewise", "clausewise-mcp"]
    }
  }
}

Status

Phase 0 (foundations). Workspace, CI, schemas, a "hello" lookup_rule tool backed by three verified federal rule cards (OWBPA, FTC non-compete status, Speak Out Act), and the first legal-fact tests. Phase 1 (California corpus + RAG) is next; see docs/PLAN.md §15.

Licenses

  • Code: Apache-2.0 (see LICENSE).

  • Corpus plain-language summaries: CC BY 4.0.

  • Statute text: public domain.

Available Tools

1 tool
lookup_ruleLookup RuleA

Look up the employment-law rule card(s) for a state and topic.

Read-only. Returns the matching rule cards with citations, effective dates and a plain-language summary, plus the corpus version, the "as of" date and the ClauseWise disclaimer. This is legal information, not legal advice.

ParametersJSON Schema
NameRequiredDescriptionDefault
as_ofNoOptional ``YYYY-MM-DD`` date; rules not yet effective on that date are omitted. Defaults to today.
stateYes``"federal"`` or a two-letter state code (e.g. ``"CA"``, ``"MA"``).
topicYesA clause topic such as ``"release_timing"``, ``"noncompete"`` or ``"confidentiality_whistleblower"``.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does reasonably well: it declares 'Read-only', enumerates the returned payload (citations, effective dates, plain-language summary, corpus version, as-of date, disclaimer), and adds the important caveat that this is legal information, not legal advice. It stops short of disclosing auth/permission requirements or any rate/scope limits.

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?

Three sentences, purpose front-loaded in the first line, the output shape and the legal caveat following in order of decreasing importance. No sentence is filler; even 'Read-only.' earns its place since no annotations are supplied.

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 three-parameter read tool with full schema coverage and an output schema, the description covers purpose, mutability, payload contents, and the legal disclaimer. The one remaining gap is usage scoping (when this tool is the right choice, and what the corpus covers), which would be low-cost to add.

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 description coverage is 100%, so the schema already explains state format, topic examples, and the as_of omission semantics ('rules not yet effective on that date are omitted'). The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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 states a specific verb and resource with a precise domain: 'Look up the employment-law rule card(s) for a state and topic.' That is far more specific than a generic 'lookup' and tells an agent exactly what comes back. There are no sibling tools, so the sibling-differentiation clause cannot be satisfied, which keeps it just short of a 5.

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?

Usage is only implied: an agent can infer it should call this when it needs employment-law rules for a given state and topic, and the required state/topic parameters reinforce that. There is no explicit when-to-use, when-not-to-use, or alternative tool to route to, and no mention of the scope of the corpus (e.g. non-US jurisdictions).

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.1.0
    • First observedlookup_rule
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.7/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of overlap or misselection between tools. The lone lookup_rule has a clearly stated purpose (state+topic rule card retrieval).

Naming Consistency5/5

The single tool uses a clean, predictable verb_noun snake_case pattern (lookup_rule). With one tool there is no chance of inconsistent convention, though the sample is too small to demonstrate a real pattern.

Tool Count2/5

A single read-only tool is very thin for a domain like employment-law rule lookup, which naturally suggests discovery, listing, and comparison operations. The surface feels under-scoped for the apparent purpose.

Completeness2/5

Only one read-only lookup exists; there is no way to list available states/topics, browse the corpus, search across rules, or retrieve citations separately. Agents hitting an unknown state or topic name have no fallback path, creating dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers