de en es ja ko ru zh

artifactdiff-mcp

Name: artifactdiff-mcp
Author: wfengq

by wfengq

Overview Schema Source Related Servers Discussions Admin

Python

Local

ArtifactDiff

Ein Vertragsänderungs-Verifikations-Gate für Menschen und KI-Agenten.

Beweisen Sie, dass ein KI-Agent nur die von Ihnen autorisierten Office/PDF-Vertragsbedingungen geändert hat – semantisch, visuell und kryptografisch – bevor das Dokument ausgeliefert wird.

ArtifactDiff ist lokal-first und offline. Es wandelt eine angeforderte Änderung wie „Zahlungsfenster von 30 Tagen auf 45 Tage ändern“ in eine eingefrorene Richtlinie um, verifiziert den Kandidaten und schreibt ein unveränderliches Review-Bundle, das sowohl Menschen als auch Agenten einsehen können.

Projektstatus: 0.1.0 Alpha. Der vertragssichere Kern und der signierte Golden Path sind implementiert und durch mehr als 900 automatisierte Tests abgedeckt. Die Paketierung und die Automatisierung der öffentlichen Veröffentlichung sind noch in Arbeit.

Was es erkennt

Kandidat	Urteil	Liefer-Gate
Nur das exakte autorisierte Klauselvorkommen wurde geändert	PASS	Kann fortfahren
Die Änderung ist semantisch erlaubt, hat aber eine unerklärte Layoutänderung	REVIEW	Blockiert, bis ein Mensch diesen Befund genehmigt
Eine Partei, ein Betrag, ein Datum, eine Unterschrift, ein Siegel, ein Anhang oder andere geschützte Inhalte wurden geändert	FAIL	Blockiert und nicht genehmigbar

ArtifactDiff ist bewusst fail-closed. Review bleibt standardmäßig blockierend und ein FAIL-Befund kann nicht wegapprobiert werden.

Related MCP server: Decapod Intent Kernel

Golden Path in drei Minuten

Voraussetzungen: Python 3.11+ und ein lokaler Checkout dieses Repositorys. Die Demo verwendet nur synthetische Verträge und stellt nach der Installation der Abhängigkeiten keine Netzwerkanfragen.

python -m venv .venv
# Activate .venv using your shell, then:
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

Der Lauf erstellt drei unabhängig verifizierte, Ed25519-signierte Review-Bundles:

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

Der review-Fall bleibt blockiert. Um den signierten Ereignisketten-Übergang mit einem explizit simulierten synthetischen menschlichen Prüfer zu demonstrieren, verwenden Sie ein anderes Ausgabeverzeichnis:

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

--approve-review ist nur für die Demo. Echte Genehmigungen bleiben interaktive menschliche Aktionen über artifactdiff review oder artifactdiff approve; Agenten können ihre eigenen Befunde nicht genehmigen. Siehe den Golden-Path-Walkthrough für die generierten Dateien und Datenschutzgrenzen.

Der Workflow

Human instruction
      │
      ▼
contract-safe policy ── freeze + optional Ed25519 authorization
      │
      ▼
controlled agent edit session
      │
      ▼
semantic rules + protected entities + visual envelope
      │
      ├── PASS ───────────────────────────────► deliver
      ├── REVIEW ─► signed per-finding review ─► deliver or reject
      └── FAIL ───────────────────────────────► reject
                          │
                          ▼
                 immutable Review Bundle

Das Review-Bundle ist das System of Record. Der lokale Review-Desk ist nur eine authentifizierte Loopback-Schnittstelle über dieses Bundle.

Schnittstellen für Menschen und Automatisierung

Die gleiche Anwendungsgrenze versorgt jede Schnittstelle:

