de en es ja ko ru zh

artifactdiff-mcp

Name: artifactdiff-mcp
Author: wfengq

by wfengq

Overview Schema Related Servers Score Discussions

Python

Local

ArtifactDiff

Шлюз проверки изменений контрактов для людей и ИИ-агентов.

Докажите, что ИИ-агент изменил только те условия контракта Office/PDF, которые вы авторизовали — семантически, визуально и криптографически — до того, как документ будет доставлен.

ArtifactDiff работает локально и офлайн. Он превращает запрошенное изменение, например «изменить срок оплаты с 30 дней на 45 дней», в зафиксированную политику, проверяет кандидата и записывает неизменяемый Review Bundle, который могут проверять и люди, и агенты.

Статус проекта: альфа-версия 0.1.0. Контрактно-безопасное ядро и подписанный Golden Path реализованы и покрыты более чем 900 автоматическими тестами. Упаковка и автоматизация публичного выпуска всё ещё в процессе.

Что он выявляет

Кандидат	Вердикт	Шлюз доставки
Изменено только точное авторизованное вхождение условия	PASS	Можно продолжать
Изменение семантически допустимо, но есть необъяснимое изменение макета	REVIEW	Заблокировано, пока человек не одобрит это заключение
Изменена сторона, сумма, дата, подпись, печать, приложение или другой защищённый контент	FAIL	Заблокировано и не может быть одобрено

ArtifactDiff намеренно закрыт по умолчанию. Review остаётся блокирующим по умолчанию, и заключение FAIL нельзя одобрить.

Related MCP server: Proof Layer MCP

Трёхминутный 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

Запуск создаёт три независимо проверенных Review Bundle, подписанных Ed25519:

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 является системой записи. Локальный стол проверки — это только аутентифицированный интерфейс loopback поверх этого пакета.

Интерфейсы для человека и автоматизации

Одна и та же граница приложения обеспечивает работу всех интерфейсов:

CLI: создание/проверка/запечатывание политик, открытие контролируемых сессий, проверка изменений, просмотр заключений, одобрение заключений, проверка и упаковка пакетов.
Локальный стол проверки: просмотр пакета и подпись одного заключения за раз без отправки контрактов или закрытых ключей в JavaScript браузера.
MCP: ограниченные инструменты 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
Показывает всё, что изменилось	Доказывает, соответствуют ли изменения предварительно авторизованной инструкции
Текст или пиксели — конечный результат	Семантические, защищённые сущности, вхождения, метаданные и визуальные правила объединяются в один шлюз
Скриншот/отчёт — это доказательство	Content-addressed Review Bundle с политикой, фактами, вердиктом, доказательствами, подписями и append-only решениями
Предназначен только для человека, смотрящего на два файла	CLI, Python, MCP, офлайн-отчёт и стол проверки человеком используют одну модель истины
«Выглядит нормально» может пройти	REVIEW и недоступные доказательства блокируют по умолчанию

Модель безопасности и конфиденциальности

Локально и офлайн; не требуется учётная запись или облачный сервис.
contract-safe включён по умолчанию, без неявной авторизации.
Точные ожидаемые изменения привязаны к их условию и вхождению.
Стороны, деньги, валюты, даты, продолжительности, проценты, верхние и нижние колонтитулы, подписи, печати и приложения защищены по умолчанию.
Офлайн Ed25519 — основной механизм доверия; корпоративная идентичность может быть добавлена через адаптеры позже.
Доказательства по умолчанию minimal; full — явный, а sealed зашифрован для указанных получателей.
Ответы MCP ограничены и не возвращают полные контракты, изображения страниц или ключевой материал.

Прочтите одобренный дизайн шлюза проверки и запись о приёмке Plan 4.5 для полной модели доверия и вердиктов.

Текущая поддержка форматов

PDF → PDF
DOCX → DOCX
DOCX → PDF
Английская, китайская и двуязычная структура контрактов
Необязательный рендеринг DOCX через LibreOffice; рендеринг PDF локальный

Разработка

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

Репозиторий в настоящее время содержит модульные, интеграционные, тесты на вмешательство, CLI, MCP, review-desk, кросс-форматные и подписанные тесты приёмки Golden Path.

Следующие вехи

Воспроизводимый публичный синтетический корпус и шлюз нулевых ложных прохождений
GitHub Action для проверки pull request бинарных документов
Демонстрационные материалы и загружаемый пример Review Bundle
Схемы, модель угроз, SBOM, происхождение и подписанный альфа-релиз
Границы плагинов для корпоративных парсеров, рендереров, подписи, шифрования и хранения

ArtifactDiff создаётся вокруг одного узкого обещания: когда агент редактирует контракт, вы можете доказать, что именно ему было разрешено изменить — и что он не изменил ничего другого.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.9/5.0

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
Ambr A
io.github.getambr
Ricardian contracts for AI agents — dual-format, SHA-256 bound, legible by construction.
Legal & Compliance Autonomous Agents Blockchain
62
gateway B
ai.duvera
Governed AI actions with signed, verifiable receipts: free keyless reads, human-approved writes.
Security Autonomous Agents
522
InfraPulse A
ai.infrapulse
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Agent Orchestration Developer Tools
61

Related MCP Servers

WETH
Blockchain Cryptocurrency
ayushkumar2601
A
license
Not graded
quality
C
maintenance
Enables AI agents to analyze Ethereum wallets, simulate transactions, and draft transfers with deterministic policy and risk scoring, requiring human approval before on-chain execution.
Updated 2 months ago (2026-07-08 09:35 UTC)
11
ISC
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 4 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 3 months ago (2026-05-27 16:09 UTC)
-
@sequesign/mcp
Autonomous Agents Security
Sequesign
A
license
A
quality
A
maintenance
Enables AI agents to create cryptographically verifiable receipts of their delegated work, with capabilities for multi-party approval and offline verification.
Updated 17 days ago (2026-08-21 03:03 UTC)
11
162
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wfengq/artifactdiff'

If you have feedback or need assistance with the MCP directory API, please join our Discord server