EAD Enterprise Suite MCP

EAD Enterprise Suite MCP 服务

面向 EAD Enterprise Suite 的 MCP 服务，支持 AI Agent 处理签名、证据、通知和档案。

快速开始

npx -y @g-digital/mcp-ead-enterprise-suite

也可参阅 ONBOARDING.md，了解分步设置指南（≤ 5 分钟）。

安装渠道

此 MCP 已通过 g-digital MCP distribution pipeline 发布到所有主流 MCP 分发渠道。请选择适合你技术栈的渠道：

渠道	安装命令 / URL
npm	npx -y @g-digital/mcp-ead-enterprise-suite — npmjs.com/package/@g-digital/mcp-ead-enterprise-suite
Docker Hub	docker pull gdigital/ead-enterprise-suite:latest — hub.docker.com/r/gdigital/ead-enterprise-suite
MCP Official Registry	自动发现为 io.github.g-digital-by-Garrigues/ead-enterprise-suite — registry.modelcontextprotocol.io
n8n 社区节点	在 n8n Settings → Community Nodes 中安装 @g-digital/n8n-nodes-ead-enterprise-suite — npmjs.com/package/@g-digital/n8n-nodes-ead-enterprise-suite
Smithery	smithery mcp install g-digital/ead-enterprise-suite — smithery.ai/servers/g-digital/ead-enterprise-suite

所有渠道提供的 MCP 服务契约都相同；无论选择哪种安装方式，以下工具和环境配置均适用。

需要凭据？请访问：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

安装

Claude Desktop

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Claude Code（命令行）

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Cursor

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Windsurf

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Cline

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

VS Code

{
  "servers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

JetBrains

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Zed

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

需要凭据？请参阅：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Claude Desktop / Claude Code

添加到 ~/.claude.json 或 claude_desktop_config.json 中：

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "command": "npx",
      "args": ["-y", "@g-digital/mcp-ead-enterprise-suite"],
      "env": {
        "MCP_AUTH_USER_KEY": "your-user-key",
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io"
      }
    }
  }
}

Docker

docker run --rm -i \
  -e MCP_AUTH_USER_KEY=your-user-key \
  -e MCP_API_BASE_URL=https://api-eadcustody.eadtrust.gocertius.io \
  gdigital/ead-enterprise-suite:latest

环境变量

名称	必填	密钥	描述
MCP_ALLOW_INSECURE_FILE_URL	否	否	设置为 "true" 以允许 evidence_create 下载纯 http:// fileUrl（默认仅允许 https）。无论如何，都会拒绝私有/内部地址（在解析时检查；请参阅托管部署操作手册中记录的 DNS TOCTOU 限制）。
MCP_ALLOW_UNVERIFIED_BEARER	否	否	当 MCP_HTTP_PUBLIC=true 且未启用入站令牌内省时的应急选项：仅当上游网关已验证 Bearer 令牌时，才设置为 "true"。服务会记录醒目警告，并将未经验证的令牌转发至上游。
MCP_ALLOWED_HOSTS	否	否	以逗号分隔的允许使用的 Host 标头。留空 = 禁用 Host 验证（默认）。设置后，Host 不在列表中的请求将被拒绝。
MCP_ALLOWED_ORIGINS	否	否	以逗号分隔的允许使用的浏览器 Origin（用于防御 DNS 重绑定）。留空 = 拒绝任何携带 Origin 标头的请求；非浏览器客户端（CLI/SDK）不会发送 Origin，因此始终允许。使用 '*' 可允许所有来源。
MCP_API_BASE_URL	是	否	上游 API 根地址。必填：系统会向此主机提交用户密钥以换取会话令牌；未设置时服务不会启动。
MCP_AUTH_USER_KEY	是	是	长期有效的 EAD Enterprise Suite 用户密钥，系统会自动将其换成短期会话令牌。无头或自动化访问时，请使用此密钥而非账户密码。（有关获取凭据的信息，请参阅 https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/。）
MCP_HTTP_HOST	否	否	HTTP 传输绑定的网络接口。默认为 127.0.0.1（仅限本地主机）。设置为 0.0.0.0 可在所有接口上公开服务（容器会自动执行此设置）。
MCP_HTTP_MAX_BODY_BYTES	否	否	POST /mcp 请求正文可接受的最大字节数（默认值为 16777216 = 16 MiB，足以容纳文档所述工具限制内的 base64 文件上传）。超大请求会在读取前或读取过程中返回 413 JSON-RPC 错误，从而关闭公共部署中的内存耗尽 DoS 攻击途径。注意：base64 文件源会先受此限制，再应用 MCP_FILE_MAX_BYTES。
MCP_HTTP_PUBLIC	否	否	公共/多租户部署时设置为 "true"。此设置会启用 Host 验证，并要求同时满足以下条件，否则服务拒绝启动：(1) 已设置 MCP_ALLOWED_ORIGINS 或 MCP_ALLOWED_HOSTS；(2) 已配置入站 Bearer 内省（MCP_SVC_INTROSPECT_URL + MCP_SVC_CLIENT_ID/SECRET），或已显式设置 MCP_ALLOW_UNVERIFIED_BEARER=true（失败时默认拒绝）。
MCP_SVC_CLIENT_ID	否	否	此服务向上述内省端点提供的客户端 ID（即其资源服务器凭据）。仅在同时使用 MCP_SVC_INTROSPECT_URL 时需要；此 ID 不用于向 EAD Enterprise Suite 验证身份。
MCP_SVC_CLIENT_SECRET	否	是	此服务向上述内省端点提供的客户端密钥（即其资源服务器凭据）。仅在同时使用 MCP_SVC_INTROSPECT_URL 时需要；此密钥不用于向 EAD Enterprise Suite 验证身份。（有关获取凭据的信息，请参阅 https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/。）
MCP_SVC_INTROSPECT_URL	否	否	用于 HTTP 模式下入站 Bearer 验证的 RFC 7662 令牌内省 URL。需主动启用，且 MCP_HTTP_PUBLIC=true 时为必填。stdio（本地）模式下请留空。
PORT	否	否	在托管（HTTP）模式下运行时使用的 HTTP 端口；stdio 模式下忽略

