Servicialo MCP Server

@servicialo/mcp-server

面向 Servicialo 标准的协议级 MCP 接口——这是 AI Agent 时代人类服务的目标层。 HTTP 让文档可寻址。Servicialo 让服务可寻址。MCP 和 A2A 是传输方式。Servicialo 是 Agent 抵达的目的地。

此软件包是面向任何兼容 Servicialo 的后端的协议级 MCP 接口——而非特定平台的连接器。Coordinalo 是参考实现（也是默认实现），但你可以接入自己的后端。

协议： v0.10 (draft) · 规范： servicialo.com/spec · 此软件包的版本独立于协议（到 1.0 前为 0.9.x）。

迈向 1.0

Servicialo 协议进入稳定化阶段。首批正式 RFC 已开放征求意见，至少持续 4 周，然后进入最终意见征询期。在 1.0 之前，版本仍为 0.9.x 补丁版，任何协议破坏性变更都需要先合并相应 RFC 并提前沟通。

• RFC 批次（PR #13）： servicialo/mcp-server#13
• 1.0 流程 / 讨论： servicialo/mcp-server#14

迈向 1.0 的待办里程碑

里程碑	状态
RFC-001 — RFC 流程与弃用政策	草案 / 开放征求意见
RFC-002 — 预付款与客户端信用余额	草案 / 开放征求意见
RFC-003 — 退款与贷项通知单（仅向前记账）	草案 / 开放征求意见
声明 Core 稳定（8 个维度 · 6+3 生命周期 · 6 个流程 · 7 项原则），并保证向后兼容	待处理
≥ 3 个独立实现投入生产	进行中

架构

@servicialo/mcp-server  →  interfaz MCP a nivel de protocolo
        ↓ se conecta a cualquier backend compatible con Servicialo
Coordinalo              →  implementación de referencia (default)
Tu implementación       →  trae tu propio backend

问题所在

AI Agent 可以浏览网页、编写代码和进行对话。但如果让它预约一次运动治疗、确认治疗确已进行，并处理付款——它就会陷入混乱。

如今，每个平台都是一个孤岛。以下方面没有统一标准：

• 发现——哪位服务提供者、在哪个组织提供我需要的服务？
• 身份——此 Agent 代表谁行事？获准执行哪些操作？
• 生命周期——这项服务处于什么状态？谁确认了？谁参加了？
• 交付证明——这次服务实际发生了吗？持续了多久？在哪里进行？
• 结算——金额是多少？付给谁？遵循哪些合同条款？

没有共享协议，每项集成都只能定制开发。每个 Agent 与平台之间的连接都是定制 API。这种方式无法扩展。

什么是 Servicialo

Servicialo 是一种开放协议，而非平台。它定义专业服务如何经历其生命周期——从发现到付款——任何 AI Agent 或平台都可以实现。

两者的关系就像 HTTP 与 Apache，或 SMTP 与 Gmail：Servicialo 定义规则，实现则让规则发挥作用。

该协议通过 8 个维度、6+3 生命周期（6 个核心状态 + 3 个可选财务状态）、6 个异常流程和 7 项基本原则来建模每项服务——适用于各个垂直领域（医疗、法律、教育、上门服务）：

Solicitado → Agendado → Confirmado → En Curso → Completado → Documentado → Facturado → Cobrado → Verificado

任何垂直领域中的任何服务，都遵循这一顺序。特定垂直领域的逻辑位于各个状态内部，而状态机保持不变。

此 MCP 服务的功能

此软件包将 Servicialo 协议作为 40 个 MCP 工具提供，按服务生命周期的 7 个阶段（0–6，包括发现解析器——类似于 DNS，但基于 HTTP）进行组织，此外还包括资源管理、解析器管理、网络智能（market.*）和冷启动发现（registry.list_*，用于在事先不了解分类体系的情况下了解它）。Agent 不会按数据库实体调用端点，而是遵循服务协调的自然流程。

阶段 0 — DNS 解析（3 个工具，无需身份验证）

工具	描述
resolve.lookup	将 orgSlug 解析为其 MCP/REST 端点和信任等级（相当于 DNS 查询）
resolve.search	在全局解析器中按国家和垂直领域搜索已注册的组织
trust.get_score	获取组织的信任评分（0-100 分、等级、最近活动时间）

阶段 1 — 发现（6 个工具，无需身份验证）

工具	描述
registry.search	按垂直领域、位置、国家搜索组织
registry.get_organization	获取公开详情：服务、服务提供者、预订配置
registry.manifest	获取服务清单：能力、协议版本、组织元数据
scheduling.check_availability	查询可用性（3 个变量：服务提供者 ∧ 客户端 ∧ 资源）
services.list	列出组织的公开服务目录
a2a.get_agent_card	获取组织的 A2A Agent Card，用于 Agent 间发现

阶段 2 — 了解（2 个工具）

工具	描述	权限范围
service.get	获取服务的 8 个维度	service:read
contract.get	获取合同条款：所需证据、取消政策、争议期限	service:read order:read

阶段 3 — 承诺（3 个工具）

工具	描述	权限范围
clients.get_or_create	按电子邮件/电话解析客户身份——通过一次调用进行查找或创建	patient:write
scheduling.book	预订服务时段 → 状态为 solicitado。实体资源可选传入 resource_id	schedule:write
scheduling.confirm	确认已预订的服务时段 → 状态为 confirmado	schedule:write

阶段 4 — 生命周期（4 个工具）

工具	描述	权限范围
lifecycle.get_state	获取当前状态、可用状态转换和历史记录	service:read
lifecycle.transition	使用证据执行状态转换	service:write
scheduling.reschedule	改期至新的日期/时间（可能适用合同政策）	schedule:write
scheduling.cancel	取消服务时段（适用合同取消政策）	schedule:write

阶段 5 — 验证交付（3 个工具）

工具	描述	权限范围
delivery.checkin	使用 GPS + 时间戳签到 → 状态为 en_curso	evidence:write
delivery.checkout	使用 GPS + 时间戳签退 → 状态为 entregado（自动计算时长）	evidence:write
delivery.record_evidence	记录证据：gps、firma、foto、documento、duración、notas	evidence:write

阶段 6 — 结算（4 个工具）

工具	描述	权限范围
documentation.create	生成服务记录（临床记录、检查报告等）→ 状态为 documentado	document:write
payments.create_sale	为已记录的服务创建费用 → 状态为 cobrado	payment:write
payments.record_payment	登记针对一笔销售收到的付款	payment:write
payments.get_status	获取一笔销售的付款状态或客户账户余额	payment:read

资源管理（6 个工具）

工具	描述	Scopes
resource.list	列出组织的实体资源	resource:read
resource.get	获取资源详情及其可用时段	resource:read
resource.create	创建新的实体资源（房间、诊室、设备）	resource:write
resource.update	更新资源（语义化补丁）	resource:write
resource.delete	停用资源（软删除：is_active = false）	resource:write
resource.get_availability	查询资源在指定日期范围内的可用情况	resource:read

Resolver 管理（3 个工具）

工具	描述	Scopes
resolve.register	在全局 resolver 中注册组织及 MCP/REST 端点	resolve:write
resolve.update_endpoint	更新已注册的端点（支持在不同后端之间迁移）	resolve:write
telemetry.heartbeat	向 resolver 发送 heartbeat，表明节点处于活动状态	telemetry:write

网络智能（2 个工具，无需身份验证）

基于各节点贡献的运营遥测数据生成匿名市场基准。采用贡献后访问政策（k-匿名性 ≥ 5）：

工具	描述
market.list_segments	列出有可用数据的细分市场 (event_type × vertical × region)（筛选出至少有 5 个不同贡献者的 k-匿名数据）
market.get_benchmark	获取细分市场的分桶数据分布（例如，health/CL 中 payment_settled 的各 price_band 占比）。Tier 0/1 可查看延迟 90 天的数据；tier 2（30 天内 ≥ 50 个事件）可查看实时数据

分类法发现（3 个工具，无需身份验证）

冷启动：Agent 无需事先了解协议分类法。缺少上下文时从这里开始：

工具	描述
registry.list_verticals	网络中涵盖的行业（已声明 + 近 30 天遥测中观测到的）
registry.list_regions	网络中有活动的 ISO 3166-1 alpha-2 国家/地区
registry.list_event_types	运营遥测的 4 种事件类型目录及其 payload_fields

文档（1 个工具，无需身份验证）

工具	描述
docs.quickstart	以结构化 JSON 获取 quickstart 的 5 个步骤 — 为缺少上下文的 Agent 提供入门指引

Quickstart — 加入网络的 5 个步骤

第 1 步：安装 MCP 服务

npx -y @servicialo/mcp-server

发现模式 — 15 个公开工具，无需凭据。立即试用：

{
  "tool": "registry.search",
  "arguments": { "vertical": "kinesiologia", "location": "santiago" }
}

