Skip to main content
Glama
jiawei686

jev-legal-clause-mcp

by jiawei686
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

jev-legal-clause-mcp

🇨🇳 中文文档

Let your agent flag contract-clause risks with calibrated-probability structured decisions instead of parsing free-form LLM text. Powered by TypeSafe Jev (System One decision model).

A single-purpose MCP tool that turns a contract excerpt into calibrated risk annotations — each of 10 default risk classes returns a presence probability (0..1), plus an overall risk level and a "suggest human review" flag. Your agent gets verifiable risk labels, not a legal opinion.

npm install && npm run build
node dist/index.js doctor      # print dependency/mode diagnostics

Connect node dist/index.js in your MCP client and use the flag_clauses tool.

⚠️ This is not legal advice

This tool is a contract first-pass / triage aid. It uses a decision model to attach probability labels to clauses and cannot replace a lawyer. Always have a qualified human review any contract before signing. A high probability on one risk class does not mean the rest of the clauses are safe.

Related MCP server: safesign-mcp

Tool: flag_clauses

Input

Param

Type

Description

text

string

The contract excerpt to scan (a clause / a section / the whole thing)

types

string[]?

Optional, custom risk classes; defaults to the built-in 10

Default 10 risk classes

Class

Meaning

indemnification

Indemnification / hold-harmless obligations

non_compete

Non-compete / non-solicit

confidentiality

Confidentiality obligations

termination_penalty

Early-termination penalty

auto_renewal

Auto-renewal (renews unless notice given)

liability_cap_absent

Missing liability cap (unlimited liability)

ip_assignment

IP ownership / assignment

governing_law

Governing law / dispute venue

payment_terms

Payment-term risk (terms / penalty interest)

personal_guarantee

Personal guarantee (joint & several liability)

Output fields

Field

Meaning

clauses

Per class { category, label, present_prob }

flagged

Classes with present_prob > 0.7, sorted by probability descending

highest_risk

The highest-probability item in flagged (null if none)

overall_risk

{ score, label, confidence }, levels low / moderate / high / severe

review_recommended

Whether any flagged item exists or overall risk ≥ high

mocked

Whether running in mock mode

Gate logic

  • Any class with present_prob > 0.7 → enters flagged

  • flagged non-empty or overall_risk.score ≥ 2 → review_recommended = true

Before any action, check review_recommended + overall_risk.confidence first.

Example

{
  "clauses": [
    { "category": "indemnification", "label": "赔偿 / 补偿义务（hold harmless）", "present_prob": 0.92 },
    { "category": "governing_law", "label": "管辖法律 / 争议解决地", "present_prob": 0.81 },
    { "category": "non_compete", "label": "竞业限制", "present_prob": 0.12 },
    "…"
  ],
  "flagged": [
    { "category": "indemnification", "label": "赔偿 / 补偿义务（hold harmless）", "present_prob": 0.92 },
    { "category": "governing_law", "label": "管辖法律 / 争议解决地", "present_prob": 0.81 }
  ],
  "highest_risk": { "category": "indemnification", "label": "赔偿 / 补偿义务（hold harmless）", "present_prob": 0.92 },
  "overall_risk": { "score": 3, "label": "severe", "confidence": 0.83 },
  "review_recommended": true,
  "mocked": false
}

Zero-key / local-first

  • No TYPESAFE_API_KEY set → automatically enters mock mode (deterministic offline stub, zero-config for CI / demos)

  • JEV_MCP_MOCK=1 → force mock

  • Set TYPESAFE_API_KEY → call the real Jev API (default jev-latest @ https://api.typesafe.ai/v1/systemone)

Environment variables

Variable

Default

Description

TYPESAFE_API_KEY

—

Required for real calls; blank falls back to mock

JEV_MODEL

jev-latest

Model name

JEV_BASE_URL

Official endpoint

Override for self-hosted / proxy

JEV_MCP_MOCK

0

1 forces mock

JEV_MCP_TIMEOUT_MS

30000

Per-request timeout

Extremely low cost

A single decision is just one Jev call (10 noul + 1 score), state truncated at 60k characters, tens of thousands of tokens per call, with no LLM calls at all. Think of it as "one cheap gate in your contract pipeline".

Tests

npm test     # smoke + MCP protocol handshake (mock mode, no key needed)

License

MIT

Available Tools

1 tool
flag_clausesA

Legal-risk clause flagger powered by Jev (System One decision model). Given a contract excerpt, returns calibrated presence probabilities for 10 default risk categories (indemnification / non-compete / confidentiality / termination penalty / auto-renewal / liability cap / IP assignment / governing law / payment terms / personal guarantee) plus an overall risk score and a review recommendation. This is a triage aid — NOT a legal opinion. Always have a human review before signing.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe contract excerpt to scan (a clause, section, or whole paragraph).
typesNoOptional custom risk categories to scan. Defaults to the 10 built-in types.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the full disclosure burden. It does well by stating outputs (probabilities, risk score, recommendation), the underlying model (Jev System One), and the operational caveat that this is triage, not legal advice. It could mention read-only behavior or input limits, but the key behavioral boundaries are present.

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?

Four short, purposeful sentences. The first sentence identifies the tool, the second explains inputs and outputs, and the last two convey the critical limitation. No filler or redundant restatement.

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 triage/analysis tool with no output schema or annotations, the description adequately covers input, output categories, risk score, recommendation, and limitations. It stops short of specifying the exact response format or error conditions, but an agent has enough to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by enumerating the 10 default risk categories, which gives an agent concrete knowledge of what 'types' accepts even though no enum is provided. This goes beyond the schema's generic 'built-in types' phrasing.

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?

States a specific verb ('flag') and resource ('clauses'), and describes exactly what it does: accepts a contract excerpt and returns calibrated probabilities for 10 named risk categories, an overall risk score, and a recommendation. The output behavior is specific enough that an agent can distinguish this from generic text-analysis tools even without siblings.

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?

Clearly frames the tool as a triage aid to be used before signing, and explicitly warns it is not a legal opinion and requires human review. It lacks explicit when-not-to-use conditions or named alternatives, but with no sibling tools the context is sufficient.

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 observedflag_clauses
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

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusing it with another tool. The purpose is unambiguous and clearly described.

Naming Consistency5/5

The tool name flag_clauses follows a clear verb_noun convention. Even with only one tool, the name is descriptive, consistent, and easy to predict.

Tool Count2/5

A single tool feels extremely thin for an MCP server. While specialized, the server would benefit from additional tools such as batch processing, clause list retrieval, or analysis history to justify its existence as a server.

Completeness3/5

The core flagging operation is present and functional, but the surface is minimal. There are notable gaps such as no way to retrieve past analyses, no configuration of risk categories, and no multi-clause or document-level handling, which limits agent workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers