What can you do with this server?

Summary: This MCP server lets you locally inspect contracts, draft/validate/seal policies, compare documents, run contract-change verification, and review/verify Review Bundles — but it cannot approve findings or perform verified signing. * Compare two documents (DOCX/PDF) with optional visual comparison and output directory. * Inspect a document or contract, returning clause/heading and bounded inspection data. * Draft a contract policy from a baseline clause, anchor, and before/after text. * Validate a drafted policy against a baseline to ensure selectors can find the declared edit. * Seal a local policy into a sealed policy file. * Verify a contract change against a sealed policy, producing a Review Bundle. * List review findings from a bundle with pagination limits/cursors. * Get a specific review finding by ID from a bundle. * Verify a Review Bundle's digests and signature claims from disk. * Operate within configured absolute input/output roots, without returning full contracts, page images, or key material.

Which integrations are available for this server?

Integrates with LibreOffice for optional DOCX rendering, enabling visual envelope checks in contract verification workflows.

How do I use artifactdiff-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@artifactdiff-mcp Verify the contract change against the frozen policy" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

artifactdiff-mcp

by wfengq

Overview Schema Source Related Servers Discussions Admin

Python

Local

ArtifactDiff

ArtifactDiff is a local-first prototype that checks whether a contract edit matches a policy approved before editing. You declare the allowed clause change; the tool inspects a candidate DOCX or text-based PDF and returns PASS, REVIEW, or FAIL, then stores a content-addressed Review Bundle that can be verified later.

ArtifactDiff 是本地运行的合同修改核验原型：先指定允许的条款修改，再检查候选 DOCX 或带文字层的 PDF，给出 PASS / REVIEW / FAIL，并保存可校验的审查记录。

Status: 0.1.0 alpha. The signed synthetic Golden Path is implemented, and the repository has a large automated test suite. Broader real-contract evaluation and public packaging remain in progress. There is no PyPI release and no demo GIF in this repository.

Verdicts

Candidate	Verdict	Delivery decision
The expected clause occurrence changed, and the required evidence is available	PASS	May proceed under the configured policy
The edit appears allowed, but visual evidence is missing or contains an unexplained change	REVIEW	Blocked until a human reviews the finding
A protected value changed outside the authorization, or an expected edit is missing	FAIL	Blocked and not approvable

ArtifactDiff fails closed. REVIEW blocks delivery by default, and a FAIL finding cannot be approved away. A PASS is a software verdict under the configured policy. It is not legal approval of a contract.

Related MCP server: Decapod Intent Kernel

Run the synthetic Golden Path

Requires Python 3.11+ and a local checkout. After dependencies are installed, the demo generates synthetic contracts and makes no network request.

python -m venv .venv
# Activate .venv using your shell, then run:
python -m pip install -e ".[dev]"
python scripts/run_contract_golden_path.py --output build/contract-golden-path
python -m json.tool build/contract-golden-path/summary.json

The command writes three Ed25519-signed Review Bundles and verifies them from disk:

authorized    raw=pass    effective=pass
review        raw=review  effective=review
unauthorized  raw=fail    effective=fail

The review case stays blocked. To demonstrate a signed decision from a simulated human reviewer, use a separate output directory:

python scripts/run_contract_golden_path.py --output build/contract-golden-path-approved --approve-review

--approve-review exists only for the synthetic demo. In normal use, a person approves a finding through artifactdiff review or artifactdiff approve. An agent cannot approve its own finding. See the Golden Path walkthrough.

Verification flow

Human instruction
      |
      v
contract-safe policy: freeze and optional Ed25519 authorization
      |
      v
controlled edit session
      |
      v
semantic rules, protected values, and visual evidence
      |
      +-- PASS ------------------------------------> deliver
      +-- REVIEW --> signed human decision --------> deliver or reject
      +-- FAIL ------------------------------------> reject
                              |
                              v
              content-addressed Review Bundle

The Review Bundle stores the policy, comparison facts, verdict, evidence index, and signed events when verified assurance is enabled. The verifier recomputes digests and signature claims from the bundle bytes.

Interfaces

The same verdict and evidence data are available through:

CLI: create, validate, and seal policies; run verification; inspect findings; record human decisions; verify or pack bundles.
Local review desk: inspect a bundle and sign one finding at a time. Contract files and private keys are not sent to browser JavaScript.
MCP: inspect, draft, validate, and run local verification from bounded input and output roots. MCP cannot approve findings or perform verified signing.
Offline HTML: create a portable report linked to the recorded facts.

