Chaindoc MCP Server (Beta): Turn Claude and ChatGPT Into Your AI Document Employee

MCP 服务器是一个小程序,它让 Claude Desktop 或 ChatGPT 这样的 AI 助手可以像调用内置工具一样调用外部服务。Model Context Protocol (MCP) 由 Anthropic 在 2024 年 11 月推出,作为一项开放标准,把 AI 智能体连接到真实世界的系统。你不必再对 AI 说"解释一下 Chaindoc 怎么用",而是可以说"把这份 NDA 发给 John 签字",AI 会通过 MCP 服务器直接执行,不用复制粘贴、不用登录、不用切换工具。

Chaindoc MCP 是首个电子签名原生的 MCP 服务器,目前处于私人 Beta 阶段。它把 Claude Desktop、ChatGPT(通过 OpenAI Apps SDK)、Cursor 和 Zed 变成可用的合同全生命周期界面:起草、签署、验证、跟踪。说实话,第一次看着 Claude 替你起草并发出一份合同,感觉简直像在作弊。

这种转变是真实的。根据 Salesforce 2024《销售现状报告》,销售人员每周仅 28% 的时间真正用于销售;其余时间都花在合同起草、追讨文件、CRM 更新这类行政工作上。基于 MCP 构建的 AI 员工可以把这 72% 中的大部分压缩成聊天指令。Aberdeen Group 的研究显示,采用电子签名工作流的组织合同签署速度提升 80%,每位销售每月处理 22.6 份提案,而手动流程仅有 10.4 份。再叠加一个端到端接管工作的 AI 智能体,生产力上限会显著提高。

本指南介绍 Chaindoc MCP 服务器的能力、它与传统 API 集成的区别、Beta 阶段提供哪些功能,以及如何申请访问。如果想了解更广义的集成背景,可参考我们的 电子签名与文档自动化 REST API 页面以及现有的 Chaindoc 与 Pipedrive CRM 集成 指南。

在这里所说的 AI 员工不是冒充人类的聊天机器人。它是一个拥有特定工具集、并被授权代表你使用这些工具的 AI 智能体。MCP 协议给 AI 三样它过去没有的东西:一份可用工具的目录(像"创建文档""验证签名"这样的 Chaindoc 操作)、一种结构化的调用方式,以及一条读回结果的路径,以便规划下一步。

想想一名人类员工怎么处理一项合同任务。你给他发邮件:"把 NDA 发给 John,复制我们的标准 IP 条款,如果一周内没签就跟进"。他打开 Chaindoc,找到 NDA 模板,填写、发送,设置日历提醒以备跟进,到期日再查看状态。每一步都对应一个 Chaindoc MCP 工具:`chaindoc_create_document`、`chaindoc_create_signature_request`、`chaindoc_get_status`、`chaindoc_subscribe_webhook`。AI 智能体推断要按什么顺序调用哪些工具,并根据每一步的返回结果做出调整。

对你这位人类来说会发生什么变化:

• 你不用再为合同工作开 14 个浏览器标签了。大多数合同操作都集中到一个聊天界面里。
• AI 智能体处理无聊的中段(填写模板、盯紧签字、发送提醒),你只在开头(意图)和结尾(审核)介入。
• 审计跟踪不会变弱,反而更强,因为每一次 AI 操作都被 Chaindoc 以与人类操作完全相同的方式记录,并采用我们 审计跟踪合规指南 中描述的同一区块链锚定方式。

说句实在话,AI 智能体也会犯错。在指令含糊时,它偶尔会挑错模板、数错签字方,或发到错的邮箱。MCP 服务器会返回完整的错误信息,所以 AI 通常能在任务中段发现自己的失误,但对高价值合同,仍建议保留一道人工复核步骤。

大多数早期 MCP 服务器把 AI 智能体连到只读数据上:搜索网页、查数据库、读文件。电子签名不一样,它属于那种少见的工作流,价值不在于检索,而在于动作。AI 不只是告诉你某份合同的情况;它直接把合同发出去。这把生产力公式直接拉高一个数量级。

电子签名特别契合 MCP 有三个理由:

1. 1.
   离散且边界清晰的动作。 合同操作可以拆解为干净的原语(创建、发送、签署、验证、状态、列表)。AI 智能体擅长为一条指令选出合适的原语;它们对模糊的多步流程则没那么擅长。电子签名操作正是那种你能用一句话向初级员工交代清楚的事。
2. 2.
   审计跟踪要求严格。 大多数被 AI 智能体接管的工作流来源链都很弱。智能体真的发了那封邮件吗?数据干净吗?在 Chaindoc 中,每一次 AI 操作都落入一条防篡改的审计跟踪,锚定在公开区块链上,与人类用户操作得到的记录完全相同。这让 AI 驱动的合同签署在 ESIGN、eIDAS 与 SOX 层面默认合规;详见我们的 审计跟踪与法律证据指南。
3. 3.
   合同变体的长尾。 一家典型公司要处理几十种合同(NDA、MSA、SOW、供应商协议、劳动合同、承包合同)。每一种都因司法管辖、行业、相对方略有不同。AI 智能体能很好地应对这种多样性,因为它们能就模板和条款进行推断;基于规则的自动化做不到。

关于 Chaindoc MCP 正在 Beta 阶段测试的具体合同场景,可参阅我们已有的 软件公司承包商 NDA、承包商 W-9 表格指南 以及 独立承包商与雇员分类 等文章。

处于 Beta 阶段的 Chaindoc MCP 服务器对外暴露七个工具,覆盖完整的合同生命周期。每个工具都对应一个具体的 Chaindoc REST API 端点,MCP 层负责处理鉴权、响应解析与错误上下文,让 AI 智能体拿到的是它真正能据以推理的内容。

Beta 中可用的工具

• `chaindoc_create_document` ,上传文件或模板变体,返回文档 ID 与查看器 URL。AI 借助它根据聊天指令从模板起草。
• `chaindoc_create_signature_request` ,把文档发给一个或多个签字方,可选 KYC 校验、签字顺序与提醒计划。
• `chaindoc_get_status` ,返回签字请求的完整状态:谁已签、谁待签、活跃签字方的签字 URL,以及截至当前的审计跟踪。
• `chaindoc_verify_document` ,把 Chaindoc 签署的文档放入防篡改校验,返回签名证书、区块链锚点与完整性结果。
• `chaindoc_list_documents` ,带可选筛选条件(状态、日期范围、签字方邮箱)的分页文档列表。让 AI 在引用模糊时仍能挑出正确文档。
• `chaindoc_get_template` ,取出已存模板及其变量结构,让 AI 准确知道要填哪些字段。
• `chaindoc_subscribe_webhook` ,注册一个状态事件 webhook,返回 webhook ID 与 HMAC 密钥。用于设置异步通知,供 AI 后续轮询。

还未进入 Beta 的内容

发票工具、KYC 编排与多租户 OAuth 都在路线图上(见下方章节)。目前的 Beta 基于 API 密钥,这对个人用户与小团队足够,但暂未支持多租户生产部署所需的按用户 OAuth 流程。

如果你已经通过 REST API 与 SDK 集成了 Chaindoc,提出这个问题很合理:为什么再加一层?答案是 MCP 不是 API 的替代品;它是面向不同消费者的另一类接口。传统 API 集成是为代码而写的(后端服务、CRM 插件)。MCP 是为 AI 智能体而写的(Claude、ChatGPT、Cursor)。

MCP 服务器配置完成后(详见下方 Beta 访问章节),用户侧的流程就是对话式的。下面是 Beta 测试中的一个真实示例。

第一步:打开 Claude Desktop 并描述你要做什么

你输入:"把承包商 NDA 发给 John Smith,邮箱 john@acme.example,签字截止下周五,从我们的软件模板里复制 IP 转让条款。"