第 2 步：创建组织

在 coordinalo.com/signup 注册组织。Coordinalo 是 Servicialo 协议的参考实现。

第 3 步：获取 MCP 凭据

在 Coordinalo 中：Settings → Servicialo → Generar credenciales MCP。你将获得两个值：

• SERVICIALO_ORG_ID — 组织的 slug（例如：clinica-dental-sur）
• SERVICIALO_API_KEY — 用于身份验证的 bearer token

第 4 步：配置 MCP 客户端

将以下内容添加到 Claude Desktop、Cursor 或任何 MCP 客户端的配置中：

{
  "mcpServers": {
    "servicialo": {
      "command": "npx",
      "args": ["-y", "@servicialo/mcp-server"],
      "env": {
        "SERVICIALO_API_KEY": "<tu_api_key>",
        "SERVICIALO_ORG_ID": "<tu_org_slug>"
      }
    }
  }
}

省略 env 块即可使用纯发现模式（15 个公开工具）。

第 5 步：将组织发布到 Servicialo 网络

在 Coordinalo 中：Settings → Servicialo → Publicar。你的组织将显示在 servicialo.com/network，并可供其他 Agent 发现。

**提示：**Agent 可调用 docs.quickstart 工具，以结构化 JSON 获取这 5 个步骤。

红色 / 网络

Servicialo 网络是实施该协议的组织全球注册表。每个已认证节点都会定期发送心跳，任何 Agent 都可以按国家/地区、垂直领域和信任评分发现组织。

• 浏览网络： servicialo.com/network
• 按垂直领域搜索： registry.search({ vertical: "kinesiologia", country: "cl" })
• 解析组织： resolve.lookup({ org_slug: "clinica-dental-sur" })

凭证

必需项

变量	必需	默认值	描述
SERVICIALO_API_KEY	否	—	Bearer token。启用认证模式（额外提供 25 个工具，共 40 个）
SERVICIALO_ORG_ID	否	—	组织 slug。启用认证模式
SERVICIALO_BASE_URL	否	http://localhost:3000	与 Servicialo 兼容的平台 API 端点
SERVICIALO_ADAPTER	否	coordinalo	后端适配器：coordinalo 或 http
SERVICIALO_TELEMETRY	否	true	设置为 false 可禁用节点匿名遥测（心跳）

SERVICIALO_API_KEY 和 SERVICIALO_ORG_ID 必须同时配置。如果只设置其中一个，服务端会回退到发现模式并发出警告。

运行遥测 + 基准测试（可选）

这些变量可让你的节点向网络基准测试贡献匿名事件，并访问实时数据（tier 2）。参见 docs/telemetry-operational.md：

变量	必需	默认值	描述
SERVICIALO_VERTICAL	否	unspecified	你的垂直领域（例如 health、legal、home）。事件要归入正确的细分领域，就需要此项
SERVICIALO_REGION	否	CL	运营所在国家/地区的 ISO 3166-1 alpha-2 代码。事件会添加此标签
SERVICIALO_NODE_TOKEN	否	—	你的节点在 registry 中的 ownership_token。在 market.* 调用中作为 X-Servicialo-Node-Token 标头发送，以识别你的 tier（包括 tier 2 = 实时访问）
SERVICIALO_OPERATIONAL_TELEMETRY	否	true	设置为 false 可禁用自动发送运行事件（booking_created、service_completed、dispute_opened、payment_settled）
SERVICIALO_PROTOCOL_VERSION	否	0.9	已发送事件中声明的协议版本
SERVICIALO_TELEMETRY_BASE_URL	否	https://servicialo.com	运行遥测接收端点（仅在测试时更改）

与基准测试 tier 的关系： 在 30 天内发送 ≥ 50 个运行事件的节点会自动达到 tier 2，market.get_benchmark 会返回实时数据（而非默认 tier 0/1 的 90 天延迟）。完整政策见：GOVERNANCE.md#contribute-to-access-policy-v01。

可在 coordinalo.com → Settings → Servicialo → Generar credenciales MCP 获取凭证。

连接自己的实现

此 MCP 服务通过可插拔适配器层支持任何与 Servicialo 兼容的后端。包含两种适配器：