artifactdiff --help
artifactdiff policy --help
artifactdiff verify --help
artifactdiff review path/to/review-bundle

For an MCP host, set absolute input and output roots before starting the stdio server. Separate multiple roots with the platform path separator.

ARTIFACTDIFF_MCP_INPUT_ROOTS=/absolute/contracts
ARTIFACTDIFF_MCP_OUTPUT_ROOTS=/absolute/artifactdiff-output
artifactdiff-mcp

How this differs from a plain document diff

Plain document diff	ArtifactDiff
Lists changed text or pixels	Checks changes against a policy created before editing
Leaves every change for a person to interpret	Separates allowed edits, protected-value changes, and unavailable evidence
Produces a report or screenshot	Writes a content-addressed bundle with facts, evidence, verdicts, and optional signatures
Usually has one human-facing interface	Uses the same data through the CLI, Python API, MCP server, HTML report, and review desk
May treat missing evidence as no visible change	Returns a blocking verdict when required evidence is unavailable

Security and privacy model

The default workflow runs locally and does not require an account or cloud service.
contract-safe is enabled by default and grants no implicit authorization.
Expected edits bind to a clause, an occurrence, and the text before and after the edit.
Policy validation simulates declared edits and rejects selectors that cannot find the resulting clause. Use an unchanged context phrase as the selector anchor.
Recognized parties, money, currencies, dates, durations, percentages, headers, footers, signatures, seals, and attachments are protected by default.
Ed25519 signatures provide the implemented offline trust mechanism. Enterprise identity support is not implemented.
Evidence defaults to minimal. full is explicit, and sealed encrypts evidence for named recipients.
MCP responses are bounded and do not return full contracts, page images, or key material.

See SECURITY.md and the Golden Path acceptance record.

Supported inputs and current limits

Implemented paths:

DOCX compared with DOCX.
Text-based PDF compared with text-based PDF.
DOCX compared with a rendered PDF when LibreOffice rendering is configured.
Selected English, Chinese, and bilingual contract examples.

Material limits:

No OCR. A scanned PDF without extractable text cannot receive the same text verification as a text-based PDF.
Multi-column PDFs, tables, and unusual reading orders can produce incorrect text grouping and need human review.
Protected-value extraction uses deterministic patterns, not a legal NER model.
The Golden Path uses synthetic contracts. Selected external-document tests do not establish production accuracy or a zero-false-pass rate.
ArtifactDiff is an engineering prototype, not a substitute for legal review.

Inspect helper: independent headings

Python inspect_contract() and the MCP inspect_contract tool may also return independent_headings and truncated_headings. independent_headings is a bounded, best-effort list of visible headings for reviewer inspection. Selectors and authorization still use the clause tree. Hidden DOCX text is excluded. truncated_headings reports when response limits shorten the heading output. Multi-column PDF limits above still apply.

Evaluation

evaluation/ is a reproducible benchmark. It measures false passes (an unauthorized change judged PASS), false blocks (an authorized edit blocked) and draftability. It runs on a committed synthetic corpus, which CI gates at zero false passes, and on the CUAD v1 contract dataset. Both DOCX and text-layer PDF are covered.

python -m evaluation run --source synthetic --output build/eval/synthetic

Development

python -m pip install -e ".[dev]"
python -m pytest -q

CI already runs on GitHub Actions for pushes and pull requests to master (.github/workflows/ci.yml: ruff baseline checks, mypy --strict, and pytest on Python 3.11, 3.12, and 3.13, plus a wheel build and install smoke test).

More documentation pointers: docs/README.md.

Planned work

Broader real-contract evaluation and a measured false-pass gate.
A docs / binary-document pull-request review Action (not implemented yet; ordinary CI already exists as noted above).
Publish schemas, a threat model, an SBOM, provenance, and a signed alpha release.
Adapter boundaries for enterprise parsers, renderers, signing, encryption, and storage.

The project has one narrow goal: make an agent's permitted contract edit and the evidence for its verdict inspectable before delivery.

Available Tools

10 tools

compare_documentsD

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`visual`	No
`after_path`	Yes
`output_dir`	No
`before_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

draft_contract_policyD

ParametersJSON Schema

Name	Required	Description	Default
`after`	Yes
`anchor`	Yes
`before`	Yes
`heading`	Yes
`rule_id`	Yes
`clause_label`	Yes
`ancestor_path`	No
`baseline_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_review_findingD