第二步:Claude 推断该调用哪些工具

Claude 调用 `chaindoc_get_template` 取出你的承包商 NDA 模板,识别出变量字段(对方姓名、邮箱、截止日期、司法管辖),并从你的标准库中合入 IP 转让条款。然后用填好的模板调用 `chaindoc_create_document`。

第三步:Claude 准备签字请求

Claude 调用 `chaindoc_create_signature_request`,带上 John 的邮箱、签字截止日期以及(可选的)KYC 校验。返回确认信息:"已根据模板 `Contractor NDA v3` 起草文档,发送至 john@acme.example,签字 URL 在 5 月 9 日(周五)23:59 UTC 之前有效。"

第四步:Claude 注册状态 webhook

Claude 调用 `chaindoc_subscribe_webhook` 监听 `signature.completed` 事件,这样 John 一签字,你就能在 Claude 内收到通知,无需自己轮询。整个流程从你最初的消息到签字请求出现在 John 的收件箱里,大约 60 秒。

第五步:完成时进行验证

John 签字后 webhook 被触发,Claude 报告结果。你可以让 Claude 验证签名,它会调用 `chaindoc_verify_document` 来确认区块链锚点、签名证书与审计跟踪。这就是你在 /verify-document 手动做的同一项验证,但直接在你最初对话的聊天里完成。

说实话,体验会因 AI 模型而异。Claude Desktop 目前最顺滑,因为 MCP 就是 Anthropic 做的。ChatGPT 通过 Apps SDK 也能跑得不错,只是延迟略高。如果你本来就生活在代码编辑器里,Cursor 与 Zed 表现很棒。协议是标准化的,所以随着时间推移,各客户端的体验应当趋同。

AI 智能体通过 MCP 服务器执行的每一项操作都会经过同一个处理人类操作的 Chaindoc 后端。没有影子路径、没有独立日志、没有所谓的"AI 旁路"模式。审计跟踪记录的就是我们 审计跟踪合规指南 中所述的七个必备字段,只多一项:AI 智能体的会话会被打标签,你能看到哪些操作由 AI 发起、哪些由人类发起。

具体来说:

• 身份:API 密钥(Beta 阶段)或 OAuth 用户令牌(GA 起)用于识别 AI 代为操作的人类账户。每一项操作都可以追溯到真实的人,而不是某个通用的"AI 智能体"身份。
• 认证:API 密钥可设定作用域(只读、写入、管理员),Beta 用户可以为特定 AI 客户端授予最小够用的访问权限。
• 操作来源:审计日志会记录该操作来自 MCP,以及来自哪个客户端(Claude Desktop、ChatGPT、Cursor 等)、调用了哪个工具。如果 Claude 替你发出了一份合同,记录会显示"通过 MCP 发送,客户端:claude-desktop,工具:chaindoc_create_signature_request,用户:alex@chaindoc.example"。
• 防篡改:每一条审计条目都按哈希链相连并锚定到公开区块链,与人类直接操作完全一致。AI 驱动的合同在抗辩力上不会逊于手动发送的合同;在某些方面甚至更强,因为结构化的工具调用和人类的聊天指令一同被保留了下来。

关于底层合规框架,可参阅我们关于 数字签名与 eIDAS、GDPR 和 NIST 合规 以及 区块链电子签名的法律效力 的文章。关于团队级访问控制(谁可以将 AI 客户端连到你的账户),参见 /team-management。

截至 2026 年 5 月,主要电子签名厂商均未推出公开的 MCP 服务器。最接近的对照是这些厂商现有产品中的 AI 功能公告(Docusign IAM 与 Docusign AI、Ironclad 的 AI 审阅工具),但都没有通过开放标准把这些能力开放给外部 AI 智能体。下表汇总了当前格局。