变量	必填	描述
MCP_AUTH_USER_KEY	必填	长期有效的用户密钥（用于换取会话令牌）
MCP_OTEL_ENABLED	可选	设置为 true 以启用 OpenTelemetry 跟踪
MCP_API_BASE_URL	必填	上游 API 根地址。用户密钥会通过此地址进行身份验证，因此未设置时服务不会启动

内置技能

此软件包在 .claude/commands/ 下提供 Claude Code 斜杠命令。安装后，可在 Claude Code 中调用：

• /getting-started — 分步工作流指南
• /signature-lifecycle — 分步工作流指南
• /notification-lifecycle — 分步工作流指南
• /notification-attachments — 分步工作流指南
• /evidence-lifecycle — 分步工作流指南
• /dossier-lifecycle — 分步工作流指南

请参阅 docs/agent-prompts.md，了解端到端提示词示例及其触发的工具调用序列。

更倾向于直接使用 REST API 编写代码？

你不必通过此 MCP 服务。本仓库还提供了一个 Claude Code 技能——一份独立的集成指南（涵盖身份验证、调用顺序、选项、枚举和注意事项），用于直接通过 REST API 编程：

• 技能： .claude/skills/gocertius-suite-api/SKILL.md — 在 Claude Code 中打开此仓库，即可直接使用。
• 作为参考： docs/api-integration-skill.md。

它独立于 MCP 工具和 n8n 节点；请选择最适合你的集成方式。

可用工具

此服务提供 86 个工具：