CLI: Richtlinien erstellen/validieren/siegeln, kontrollierte Sitzungen öffnen, Änderungen verifizieren, Befunde prüfen, Befunde genehmigen und Bundles verifizieren oder packen.
Lokaler Review-Desk: Ein Bundle prüfen und jeweils einen Befund signieren, ohne Verträge oder private Schlüssel an Browser-JavaScript zu senden.
MCP: begrenzte Inspect-/Draft-/Validate-/Local-Verify-Tools für KI-Agenten, mit getrennten Eingabe- und Ausgabe-Roots und ohne Genehmigungs- oder verifizierte Signierfunktion.
Offline-HTML: tragbare menschliche Review-Berichte, die mit verifizierten Fakten verknüpft sind.

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

Konfigurieren Sie für einen MCP-Host absolute, durch Pfadtrennzeichen getrennte Roots, bevor Sie den stdio-Server starten:

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

MCP kann absichtlich keine Befunde genehmigen oder verifizierte Signierungen durchführen.

Warum dies kein weiterer PDF-Diff ist

Gewöhnlicher Dokument-Diff	ArtifactDiff
Zeigt alles, was sich geändert hat	Beweist, ob Änderungen einer vorab autorisierten Anweisung entsprechen
Text oder Pixel sind das Endergebnis	Semantische, geschützte Entitäts-, Vorkommens-, Metadaten- und visuelle Regeln kombinieren sich zu einem Gate
Ein Screenshot/Bericht ist der Beweis	Content-adressiertes Review-Bundle mit Richtlinie, Fakten, Urteil, Beweisen, Signaturen und Append-only-Entscheidungen
Nur für eine Person gedacht, die zwei Dateien ansieht	CLI, Python, MCP, Offline-Bericht und menschlicher Review-Desk teilen ein gemeinsames Wahrheitsmodell
„Sieht gut aus“ könnte bestehen	REVIEW und nicht verfügbare Beweise blockieren standardmäßig

Sicherheits- und Datenschutzmodell

Lokal-first und offline; kein Konto oder Cloud-Dienst erforderlich.
contract-safe ist standardmäßig aktiviert, ohne implizite Autorisierung.
Exakte erwartete Änderungen sind an ihre Klausel und ihr Vorkommen gebunden.
Parteien, Geld, Währungen, Daten, Dauern, Prozentsätze, Kopf- und Fußzeilen, Unterschriften, Siegel und Anhänge sind standardmäßig geschützt.
Offline-Ed25519 ist der Kernvertrauensmechanismus; Unternehmensidentität kann später über Adapter hinzugefügt werden.
Beweise standardmäßig minimal; full ist explizit und sealed ist für benannte Empfänger verschlüsselt.
MCP-Antworten sind begrenzt und geben keine vollständigen Verträge, Seitenbilder oder Schlüsselmaterial zurück.

Lesen Sie das genehmigte Verification-Gate-Design und den Plan-4.5-Abnahmeprotokoll für das vollständige Vertrauens- und Urteilsmodell.

Aktuelle Formatunterstützung

PDF → PDF
DOCX → DOCX
DOCX → PDF
Englische, chinesische und zweisprachige Vertragsstruktur
Optionale DOCX-Rendering über LibreOffice; PDF-Rendering ist lokal

Entwicklung

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

Das Repository enthält derzeit Unit-, Integrations-, Manipulations-, CLI-, MCP-, Review-Desk-, Cross-Format- und signierte Golden-Path-Abnahmeabdeckung.

Nächste Meilensteine

Reproduzierbarer öffentlicher synthetischer Korpus und Zero-False-Pass-Gate
GitHub Action für die Überprüfung von Pull Requests mit Binärdokumenten
Demo-Medien und herunterladbares Beispiel-Review-Bundle
Schemata, Bedrohungsmodell, SBOM, Provenienz und signierte Alpha-Version
Plugin-Grenzen für Unternehmens-Parser, Renderer, Signierung, Verschlüsselung und Speicherung

ArtifactDiff wird um ein einziges enges Versprechen herum gebaut: Wenn ein Agent einen Vertrag bearbeitet, können Sie genau beweisen, was er ändern durfte – und dass er nichts anderes geändert hat.

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