Beta 仅限邀请,名额有限,优先考虑活跃的 Chaindoc 客户与开发者占比高的组织。Beta 参与者可在正式发布之前免费使用,获得来自工程团队的专属 Slack 支持,并享有功能需求直通通道。

三种申请方式

1. 1.
   现有客户:登录 Chaindoc 控制台,在"设置"中找到"AI Agents"区域。Beta 开关就在那里。
2. 2.
   新评估者:通过 /api-integration 注册,并在开发者引导表单上勾选"MCP beta"选项。
3. 3.
   直接申请:发送邮件到 beta@chaindoc.io,简短描述你的使用场景(1-2 句)、团队规模以及你想接入的 AI 客户端(Claude Desktop、ChatGPT、Cursor、Zed)。我们会在两个工作日内回复。

拿到访问权限后的安装方式

Beta 以 npm 包的形式发布。收到 API 密钥后,把以下内容加入你的 Claude Desktop 配置(macOS 路径为 `~/Library/Application Support/Claude/claude_desktop_config.json`,Windows 与 Linux 上有相应路径):

重启 Claude Desktop。🔌 图标应显示"chaindoc"已连接,并提供七个工具。首次工具调用通常在 2-3 秒内完成。

Cursor、Zed 与 Windsurf 的配置方式类似;完整说明会随 Beta 邀请一起发出。通过 OpenAI Apps SDK 的 ChatGPT 支持目前在私人测试中,将在 Claude Desktop 进入 GA 后逐步开放。

当前 Beta 覆盖合同起草、签署、验证与跟踪。还有三项能力正在积极开发中,将在后续 Beta 阶段与 GA 中推出:

发票自动化

一个名为 `chaindoc_create_invoice` 的工具,可基于已签合同生成发票,带付款条款、明细行以及 Stripe / 电汇说明。该工具读取合同的付款计划,在正确的日期生成发票,并(可选)通过现有的 Chaindoc 审计跟踪发出。该能力建立在我们已有的 合同关联付款与账单自动化 之上,详见 电子签名后账单自动化 深度解读。

KYC 编排

一个名为 `chaindoc_request_kyc` 的工具,在签字方签字前触发身份核验。AI 智能体可以推断哪些签字方需要完整 KYC(高价值合同、受监管行业)、哪些只需轻量校验(标准 NDA),并据此配置签字请求。目前 KYC 仍由人类在请求层面配置;目标是把这一决策交给 AI。

多智能体工作流

再往后看,MCP 支持智能体之间的通信。也就是说,Chaindoc MCP 服务器可以呼叫一个 CRM MCP 服务器(HubSpot、Salesforce)、一个日历 MCP 服务器(Google、Outlook)或一个支付 MCP 服务器(Stripe)。一份签好的合同可以触发 CRM 更新、日历提醒与发票开具,全部由 AI 智能体协调,而不是写死的 webhook。这种架构让 AI 从写作工具变为真正的运营层。

如今,贴在已有产品上的 AI 功能随处可见。自动起草条款、智能红线、合同审阅摘要:每家老牌厂商都在推出。它们有用,但它们是功能。它们活在厂商自家界面里,需要人类用户来推动工作流。

AI 原生电子签名在结构上不同。价值单位不再是"我们的产品能为你做什么",而是"你的 AI 智能体能在它所处的任何地方代表你做什么"(Claude Desktop、ChatGPT、Cursor、你自己的定制客户端)。这改变了采购标准。合同执行速度的衡量不再是每份签字多少分钟,而是每个结果多少条聊天指令。审计跟踪不再只是防御性的合规功能,而是信任 AI 驱动工作流的前提条件。

Chaindoc 早早押注:这一品类将在未来 24 个月成为主流。MCP 服务器是迈出的第一步。如果你是现有客户,Beta 开关现已出现在控制台里。如果你正在评估带 AI 路线图的电子签名工具,可通过 /api-integration 申请 Beta 访问,并告诉我们你想接入哪个 AI 客户端。