ParametersJSON Schema

Name	Required	Description	Default
`finding_id`	Yes
`bundle_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

inspect_contractD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

inspect_documentD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`force`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_review_findingsD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`cursor`	No
`bundle_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

seal_local_policyD

ParametersJSON Schema

Name	Required	Description	Default
`output_path`	Yes
`policy_path`	Yes
`baseline_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

validate_contract_policyD

ParametersJSON Schema

Name	Required	Description	Default
`policy_path`	Yes
`baseline_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

verify_contract_changeD

ParametersJSON Schema

Name	Required	Description	Default
`visual`	No
`output_path`	Yes
`baseline_path`	Yes
`candidate_path`	Yes
`sealed_policy_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

verify_review_bundleD

ParametersJSON Schema

Name	Required	Description	Default
`bundle_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

10 tool updatesv0.1.0Aug 25, 2026
- First observedcompare_documents
- First observeddraft_contract_policy
- First observedget_review_finding
- First observedinspect_contract
- First observedinspect_document
- First observedlist_review_findings
- First observedseal_local_policy
- First observedvalidate_contract_policy
- First observedverify_contract_change
- First observedverify_review_bundle

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

D1.9/5.0

Scored 2026-08-25 09:10 across 10 tools

Disambiguation2/5

The tool set includes several pairs with ambiguous boundaries: inspect_document vs inspect_contract likely overlap, and compare_documents vs verify_contract_change seem to address similar tasks. Without descriptions, an agent would struggle to distinguish which tool to call for a given operation.

Naming Consistency5/5

All tools use a clear snake_case verb_noun pattern (compare, inspect, draft, validate, seal, verify, list, get). Consistency is high and follows a predictable convention.

Tool Count5/5

10 tools is within the ideal range for a domain covering document comparison and contract policy management. The count is well-scoped with no obvious bloat.

Completeness4/5

Core workflows for contract policy drafting/validation/sealing and review finding retrieval are covered. However, there is no tool for listing or managing documents/contracts, and the generic artifact diffing implied by the server name is thin, leaving minor but noticeable gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CodeRifts A
io.github.coderifts
Contract-change authorization for AI agents: preflight a change to an API or MCP contract, get a signed decision, and verify the receipt offline. Only a granted change can proceed.
API Testing Autonomous Agents Developer Tools
32
governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373
Covalt Execution Gateway
io.github.covaltpay
Trusted execution infrastructure for AI agents. Proposal-only protocol with human consent.
Agent Orchestration Security
1
VulnHunt Security Intelligence C
io.github.owenkingva-web
Read-only smart-contract security intelligence for autonomous agents.
Blockchain Penetration Testing Code Analysis
1

Related MCP Servers

Proof Layer MCP
Security Autonomous Agents
World-999-Labs
A
license
Not graded
quality
D
maintenance
Provides cryptographic governance receipts for AI agents, enabling pre-execution evaluation and signed verdicts (EXECUTE/BLOCK/REVIEW/SHADOW) with offline-verifiable audit trails.
Updated 5 months ago (2026-05-03 23:16 UTC)
MIT
Decapod Intent Kernel
Autonomous Agents Agent Orchestration
clauxel
F
license
Not graded
quality
D
maintenance
Enables AI agents to create intent contracts, check boundaries, record completions, and export receipts for structured agent workflows
Updated 5 months ago (2026-05-27 16:09 UTC)
-
wwall
Blockchain
axdvdv
F
license
Not graded
quality
C
maintenance
Enables AI agents to propose wallet payments while a local, human-authored policy decides whether each transaction is approved, requires human confirmation, or is refused, and records every decision in a signed, append-only ledger.
Updated 2 months ago (2026-08-22 23:48 UTC)
-
can2cup
Security Communication
ccqqder
A
license
Not graded
quality
B
maintenance
Enables users' AI agents to join signed, hash-chained rooms with another person's agent to negotiate, coordinate, or hand off work, while a locally enforced mandate filters every outbound message. Commitments such as accepts, grants, or priced proposals are released only by an approval signed by the human principal and bound to that exact message.
Updated 19 days ago (2026-09-24 01:25 UTC)
63 npm
Apache 2.0