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

人間とAIエージェントのための契約変更検証ゲート。

AIエージェントが、あなたが承認したOffice/PDF契約条項のみを変更したことを、文書が納品される前に、意味的・視覚的・暗号的に証明します。

ArtifactDiffはローカルファーストでオフライン動作します。「支払い期間を30日から45日に変更する」といった要求編集を凍結ポリシーに変換し、候補を検証し、人間とエージェントの両方が検査できる不変のReview Bundleを書き出します。

プロジェクトステータス: 0.1.0 アルファ版。契約安全コアと署名付きGolden Pathは実装済みで、900以上の自動テストでカバーされています。パッケージングと公開リリースの自動化はまだ進行中です。

検出内容

候補	判定	納品ゲート
承認された正確な条項の出現箇所のみが変更された	PASS	続行可
編集は意味的に許可されているが、説明のつかないレイアウト変更がある	REVIEW	人間がその所見を承認するまでブロック
当事者、金額、日付、署名、印、添付物、その他の保護コンテンツが変更された	FAIL	ブロックされ、承認不可

ArtifactDiffは意図的にフェイルクローズドです。レビューはデフォルトでブロック状態であり、FAIL所見を承認で解除することはできません。

Related MCP server: Decapod Intent Kernel

3分間のGolden Path

前提条件: Python 3.11以上、およびこのリポジトリのローカルチェックアウト。デモは合成契約のみを使用し、依存関係のインストール後はネットワークリクエストを行いません。

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

この実行により、3つの独立して検証されたEd25519署名付きReview Bundleが作成されます:

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

review ケースはブロックされたままです。明示的にシミュレートされた合成人間レビューアによる署名付きイベントチェーン遷移をデモするには、別の出力ディレクトリを使用します:

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

--approve-review はデモ専用です。実際の承認は、artifactdiff review または artifactdiff approve を通じた対話的な人間のアクションのままです。エージェントは自分の所見を承認できません。生成されたファイルとプライバシー境界については、Golden Path ウォークスルーを参照してください。

ワークフロー

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

Review Bundleがシステムオブレコードです。ローカルレビューデスクは、そのバンドル上の認証されたループバックインターフェースにすぎません。

人間と自動化のインターフェース

同じアプリケーション境界がすべてのインターフェースを支えています:

CLI: ポリシーの作成/検証/封印、制御されたセッションの開始、変更の検証、所見の検査、所見の承認、バンドルの検証またはパック。
ローカルレビューデスク: 契約や秘密鍵をブラウザJavaScriptに送信せずに、バンドルを検査し、一度に1つの所見に署名します。
MCP: AIエージェント向けの制限付き inspect/draft/validate/local-verify ツール。入力ルートと出力ルートは分離されており、承認や検証済み署名機能はありません。
オフラインHTML: 検証済みの事実にリンクされたポータブルな人間向けレビューレポート。

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

MCPホストの場合は、stdioサーバーを起動する前に、絶対パスをパス区切りで区切ったルートを設定します:

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

MCPは意図的に所見の承認や検証済み署名を行うことはできません。

これが単なるPDF差分ではない理由

通常の文書差分	ArtifactDiff
変更されたすべてを表示	変更が事前承認された指示と一致するかどうかを証明
テキストまたはピクセルが最終結果	意味的、保護エンティティ、出現箇所、メタデータ、視覚的ルールが1つのゲートに統合
スクリーンショット/レポートが証拠	ポリシー、事実、判定、証拠、署名、追記専用の決定を含むコンテンツアドレス型Review Bundle
2つのファイルを見る人のためだけに設計	CLI、Python、MCP、オフラインレポート、人間向けレビューデスクが1つの真理モデルを共有
「問題なさそう」で通る可能性	REVIEWおよび利用不可の証拠はデフォルトでブロック

セキュリティとプライバシーモデル

ローカルファーストでオフライン。アカウントやクラウドサービスは不要。
contract-safe はデフォルトで有効。暗黙の承認はありません。
正確な期待編集は、その条項と出現箇所にバインドされます。
当事者、金額、通貨、日付、期間、パーセンテージ、ヘッダー、フッター、署名、印、添付物はデフォルトで保護されます。
オフラインEd25519がコアの信頼メカニズム。エンタープライズIDは後でアダプターを通じて追加可能。
証拠はデフォルトで minimal。full は明示的、sealed は指定受信者向けに暗号化。
MCP応答は制限されており、完全な契約、ページ画像、鍵素材は返しません。

承認済みの検証ゲート設計とPlan 4.5 受入記録を読んで、完全な信頼と判定モデルを確認してください。

現在のフォーマットサポート

PDF → PDF
DOCX → DOCX
DOCX → PDF
英語、中国語、およびバイリンガル契約構造
LibreOfficeによるオプションのDOCXレンダリング。PDFレンダリングはローカル

開発

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

リポジトリには現在、ユニット、統合、改ざん、CLI、MCP、レビューデスク、クロスフォーマット、署名付きGolden Path受入カバレッジが含まれています。

次のマイルストーン

再現可能な公開合成コーパスとゼロ誤パスゲート
バイナリ文書のプルリクエストレビュー用GitHub Action
デモメディアとダウンロード可能なサンプルReview Bundle
スキーマ、脅威モデル、SBOM、来歴、署名付きアルファリリース
エンタープライズパーサー、レンダラー、署名、暗号化、ストレージ用プラグイン境界

ArtifactDiffは、1つの狭い約束を中心に構築されています: エージェントが契約を編集するとき、それが変更を許可された内容を正確に証明でき、それ以外は何も変更していないことを証明できるということです。

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