工具	描述
evidence_create	在证据组中注册一条新证据记录。需要：evidence_group_create → evidenceGroupId、case_file_create → caseFileId。为 id 生成 UUID v4，并在调用前计算 SHA-256 十六进制哈希。内部流程：使用 custodyType INTERNAL 调用；响应会返回 uploadFileUrl（预签名 S3 URL）。将文件的原始字节 PUT 到 uploadFileUrl，然后通过 evidence_get/evidence_list 验证，只有完成后才能调用 evidence_seal。任何 INTERNAL 证据文件尚未上传时，都不要封存。外部流程：仅在有意创建仅含哈希的证据时使用 custodyType EXTERNAL；每条证据仍需使用新生成的 UUID。如果之前创建或上传证据失败且结果不确定，请先通过 evidence_list 验证再重试；除非确认未保存，否则不要重复使用同一个 id。警告：即使证据已成功保存，API 有时仍会返回 {code:'EvidenceCreateError'}。
evidence_list	列出指定证据组中的所有证据记录。需要：caseFileId 和 evidenceGroupId。返回分页列表，包含 ID、标题、状态和时间戳。
evidence_seal	封存证据组并触发合格 TSP 时间戳服务。需要：组内所有 INTERNAL 证据记录都已上传到各自的 uploadFileUrl，并通过 evidence_get/evidence_list 验证。需要 case_file_create → caseFileId 和 evidence_group_create → evidenceGroupId。将 evidencesCount 设为组内证据数量。异步：调用后，轮询 evidence_group_list，直到组状态变为 CLOSED，然后再关联到案卷或生成证书。
evidence_get	获取指定证据记录。需要：evidence_create → evidenceId、evidence_group_create → evidenceGroupId、case_file_create → caseFileId。返回状态（COMPLETED
evidence_group_create	在案卷中创建证据组。需要：case_file_create → caseFileId。为 id 生成 UUID v4。将 evidenceType 设为 FILE、PHOTO、VIDEO 或 WEB_PLUGIN。返回 evidenceGroupId。一个组可包含多条证据记录。
evidence_group_list	列出案卷中的所有证据组及其当前状态（OPEN、CLOSING、CLOSED）。用于查找现有组，或检查哪些组已可封存。需要：caseFileId。
dossier_create	创建案卷，将已认证的证据组合并为一个具有防篡改能力的 PDF。需要：case_file_create → caseFileId。关联前，证据组必须处于 CLOSED 状态。为 id 生成 UUID v4 字符串。返回 dossierId。创建后，使用 dossier_evidence_link 关联证据，然后通过 dossier_certify 认证。
dossier_update	更新现有案卷的元数据。需要：dossier_create → dossierId、caseFileId。仅当案卷处于 DRAFT 状态时可用。
dossier_certify	认证案卷，生成具有防篡改能力的 PDF，并锁定所有已关联证据。需要：dossier_create → dossierId、dossier_evidence_link（已关联证据）、case_file_create → caseFileId。异步：状态依次从 DRAFT → CERTIFYING → CERTIFIED。轮询 dossier_list，直到 dossierId 的状态为 CERTIFIED。
dossier_list	列出案卷中的所有案卷。需要：caseFileId。返回分页列表，包含 ID、名称、状态和创建日期。用于监控认证进度——轮询直到状态为 CERTIFIED。
dossier_list_by_user	列出某个用户名下所有案卷，涵盖其所有案卷文件。需要：userId（来自 session_login 或 session_info）。不知道案卷属于哪个案卷文件时使用此工具；已知 caseFileId 时使用 dossier_list。支持 filter、order 和 page。返回 { data, meta.totalElements }。
dossier_get	获取指定案卷的完整详情，包括状态、已关联证据和下载 URL。需要：caseFileId 和 dossierId。
dossier_template_list	列出可用的案卷模板。无前置条件。返回模板 ID 及其各语言译文。将返回的 id 用作 dossier_create 中的 dossierTemplateId。
dossier_preview	返回认证前案卷的 HTML 预览 URL。需要：caseFileId 和 dossierId。
dossier_document_url	返回已认证案卷 PDF 的下载 URL。需要：dossier_certify（CERTIFIED 状态）、caseFileId、dossierId。
dossier_package_url	返回完整案卷包（PDF + 证据文件）的下载 URL。需要：dossier_certify（CERTIFIED 状态）、caseFileId、dossierId。
dossier_visibility	更新已认证案卷的可见性（公开/私密）。需要：dossier_certify（CERTIFIED 状态）、caseFileId、dossierId。
dossier_delete	删除案卷。处于 DRAFT 状态时可删除（以在认证前丢弃），处于 CERTIFIED 状态时也可删除（永久移除已认证案卷）。此操作不可逆。需要：caseFileId 和 dossierId。
dossier_group_certify	通过一次调用，从一个已封存的证据组创建并认证案卷（快捷流程）。需要：evidence_seal（CLOSED）、case_file_create → caseFileId、evidence_group_create → evidenceGroupId。为 id 生成 UUID v4 字符串。返回状态为 CERTIFYING 的 dossierId → 轮询直到 CERTIFIED。
dossier_evidence_link	将已封存组中的证据项关联到案卷。需要：dossier_create → dossierId、evidence_seal（CLOSED）、case_file_create → caseFileId。传入证据 UUID 的 ids 数组。可多次调用，以关联来自不同案卷文件的证据。
dossier_evidence_list_to_link	列出可关联到案卷的证据项（尚未关联的 CLOSED 组）。需要：caseFileId 和 dossierId。
dossier_evidence_list	列出案卷某一个证据组中已关联的证据项。需要：caseFileId、dossierId 和 dossierEvidenceGroupId，三项缺一不可。若要列出案卷中的所有证据项（不论所属组），请改用 dossier_evidence_list_by_dossier。支持 filter、order 和 page。
dossier_evidence_list_by_dossier	列出案卷中关联的所有证据项，涵盖其所有证据组。需要：caseFileId 和 dossierId。这是案卷级视图；dossier_evidence_list 的范围更窄，仅列出单个组，且还需要 dossierEvidenceGroupId。支持 filter、order 和 page。返回 { data, meta.totalElements }。
dossier_evidence_get	获取案卷中已关联的指定证据项详情。需要：caseFileId、dossierId、evidenceId。
dossier_evidence_delete	从案卷中移除证据项。仅当案卷处于 DRAFT 状态时可用。需要：caseFileId、dossierId、evidenceId。
notification_document_add	为通知添加文档。分两步：此调用登记文件并返回 { url }（预签名上传 URL），然后将原始字节 PUT 到该 URL，并附带 x-amz-checksum-sha256 标头。为 id 生成 UUID v4，并在调用前计算文件的 SHA-256 十六进制哈希——将其填入 hash。顺序至关重要，顺序错误会导致发送失败：添加收件人之前，先添加所有文档；并等待每个文档达到 READY_TO_SEND（轮询 notification_document_list；大约需要 8 秒）后再调用 notification_request_send。在添加收件人后附加文档，或文档仍为 PENDING 时发送，都会返回 409/404 NOTIFICATION_NOT_FOUND。附件最大数量由订阅设置决定，而非固定的 API 限制，因此不要假定有固定数量。附件可以打包进投递证书——参见 notification_certificate_package_url。
notification_request_create	创建已认证通知请求。需要：case_file_create → caseFileId。为 id 生成 UUID v4。将 language 设为 en_GB 或 es_ES。返回 notificationRequestId。发送前，使用 notification_receiver_add 添加至少一名收件人。重要：content 字段必须是有效 HTML——不带 HTML 标签的纯文本不会显示在收件人落地页上。仅支持以下 HTML 格式：段落（ ）、粗体（）、斜体（）、无序列表（ ）、有序列表（ ）。不要使用其他 HTML 标签或 CSS。在 subject 中避免使用特殊排版字符（长破折号、弯引号）；请使用标准 ASCII 等效字符（连字符、直引号）。
notification_request_send	向所有已添加的收件人发送已认证通知。需要：notification_request_create → notificationRequestId、notification_receiver_add（至少一名收件人）、case_file_create → caseFileId。异步：触发投递。在生成证书前，轮询 notification_request_status，直到状态为 SENT 或更后续状态（PARTIALLY_READ、FULLY_READ）。
notification_request_status	检查已认证通知的投递状态。需要：notificationRequestId、caseFileId。返回状态（CREATING
notification_receiver_add	向通知请求添加收件人。需要：notification_request_create → notificationRequestId、case_file_create → caseFileId。id 可以是 UUID v4 或自定义字符串。返回 receiverId——请保存，以供 notification_certificate_get 使用。始终通过电子邮件投递；设置 sendWaUrl 可提供 WhatsApp 链接，设置 sendSmsUrl 可提供 RCS/SMS 链接（根据接收设备支持情况协商：设备支持 RCS 时使用 RCS，否则使用 SMS），设置 otpRequired 可要求收件人输入一次性验证码。以上三项中任意一项都需要 phonePrefix（带 +）和 phoneNumber。调用 notification_request_send 前添加所有收件人；但如果通知带有附件，必须先添加附件（参见 notification_document_add）。
notification_certificate_get	为指定收件人生成或获取 PDF 证书，证明通知已投递和／或已阅读／已回复。需要：notification_request_send、notification_receiver_add → receiverId、notificationRequestId、caseFileId。首次为该收件人请求证书时，为 id 生成 UUID v4；轮询时重复使用同一 id。仅当 notification_request_status 为 SENT 或更后续状态时调用；若通知类型需要收件人操作，优先等到 READ/ANSWERED 状态。首次调用可能返回 {}，因为证书仍在生成；请轮询／重新调用 notification_certificate_get，直到响应包含 pdfUrl/documentUrl 或 CERTIFIED／最终状态。如果后端返回 Forbidden/Unexpected，请停止轮询证书端点，改为轮询 notification_request_status；只有通知进入更完整的状态或界面显示证据可用后，才使用相同证书 id 重试。对于 ACCEPTED_OR_NOT 通知，在达到可认证的投递／阅读状态后调用一次，以生成中间证书；达到 PARTIALLY_ANSWERED/FULLY_ANSWERED 后再次调用，以生成最终答复证书。
notification_request_list	列出用户可见的已认证通知。需要 userId（来自 session_login、session_info 或 profile_get）——此列表以用户为范围，而非案卷文件，因此涵盖所有案卷文件，除非添加筛选条件。用于找回已丢失的 notificationRequestId；这是唯一的查找方式。每条通知返回：id、code、subject、status、type、sentAt、receiverStats 和所属 caseFile。可按 status 或 statuses（CREATING、DRAFT、IN_PROCESS、SENT、PARTIALLY_READ、FULLY_READ、PARTIALLY_ANSWERED、FULLY_ANSWERED）、caseFileIds、subject 的 search，或用于查找发送给指定收件人的 receiversSearch 筛选。支持分页。
notification_request_update	编辑尚未发送的通知：subject、content、type 和 language。需要 notificationRequestId 和 caseFileId。content 必须是有效 HTML——API 接受纯文本，但纯文本不会显示在收件人落地页上。仅支持以下标签： 、、、 、 ；不支持其他标签或 CSS。subject 仅使用纯 ASCII 字符，最多 100 个字符。已测试：通知发送后，API 会以 403 Forbidden 拒绝此操作，因此只能在发送前编辑。要更改通知所属的案卷文件，请使用 notification_request_case_file_move——此工具不会移动通知。
notification_request_delete	删除通知。需要 notificationRequestId 和 caseFileId。无法撤销。已测试：通知发送后，API 会以 403 Forbidden 拒绝此操作——已发送的通知属于投递证据，无法移除。若只想将其归档到其他位置，请改用 notification_request_case_file_move。
notification_request_duplicate	根据现有通知创建新的 DRAFT 通知，并复制其内容、收件人和附件。无论原通知处于何种状态均可使用，因此可借此重新发送给同一批人员，或将已发送通知用作模板。为 id 生成 UUID v4，并提供新的 subject；在请求正文中传入 caseFileId 可将副本放入其他案卷文件，省略则副本与原通知放在一起。副本采用异步构建：初始状态为 CREATING，收件人和文档数量均为零，之后才会填充；因此立即读取时看到的是一个暂时显示为空的通知。请轮询 notification_request_status，直到状态为 DRAFT，再检查或发送。由于收件人也会被复制，请在调用 notification_request_send 前使用 notification_receiver_list 检查收件人，否则会再次发送给原收件人列表。
notification_request_case_file_move	将通知移至其他案卷文件。注意两个 caseFileId 的区别：路径中的值是通知当前所在的案卷文件，正文中的值是目标位置。通知按案卷文件分组，这是更改分组的唯一方式（复制除外）。
notification_receiver_list	列出通知的收件人及其各自的投递状态。每位收件人返回：id、firstName、lastName、email、phonePrefix/phoneNumber、status（INVALID、READY_TO_SEND、SENT、READ、ANSWERED、ERROR）、statusUpdatedAt、收件人回复后出现的 answer、emailBounced，以及遭拒地址的 validationError（TAKEN、IS_DEFINED、IS_INVALID）。可在调用 notification_request_send 前检查是否有地址被标记为 INVALID，也可在发送后查看谁已阅读或回复。也可用于找回 notification_certificate_get 所需的 receiverId。支持分页；可按 id 筛选。
notification_receiver_update	更正收件人信息：firstName、lastName、email、phonePrefix、phoneNumber。需要 receiverId、notificationRequestId 和 caseFileId。可用于修正拼写错误的地址，避免删除并重新添加（那样会丢失 receiverId）。phonePrefix 必须包含 +（例如 +34）。若收件人需要接收 RCS/SMS 链接（sendSmsUrl）、WhatsApp 链接（sendWaUrl）或 OTP 验证码（otpRequired），则必须提供电话号码。
notification_receiver_delete	从通知中移除收件人。需要 receiverId、notificationRequestId 和 caseFileId。若要一次移除平台拒绝的所有地址，请使用 notification_receiver_invalid_purge，而不是逐个删除。
notification_receiver_add_bulk	一次调用添加多名收件人，而无需为每人分别调用 notification_receiver_add。将 receivers 作为数组传入；每个条目都需要 id（由你生成）、firstName、lastName 和 email，还可以包含 phonePrefix（带 +）和 phoneNumber。注意，此批量形式不接受单收件人工具支持的逐个收件人设置 otpRequired、sendWaUrl 或 sendSmsUrl 标志；请改为在请求上设置默认值（otpByDefault、sendWaUrlByDefault、sendSmsUrlByDefault）。收件人最大数量由订阅设置决定，而非固定的 API 限制；不同租户和平台的限制各不相同，因此不要假定固定数量——添加收件人并在超出该租户上限时读取错误信息。调用 notification_request_send 前添加所有收件人，然后通过 notification_receiver_list 检查结果，因为被拒绝的地址会显示为 INVALID。
notification_receiver_invalid_purge	一次调用从通知中移除所有状态为 INVALID 的收件人——即平台判定为格式错误或重复的地址。需要 notificationRequestId 和 caseFileId。其他状态的收件人不会受影响。无效收件人会阻止发送，因此请在调用 notification_request_send 前运行此工具（或使用 notification_receiver_update 修正地址），否则通知无法发出。先使用 notification_receiver_list 查看将被移除的对象。
notification_document_list	列出通知所附文档及其处理状态；添加文档后需轮询此工具：新登记的文档初始状态为 PENDING，大约 8 秒后达到 READY_TO_SEND。只要仍有文档处于 PENDING，调用 notification_request_send 就会失败，并返回 409/404 NOTIFICATION_NOT_FOUND。使用有限次数重试——每隔几秒轮询一次，最多尝试十几次。需要 notificationRequestId 和 caseFileId。支持分页。
notification_document_delete	从通知中移除附件。需要 documentId（来自 notification_document_list）、notificationRequestId 和 caseFileId。
notification_document_download_url	返回 { downloadUrl }，即附件发送时版本的临时链接。需要 documentId（来自 notification_document_list）、notificationRequestId 和 caseFileId。用于取回你附加的文件，或验证收件人收到的内容。该 URL 为预签名链接，且会过期；需要时再获取，不要保存。
notification_certificate_list	列出为某位收件人生成的投递证书，以便复用而非重复生成。需要 receiverId、notificationRequestId 和 caseFileId。每份证书返回：id、status（DRAFT、CERTIFYING、CERTIFIED）、language、createdAt、certifiedAt、partial（表示是否为收件人完成回复前签发的中间证书）以及 embeddedDocuments。不要将 embeddedDocuments 理解为“证书包中包含附件”：在一次已测试的运行中，通知有附件但该值为 false，而 notification_certificate_package_url 仍返回了包含附件的 ZIP。证书达到 CERTIFIED 后，使用 notification_certificate_document_url 下载证书本身，或使用 notification_certificate_package_url 下载包含附件的 ZIP。
notification_certificate_document_url	返回证书 PDF 自身的 { documentUrl }，不含附件。需要 certificateId、receiverId、notificationRequestId 和 caseFileId。等待证书达到 CERTIFIED：生成是异步的，仍处于 CERTIFYING 时，首次调用可能返回 404 或空结果；请有限次轮询，而不要频繁请求。若要将附件一并打包，请改用 notification_certificate_package_url。
notification_certificate_package_url	返回包含证书和通知附件的 ZIP 的 { packageUrl }，即“附带附件”版本。API 中没有单独的预览标志：package 包含附件，document 仅包含证书本身。需要 certificateId、receiverId、notificationRequestId 和 caseFileId。前置条件与 notification_certificate_document_url 相同——等待证书达到 CERTIFIED，并注意生成过程中首次调用可能失败。
case_file_create	创建新的案卷文件——这是所有相关操作（证据、通知、签名、案卷）的顶层容器。在任何其他操作之前先调用此工具。为 id 生成 UUID v4。返回后续调用所需的 caseFileId。
case_file_list	列出 EAD Enterprise Suite 账户中的所有案卷文件。传入 userId（来自 session_login 或 session_info）可将结果限定为你的账户。返回分页列表，包含 ID、名称和状态。
case_file_get	获取指定案卷文件的详情。需要：caseFileId。用于在创建证据组、案卷或签名请求前确认案卷文件存在。
case_file_delete	删除案卷文件及其中归档的所有内容——证据组、案卷、通知及其证书。此操作不可逆，没有确认步骤，也没有回收站。需要：caseFileId。不返回正文（HTTP 204）；请通过 case_file_list 确认。除非用户要求销毁该案卷文件，否则不要调用此工具进行“清理”。
session_login	强制 MCP 服务向 EAD Enterprise Suite 重新进行身份验证。不需要任何参数，也不接受凭据——服务会将配置的用户密钥（MCP_AUTH_USER_KEY）重新交换为新的会话令牌，并报告生成的 userId 和过期时间。MCP 服务会自动管理身份验证；只有遇到 401 错误时才调用此工具。如果服务本身没有凭据（未配置，或你提供了自己的 Bearer 令牌），则没有可供续期的本方会话，此工具会返回一条提及 MCP_AUTH_USER_KEY 的错误。
session_info	获取当前已认证会话的信息：userId、type（此 MCP 会话的身份验证方式——始终为 UserKey，这是服务唯一的身份验证流程）、accountLoginType（另一项信息：EAD Enterprise Suite 账户本身的登录方式，可能为 Password 或 OpenId；若 API 未提供则为 null）、email、companyId 和 defaultCaseFileId。身份信息通过 GET /profile 获取。如果只需要 userId，优先使用 profile_get——它是权威来源（id），并会返回其余个人资料信息。无必需参数。
profile_get	返回已认证用户本人的个人资料。仅根据会话令牌识别调用者——无需提供 email 或其他输入，因此在所有部署中均可使用，包括按请求提供 Bearer 令牌的部署。其 id 字段就是你的 userId（UUID）：case_file_list 和所有 /users/{userId}/... 操作所需的值。需要 userId 时优先使用此工具，而非 session_info：它是权威来源。还会返回 companyId（订阅通知 SSE 流所需）和 defaultCaseFileId。还会返回 permit，这是一个布尔值集合——{ evidences, idVerifications, notifications, chats, signatures }——表示此账户可以使用哪些工具类别：值为 false 表示该类别中的所有工具都会返回 403，无论输入为何；重试或更改参数都无济于事。首次调用某个类别中的工具前请先读取该字段；在 2026-09-07 检查的集成部署中，permit.idVerifications 为 false，所有身份验证工具均返回 403 NoIdVerificationsPermit。无需参数。
use_case_list	列出账户可用的用例。用例定义允许的签名工作流和文档类型。返回 signature_request_create 所需的 useCaseId 值。
id_verification_video_create	为一人发起远程视频身份验证：平台会联系该人员并进行身份识别会话。需要：id（由你生成的 UUID v4）、name、firstSurname、email、phonePrefix 和 phoneNumber。phonePrefix 必须包含开头的 +（例如 '+34'）。secondSurname 为可选项。返回 HTTP 201，无正文，因此请保留生成的 id——它就是 verificationId；只有通过 id_verification_list 才能查看结果。受权限限制：先调用 profile_get 并检查 permit.idVerifications；若为 false，此处每次调用都会返回代码为 NoIdVerificationsPermit 的 403，更改参数也无济于事，因此请报告此情况而不要重试。上游已弃用现场（面对面）身份验证，因此本工具不会提供该功能。
id_verification_list	列出属于某个用户的身份验证及各自结果。需要：userId（来自 profile_get）。条目为 { id, email, name, firstSurname, secondSurname, status, identificationType, createdAt, createdBy, rejectedReason, rejectedContext }，可在此查看验证是否成功，以及未成功时的原因。支持 filter、order 和 page。这是查看 id_verification_video_create 结果的唯一方式，因为后者不返回正文。受权限限制：当 profile_get 报告 permit.idVerifications === false 时，返回代码为 NoIdVerificationsPermit 的 403。
id_verification_contract_url	获取某项已完成身份验证的已签署合同。需要：verificationId——即为 id_verification_video_create 生成的 id，或来自 id_verification_list 的 id。注意：OpenAPI 规范声明此操作返回 200 且无正文，因此确切响应内容未在规范中声明，且尚未在可正常运行的部署中观察到；请检查实际返回内容，不要假定其中有特定字段。受权限限制：当 profile_get 报告 permit.idVerifications === false 时，返回代码为 NoIdVerificationsPermit 的 403。签署合同需要两个有效的一次性验证码，因此不会作为工具提供。
signature_group_create	为可配置签名请求创建签署顺序组。类型：'Document'（将文档分为多个签署轮次——在 signature_request_add_document 中将其 id 用作 groupId）、'Signatory'（将签署人分为多个签署轮次——在 signature_participant_create 中将其 id 用作 groupId）、'DocumentSignatory'（将特定文档关联到某个签署轮次，需要 documentId）。重要——避免创建空组：创建 CONFIGURABLE 请求时，API 会自动预先创建一个 Document 组和一个 Signatory 组，两者的 index 均为 1。第一个文档和第一名签署人始终使用这些已存在的 index:1 组（创建请求后立即通过 signature_group_list 获取其 ID）。仅为额外组（index:2、3……）调用 signature_group_create。添加参与者时设置 linkToAllDocuments:true，以便自动生成 index 正确的 DocumentSignatory 组。若添加参与者时不设置 linkToAllDocuments，则他们不会关联到文档，signature_coordinate_set 会失败并报错 'Signatory not found'。
signature_group_list	列出可配置签名请求中的所有签署顺序组。每个组返回 id、type（Document/Signatory/DocumentSignatory）、index 和 documentId。调用 signature_request_create 后立即调用此工具，以便在添加文档或参与者前获取预先创建的 index:1 组 ID。
signature_request_create	创建新的签名请求，初始状态为 DRAFT。需要：case_file_create → caseFileId。为 id 生成 UUID v4。将 deadline 设为 ISO 8601 日期时间（最多约 30 天后）。返回 requestId。激活前，使用 signature_request_add_document 添加文档，使用 signature_participant_create 添加参与者。
signature_request_get	获取签名请求的完整详情。需要：signature_request_create → requestId、case_file_create → caseFileId。返回状态、文档、参与者、截止时间和历史记录。用于检查整体流程状态。
signature_request_cancel	取消已激活的签名请求。需要：activate_signature_request（ACTIVE 状态）、requestId、caseFileId。状态将变为 CANCELLED。无法撤销。
signature_request_add_document	向处于 DRAFT 状态的签名请求添加文档。需要：signature_request_create → requestId、case_file_create → caseFileId。为文档提供字符串 id；同一个 id 也作为坐标和证书所需的 documentId。调用前计算 PDF 的 SHA-256 十六进制哈希。返回 url（预签名 S3 上传 URL）。必须将 PDF 的原始字节 PUT 到 url，然后在激活前等待后端完成处理：如果 API 提供处理状态，请轮询 signature_request_get，直到状态为 processed/READY_TO_SIGN；如果响应中不包含文档处理字段，则在 PUT 成功后等待一小段处理时间，设置 PDF 坐标，然后激活并通过 signature_request_get 确认状态为 ACTIVE。signature_document_list 会报告文档级状态和 signatoryCoordinatesStats（可用于检查坐标前置条件），但尚未验证其是否会报告新添加文档的上传处理状态——请使用 signature_request_get 检查。调用 activate_signature_request 后无法再添加文档。对于 CONFIGURABLE 顺序：groupId 必须指向 Document 类型的组（不能是 Signatory 或 DocumentSignatory）；传入错误的组类型会返回 'Signature group not found'。
signature_document_list	列出签名请求中的文档及文档级状态和逐文档统计信息。需要：signature_request_create → requestId、case_file_create → caseFileId。条目为 { id, requestId, groupId, status, title, fileName, fileSize, convertToPdf, participantStats, signatoryStatusStats, signatoryCoordinatesStats }——例如，状态为 PARTIALLY_SIGNED，signatoryStatusStats 为 { pending: 0, readyToSign: 1, signed: 1, rejected: 0 }，signatoryCoordinatesStats 为 { defined: 2, missing: 0 }（2026-09-07 在 INT 环境中实时读取）。signatoryCoordinatesStats.missing === 0 可直接用于确认 activate_signature_request 前所有必需签署人均已设置坐标。尚未验证此状态是否也会报告新添加文档的上传处理情况——仍请使用 signature_request_get 检查。要查看某份文档的签署人，请使用 signature_document_signatory_list。
signature_document_signatory_list	列出签名请求中某份文档的签署人，以及每位签署人在该文档上的状态。需要：signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId。条目为 { id, groupId, email, firstName, lastName, status, coordinates, uniqueValidator, phonePrefix, phoneNumber, participantStats }；status 为 PENDING、READY_TO_SIGN、VALIDATING、SIGNED 或 REJECTED。每个 id 都是 signatoryId。要在 activate_signature_request 前检查文档本身是否已达到 READY_TO_SIGN，请使用 signature_request_get；激活后，请在调用 signature_certificate_get 前轮询此工具，直到所有签署人均为 SIGNED。
signature_document_observer_list	列出签名请求中某份文档的观察者——即以 OBSERVER 角色创建、会收到副本但不会签署的参与者。需要：signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId。条目仅包含 { id, email, firstName, lastName }：此处有意不提供 status 字段，因为观察者无须完成任何操作。要查看同一文档的签署人，请使用 signature_document_signatory_list。
signature_signatory_progress_list	列出签名请求中分配给某一名签署人的文档，以及该签署人在每份文档上的进度。需要：caseFileId、requestId 和 signatoryId。signatoryId 是角色为 SIGNATORY 的参与者的 id——从 signature_participant_list 或 signature_document_signatory_list 中读取。传入角色不是 SIGNATORY 的参与者 id 会返回 404 'Signatory not found'——2026-09-07 在 INT 环境中使用 VALIDATOR id 观察到此情况；两类 ID 共用一个 ID 空间，但以签署人为范围的端点只接受 SIGNATORY 参与者的 ID。返回 { data, meta.totalElements }，条目为 { id, fileName, fileSize, status }，其中 status 为 PENDING、READY_TO_SIGN、SIGNED 或 REJECTED。
signature_participant_create	向 DRAFT 状态的签名请求添加一名参与者。这是唯一的参与者创建端点：role 用于指定 SIGNATORY（必须签署）、OBSERVER（接收只读副本）或 VALIDATOR（必须先批准，签署人才能签署）。需要：signature_request_create → requestId、case_file_create → caseFileId，以及 role、firstName、lastName 和 email。由你生成 id（UUID v4）；调用返回 HTTP 201，无正文，因此不会返回任何 ID——你生成的 id 就是 participantId；若传入 role SIGNATORY，它也是 signatoryId；若传入 role VALIDATOR，它就是 validatorId。请妥善保存。对于 ADVANCED 签名，必须提供 phonePrefix 和 phoneNumber，因为签署人会在此接收 OTP；ADVANCED 不支持 WhatsApp 投递。对于 INTERPOSITION，电话为可选项，且平台配置后可使用 WhatsApp。激活前至少添加一名 SIGNATORY。对于 role VALIDATOR，不要包含 groupId 或 linkToAllDocuments——稍后使用 assign_validator_to_signatory 将其关联。批量添加时使用 signature_participant_add_bulk；重新读取现有参与者时使用 signature_participant_list。
signature_participant_add_bulk	一次调用向 DRAFT 状态的签名请求添加多名参与者，而无需为每人分别调用 signature_participant_create。需要：signature_request_create → requestId、case_file_create → caseFileId，以及 participants 数组；其条目使用与 signature_participant_create 相同的字段，包括为每人生成的 id 和 role。允许在一次调用中混合多种角色。返回 HTTP 201，无正文，因此请保留生成的 ID，并通过 signature_participant_list 重新读取结果。
signature_participant_list	列出签名请求中的所有参与者及其创建时指定的角色——SIGNATORY、OBSERVER 或 VALIDATOR——以及联系方式和有效性信息。需要：signature_request_create → requestId、case_file_create → caseFileId。条目为 { id, requestId, groupId, role, firstName, lastName, email, phonePrefix, phoneNumber, createdAt, editable, emailBounced, valid, validationError, participantStats, documentStats }。此工具用于确认 ID：条目的 id 是 participantId；role 为 SIGNATORY 时，它同时也是 signatoryId；role 为 VALIDATOR 时，它同时也是 validatorId。支持 filter、order 和 page。
signature_participant_update	在签名请求激活前更正参与者信息。需要：signature_participant_create → participantId、signature_request_create → requestId、case_file_create → caseFileId。可发送 groupId、firstName、lastName、email、phonePrefix 和 phoneNumber 中的任意字段。无法更改角色；如需将签署人改为观察者，请先删除，再重新创建。可用于修复退信地址或拼写错误的邮箱——signature_participant_list 会报告 emailBounced 和 validationError。不返回正文；请通过 signature_participant_list 确认。
signature_participant_delete	从签名请求中移除一名参与者。需要：signature_participant_create → participantId、signature_request_create → requestId、case_file_create → caseFileId。可用于移除误添加的人员，或更改角色（先删除，再以新角色重新创建，因为角色不可更新）。不返回正文；请通过 signature_participant_list 确认。要一次移除所有无效参与者，请改用 signature_participant_invalid_purge。
signature_participant_invalid_purge	一次调用移除签名请求中平台标记为无效的所有参与者。需要：signature_request_create → requestId、case_file_create → caseFileId。signature_participant_list 会通过 valid: false 和 validationError 标识这些参与者，常见原因是邮箱无法投递或电话号码格式错误。不返回正文；请通过 signature_participant_list 确认。如果信息可以修正，优先使用 signature_participant_update，而不是移除该人员。
assign_validator_to_signatory	将一名或多名验证者分配给签名请求中的指定签署人。签署人必须先得到验证者批准才能签署。需要：signature_participant_create（验证者）→ validatorIds 数组中的 validatorId、signature_participant_create（签署人）→ signatoryId、signature_request_create → requestId、case_file_create → caseFileId。
signature_validator_list	列出当前关联到签名请求中某一名签署人的验证者。需要：signature_participant_create（签署人）→ signatoryId、signature_request_create → requestId、case_file_create → caseFileId。条目包含 { id, email, firstName, lastName }，其中每个 id 都是 validatorId。注意两步操作模式：以 VALIDATOR 角色创建参与者并不会自动将其关联到任何人；因此，验证者可以存在于请求中，但在 assign_validator_to_signatory 完成关联前不会显示在此列表中——空列表表示尚未关联任何验证者，而非不存在验证者。
signature_validator_unassign	取消一个验证者与一名签署人的关联，撤销 assign_validator_to_signatory 的操作。需要：signature_validator_list → validatorId、signature_participant_create（签署人）→ signatoryId、signature_request_create → requestId、case_file_create → caseFileId。此操作仅移除关联：验证者仍是请求的参与者；若要彻底移除该人员，请使用 signature_participant_delete。不返回正文；请通过 signature_validator_list 确认。
activate_signature_request	激活签名请求，使其从 DRAFT 转为 ACTIVE，并向所有签署人发送签名邀请。上传文件后不要立即调用此工具。激活前必须满足以下条件：请求处于 DRAFT；至少有一名 SIGNATORY；每份文档均已上传到其预签名 URL；所有已上传文档均已留出足够时间供后端处理（如果 signature_request_get 提供 processed/READY_TO_SIGN 状态，则以此为准；否则在 PUT 成功后等待）；PDF 文档已为每位必需签署人设置签名坐标。INTERPOSITION 可发送简单签名链接；若平台可用且已配置，也可通过 WhatsApp 发送。ADVANCED 使用 phonePrefix/phoneNumber 发送 OTP，目前不支持 WhatsApp 投递。此操作不可逆：激活后无法再添加文档或参与者。异步：激活后，轮询 signature_request_get，直到状态为 ACTIVE；然后使用带 documentId 的 signature_document_signatory_list 监控每位签署人，或使用 signature_document_list 查看请求中的文档及签署人汇总状态 signatoryStatusStats；仅当文档状态为 SIGNED 后，才调用 signature_certificate_get。
signature_coordinate_set	设置 PDF 文档页面上签名栏的可视位置。对于 INTERPOSITION 和 ADVANCED 签名，PDF 文档必须在激活前设置坐标。需要：signature_participant_create → signatoryId、signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId。坐标以数组形式提供：{page（从 1 开始）、x（距左侧的点数）、y（距底部的点数）}。文档上传后、调用 activate_signature_request 前设置坐标。
signature_certificate_get	获取已签署文档的证书 PDF。需要：activate_signature_request（文档已完全签署）、signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId。返回 documentUrl（已签署 PDF 证书）。异步：轮询直到 documentUrl 可用。
large_evidence_upload_initiate	针对 EAD Enterprise Suite API，启动向证据组上传大文件的流程。必需字段：id、caseFileId、evidenceGroupId、title、fileName、hash（SHA-256 十六进制）、fileSize（字节数）、custodyType。返回分段上传 ID 和各分段的预签名 URL。用于大于 5 MB 的文件。所有分段上传完毕后，调用 large_evidence_upload_complete。
large_evidence_upload_complete	完成大文件上传并封存证据组。需要：large_evidence_upload_initiate → 已完成所有分段上传、case_file_create → caseFileId、evidence_group_create → evidenceGroupId。异步：触发 TSP 时间戳服务。轮询 evidence_group_list，直到 status === CLOSED。
large_evidence_upload_get	报告平台实际已收到的大文件上传内容。需要：caseFileId、evidenceGroupId 和证据 id。返回 fileName、totalSizeMB、chunkSizeMB 和 biggestUploadedOffset；调用 large_evidence_upload_complete 前，将 biggestUploadedOffset 与 totalSizeMB 比较，以确定所有分段是否均已到达。可用于恢复中断的上传或诊断停滞的上传。
evidence_upload	一步将本地文件作为证据上传：计算 SHA-256、登记证据记录（custodyType INTERNAL = EAD 存储文件），并将字节上传到 S3——无需手动计算哈希或执行 PUT。此工具内部遵循 EAD 所需的顺序：创建 INTERNAL 证据 → 接收 uploadFileUrl（预签名 S3 URL）→ PUT 文件字节 → 返回 uploaded:true。需要：case_file_create → caseFileId、evidence_group_create → evidenceGroupId。必须且只能提供 filePath（仅限 stdio／本地模式下的绝对本地路径）或 contentBase64（Base64 编码的文件内容，约 10 MB 上限）之一。本地计算机上的文件请使用 evidence_upload；若已知 SHA-256 哈希、需要手动检查／使用 uploadFileUrl，或有公开的 fileUrl，请使用 evidence_create。此工具成功后，通过 evidence_get/evidence_list 验证，只有完成后才能调用 evidence_seal。如果此工具在返回证据 id 前失败，请先检查 evidence_list 再重试；若改为手动重试，请使用新的 UUID 调用 evidence_create。本地文件必须小于 1 GiB。
notification_send	一次调用向一名或多名收件人发送已认证通知：创建通知请求、添加所有收件人并发送。由工具自行生成所有 UUID——不要传入任何 id。需要 case_file_create → caseFileId。content 必须为 HTML：API 接受纯文本并会报告 SENT，但纯文本不会显示在收件人落地页上。仅支持以下标签： 、、、 、 ——不支持其他标签或 CSS。subject 仅使用纯 ASCII 字符，最多 100 个字符。始终通过电子邮件投递；还可为每位收件人设置 sendWaUrl（WhatsApp）、sendSmsUrl（根据接收设备使用 RCS 或 SMS）和 otpRequired（一次性验证码），以上各项均需要带 + 的 phonePrefix 和 phoneNumber。收件人最大数量由订阅设置决定，并非固定限制，因此本工具不进行限制——API 会拒绝超出限制的批次。此工具不会附加文件；如需附加，请使用 notification_send_with_attachments，因为附件必须在添加收件人前登记。部分成功会在结果中报告，而不会抛出异常：如果已创建请求，但添加收件人或发送失败，结果仍会包含 notificationRequestId，以及 recipientsAdded、recipientsFailed 和 sent:false，因此可继续使用 notification_receiver_add 和 notification_request_send，而不必放弃草稿。INVALID 收件人会阻止发送，因此此工具会在发送前检查并报告 invalidRecipients，而不会尝试无法成功的发送。如果初始创建失败，工具会直接报错：常见原因包括不存在的 caseFileId、subject 超过 100 个字符，以及已用尽合同规定的通知套餐额度；重试无法解决这些问题。如果错误是超时而非拒绝，请先检查 notification_request_list 再重试——请求可能已经创建。轮询 notification_request_status 查看投递进度，然后针对每位收件人调用 notification_certificate_get。
notification_send_with_attachments	一次调用向一名或多名收件人发送带有一个或多个附件的已认证通知。没有附件时，请改用 notification_send。此工具单独存在，是因为 API 强制要求附件遵循特定顺序，且不会容忍违反顺序：必须在添加任何收件人之前登记并完整上传文档，且每个文档都必须达到 READY_TO_SEND 后才能发送通知——否则发送会失败并返回 409/404 NOTIFICATION_NOT_FOUND。此工具会为你完成整个流程：创建 → 登记并上传每个文档 → 等待 READY_TO_SEND → 添加收件人 → 发送。每个附件可使用本地文件路径、Base64 内容、HTTPS URL 或 n8n 二进制引用；哈希和上传由工具内部处理。由工具自行生成所有 UUID——不要传入任何 id。需要 case_file_create → caseFileId。content 必须为 HTML：API 接受纯文本并会报告 SENT，但纯文本不会显示在收件人落地页上。仅支持以下标签： 、、、 、 。subject 仅使用纯 ASCII 字符，最多 100 个字符。始终通过电子邮件投递；还可为每位收件人设置 sendWaUrl（WhatsApp）、sendSmsUrl（根据接收设备使用 RCS 或 SMS）和 otpRequired（一次性验证码），以上各项均需要带 + 的 phonePrefix 和 phoneNumber。附件和收件人的最大数量均由订阅设置决定，并非固定限制，因此本工具不对任一数量进行限制。如果附件上传失败，流程会有意在添加收件人前停止：API 一旦存在收件人就不再接受后续文档，因此继续操作会生成一个永远无法包含缺失文件的通知。结果会返回草稿的 notificationRequestId，方便你重试或删除。INVALID 收件人会阻止发送，因此工具会在发送前检查并报告 invalidRecipients，而不会尝试注定失败的发送。如果初始创建失败，工具会直接报错：常见原因包括不存在的 caseFileId、subject 超过 100 个字符，以及已用尽合同规定的通知套餐额度；重试无法解决这些问题。如果错误是超时而非拒绝，请先检查 notification_request_list 再重试——请求可能已经创建。证书可以打包附件——参见 notification_certificate_package_url。

共存

此 MCP 服务是 EAD Enterprise Suite API 当前且仍在积极维护的接口。

如果你此前使用过早期版本（v1.0 之前）的 EAD Enterprise Suite MCP 服务，请注意，此服务已取代早期版本。在迁移期间，两个服务可以并行运行——它们连接到同一个上游 API，且不共享本地状态。为避免在多服务 MCP 配置中出现重复的工具名称，请在迁移完成后一次只运行一个服务。

许可证

MIT — 参见 LICENSE。