• coordinalo（默认）——连接到 Coordinalo/Digitalo 后端，其路由采用组织范围限定，路径为 /api/organizations/{orgId}。
• http——连接到任何在 /v1/* 下公开 HTTP_PROFILE.md 规范端点的实现。

连接你的实现只需 3 步

第 1 步。 在你的平台上实现 HTTP_PROFILE.md 中定义的 REST 端点。

第 2 步。 配置 MCP 服务使用 HTTP 适配器：

SERVICIALO_ADAPTER=http \
SERVICIALO_BASE_URL=https://tu-plataforma.com \
SERVICIALO_API_KEY=tu_key \
npx -y @servicialo/mcp-server

第 3 步。 添加到你的 MCP 客户端配置中：

{
  "mcpServers": {
    "servicialo": {
      "command": "npx",
      "args": ["-y", "@servicialo/mcp-server"],
      "env": {
        "SERVICIALO_ADAPTER": "http",
        "SERVICIALO_BASE_URL": "https://tu-plataforma.com",
        "SERVICIALO_API_KEY": "tu_api_key",
        "SERVICIALO_ORG_ID": "tu_org_id"
      }
    }
  }
}

HTTP 适配器会将内部路由转换为规范的 /v1/* 端点，并通过 X-Servicialo-Org 标头发送组织上下文。完整的 REST 契约请参阅 HTTP_PROFILE.md。

委托代理模型

该协议将 AI Agent 视为一等参与者，但绝不会默认信任它们。每项 Agent 操作都需要一个 ServiceMandate：由主要负责人向 Agent 明确授予能力的委托。

工作原理

1. 人类（专业人员、患者或组织）向 Agent 签发委托
2. 委托会指定 Agent 代表谁行事、可以做什么（权限范围），以及有效时长
3. 每次工具调用时，MCP 服务都会在执行前根据 8 项检查验证委托
4. 每项操作都会生成一条审计记录，无论成功还是失败

委托示例

{
  "mandate_id": "550e8400-e29b-41d4-a716-446655440000",
  "principal_id": "dra_barbara",
  "principal_type": "professional",
  "agent_id": "agent_booking_bot",
  "agent_name": "Asistente de Agendamiento",
  "acting_for": "professional",
  "context": "org:clinica-kinesia",
  "scopes": ["schedule:read", "schedule:write", "patient:write"],
  "constraints": {
    "max_actions_per_day": 50,
    "allowed_hours": {
      "start": "08:00",
      "end": "20:00",
      "timezone": "America/Santiago"
    },
    "require_confirmation_above": {
      "amount": 100000,
      "currency": "CLP"
    }
  },
  "issued_at": "2026-03-01T00:00:00Z",
  "expires_at": "2026-06-01T00:00:00Z",
  "status": "active"
}

在工具调用中使用委托

当 actor.type 为 "agent" 时，需包含 mandate_id：

{
  "tool": "scheduling.book",
  "arguments": {
    "service_id": "srv_123",
    "provider_id": "prov_111",
    "client_id": "cli_789",
    "starts_at": "2026-03-03T10:00:00",
    "actor": {
      "type": "agent",
      "id": "agent_booking_bot",
      "mandate_id": "550e8400-e29b-41d4-a716-446655440000"
    }
  }
}

8 项验证检查

每次 Agent 工具调用都会通过以下检查进行验证：

#	检查	可防止的问题
1	状态 — 委托必须为 active	使用已撤销或已过期的委托
2	时间有效性 — issued_at ≤ now < expires_at	基于时间的攻击
3	Agent 身份 — mandate.agent_id === 请求 Agent	Agent 冒充
4	权限范围覆盖 — 委托的权限范围涵盖工具的要求	权限提升
5	上下文 — 委托上下文与请求相符	跨组织数据访问
6	利益冲突 — Agent 不能同时代表双方行事	双重代理违规
7	限制 — 允许的时间段、每日限额、财务阈值	Agent 自主性过高
8	审计 — 每项操作均使用经过清理的输入进行记录	否认责任

非 Agent 参与者（client、provider、organization）无需进行委托验证。

服务提供者发现

Agent 可以使用结构化查询搜索注册目录，并根据患者需求匹配服务提供者。

搜索注册目录

{
  "tool": "registry.search",
  "arguments": {
    "vertical": "kinesiologia",
    "location": "santiago",
    "country": "cl"
  }
}

返回服务和服务提供者与搜索条件相符的组织。

查询可用性

{
  "tool": "scheduling.check_availability",
  "arguments": {
    "org_slug": "clinica-kinesia",
    "service_id": "srv_rehab_pelvica",
    "provider_id": "prov_111",
    "date_from": "2026-03-10",
    "date_to": "2026-03-14"
  }
}

三变量调度器会同时检查服务提供者、客户端和实体资源的可用性。

端到端示例

1. registry.search({ vertical: "kinesiologia", location: "santiago" })
   → encuentra org "clinica-kinesia"

2. services.list({ org_slug: "clinica-kinesia" })
   → lista servicios disponibles

3. scheduling.check_availability({ org_slug: "clinica-kinesia", date_from: "2026-03-10", date_to: "2026-03-14" })
   → retorna slots disponibles

4. contract.get({ service_id: "srv_123", org_id: "org_456" })
   → cancelación: 0% si >24h, 50% si 2-24h, 100% si <2h
   → evidencia requerida: check_in + check_out + registro_clinico

5. clients.get_or_create({ email: "[email protected]", name: "Maria", last_name: "Lopez" })
   → client_id: "cli_789"

6. scheduling.book({ service_id: "srv_123", provider_id: "prov_111", client_id: "cli_789", starts_at: "2026-03-12T10:00:00" })
   → session_id: "ses_001", estado: "solicitado"

7. scheduling.confirm({ session_id: "ses_001" })
   → estado: "confirmado"

8. delivery.checkin({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
   → estado: "en_curso"

9. delivery.checkout({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
   → estado: "entregado", duración: 42min

10. documentation.create({ session_id: "ses_001", content: "Sesión de rehabilitación de piso pélvico..." })
    → estado: "documentado"

11. payments.create_sale({ client_id: "cli_789", service_id: "srv_123", unit_price: 35000 })
    → sale_id: "sale_001", estado: "cobrado"

12. lifecycle.transition({ session_id: "ses_001", to_state: "verified" })
    → estado: "verificado" ✓

协议规范

完整的 Servicialo 协议规范见：

• 代码仓库： github.com/servicialo/protocol
• 网站： servicialo.com
• 当前稳定版本： 0.9
• JSON Schemas： service.schema.json、service-order.schema.json、service-mandate.schema.json、resolution.schema.json、servicialo-config.schema.json

该规范涵盖服务的 8 个维度、6+3 生命周期、6 种异常流程、7 项基本原则、双实体架构（原子服务 + 服务订单）、委托代理模型、DNS 解析和 A2A 互操作性。

参考实现

Digitalo 是 Servicialo 协议的首个生产环境实现，在智利的医疗领域运行。它实现了完整的生命周期——从服务提供方发现到付款结算——并为协议的演进提供验证场景。

此 MCP 服务通过 SERVICIALO_BASE_URL 连接到任何兼容 Servicialo 的后端。Digitalo 就是其中一个后端。该协议旨在让任何 CRM、HIS 或平台都能将其实现为一个自主节点。

为协议做贡献

Servicialo 对协议规范采用语义化版本控制：

• 补丁版本（0.7.x）——澄清、错字修正、非破坏性新增内容
• 次版本（0.x.0）——新增可选字段、工具定义或异常流程
• 主版本（x.0.0）——对 schema、状态机或核心语义进行破坏性变更

如何提议变更

1. 提交 issue，描述问题和建议的解决方案
2. 对于重大变更，在 spec/ 中撰写 RFC，并注明受影响的章节编号
3. 协议变更在合并前至少需要一个参考实现
4. schema 变更必须包含更新后的 JSON Schema 和 MCP 服务中的 Zod 类型

正在积极征求意见的领域

• 特定垂直领域的证据要求（不限于医疗领域）
• 生命周期状态名称的多语言支持
• 节点间联邦（两个 Servicialo 实现如何互操作）
• 面向 Python 和 TypeScript 的 Agent SDK 模式

遥测

启动时，MCP 服务会向 https://servicialo.com/api/telemetry/instance 发送唯一一条匿名 POST 请求，其中包含：

{
  "event": "node_initialized",
  "version": "0.9.8",
  "node_id": "a1b2c3d4-...",
  "ts": 1711300000000
}

字段	描述
event	始终为 "node_initialized"
version	软件包版本
node_id	存储在 ~/.servicialo/node_id 中的持久 UUID
ts	毫秒级时间戳

这就是发送的全部内容。 不会传输组织信息、API keys、患者数据或任何个人标识符。IP 会在服务器上经过哈希处理（SHA-256）后再存储。此 ping 采用即发即弃方式：如果失败，错误会被静默丢弃，绝不会阻止服务器运行。

首次在启用遥测的情况下运行时，服务器会在 stderr 中打印一条提示，说明会发送哪些内容以及如何禁用遥测。

禁用遥测

SERVICIALO_TELEMETRY=false npx -y @servicialo/mcp-server

或者在 MCP 配置中设置：

{
  "env": {
    "SERVICIALO_TELEMETRY": "false"
  }
}

更多详情：servicialo.com/network

加入网络

安装 @servicialo/mcp-server 后，你的节点会自动注册到网络遥测。这有助于生态系统衡量协议的实际采用情况——不会收集个人数据或客户数据。

遥测仅报告：软件包版本、持久节点 UUID，以及 IP 哈希（用于大致地理定位——我们不会存储 IP）。你可以随时使用 SERVICIALO_TELEMETRY=false 禁用遥测。

启动提示

服务器会在 stderr 中写入两条提示信息——绝不会写入 stdout，因为 stdout 用于传输 JSON-RPC，写入任何其他内容都会破坏它：

• RFC-005 的评论期窗口，只要仍处于开放状态。它设有内置过期时间：在最终评论期于 2026-09-13 结束后，便不再打印。10 月安装的节点不会看到过期公告。
• 如果你的节点是匿名的，如何识别它（见下文）。

每个进程中，这两条提示各打印一次；设置 SERVICIALO_QUIET=true 可将其静默：

{
  "env": {
    "SERVICIALO_QUIET": "true"
  }
}

此变量仅影响这两条提示。模式横幅和首次运行遥测提示仍保持原有行为。

识别你的节点

默认情况下，你的节点是匿名的：ping 仅包含事件、版本、node_id 和时间戳，不包含其他内容。如果你运行的是该协议的自有实现，这三个可选变量可以标识该实现，并申请成为已验证实现者：

SERVICIALO_IMPL_NAME="Mi Plataforma"        # Nombre de tu implementación
SERVICIALO_IMPL_URL="https://example.com"   # Tu sitio web o repositorio
SERVICIALO_IMPL_CONTACT="[email protected]" # Email de contacto — se hashea antes de salir

每个变量会从你的机器发送什么

变量	发送的内容	不会发送的内容
SERVICIALO_IMPL_NAME	以纯文本形式发送的名称，作为 impl_name。该名称是公开的：验证通过后会显示在 /implementors 上。	—
SERVICIALO_IMPL_URL	以纯文本形式发送的 URL，作为 impl_url。验证通过后同样会公开。	—
SERVICIALO_IMPL_CONTACT	仅发送 impl_contact_hash：对小写且不含空格的电子邮件地址计算得到的 SHA-256 哈希值，在你的机器上、发出任何网络请求之前计算。	电子邮件地址。它不会离开主机，不会被记录或存储，也不会在任何地方显示。

如果未配置变量，ping 中不会出现这些字段。未配置的节点与此版本发布前的行为完全相同。

验证流程

anonymous → pending → verified

1. anonymous — 未配置变量。这是默认状态，匿名节点完全符合规范。
2. pending — 新的 impl_name 首次出现时，该记录会进入待处理状态，团队会收到包含名称、URL 和国家/地区的通知。通知中不会包含联系哈希，也不可能包含：它毫无用处。
3. verified — 根据合规性检查清单进行人工审核后，你的实现会连同其等级和报告该实现的主机数量一起显示在 servicialo.com/implementors 上。

目前验证采用人工审核。自动化合规性测试套件已列入路线图，但目前尚不具备此功能。

联系哈希的用途——以及它的非用途。 这是单向摘要：没人能通过它联系你，配置它也不会让你订阅任何公告或邮件列表。它的作用恰恰相反：当你来信介绍自己的实现时，你电子邮件地址的哈希值可以确认你就是发送这些 ping 的运营者。

如何停止发送

从 MCP 配置中删除这些变量（或执行 unset SERVICIALO_IMPL_NAME SERVICIALO_IMPL_URL SERVICIALO_IMPL_CONTACT），然后重启服务。下一次 ping 就会恢复匿名状态，不包含任何身份字段。已经发送的 ping 仍会保留其已发送的内容；如需删除现有记录，请在代码库中创建 issue。

相关功能：每周快照

Registry 会在每周一 00:00 UTC 向已订阅的端点发送 benchmark.weekly_snapshot，并附带由 HMAC-SHA256 签名的载荷。这三个变量不会启用此功能。 该功能需要在 registry 中创建条目，并通过 Webhooks API 明确订阅；它提供的是基准测试数据，而非协议公告。

许可证

Apache-2.0——欢迎任何实现，无论是否用于商业用途。请参阅 LICENSE。