covedataprotection-mcp

面向 Cove Data Protection（N-able 的备份/BDR 平台，前身为 N-able Backup / Backup Manager）的 MCP 服务器。将 Backup Manager JSON-RPC Management Service API 以 MCP 工具的形式暴露出来。

概述

• 无状态 HTTP 服务。任何凭据都不会被持久化——每个请求通过请求头自行提供凭据，且这些凭据仅在该单个请求的生命周期内使用。

• 支持并发请求；每个请求的凭据隔离通过 Python contextvars 实现，而非使用全局/共享的客户端实例。

• 入口点：POST /mcp（MCP 协议）和 GET /health（健康检查）。

• 默认端口：8080（可通过 MCP_HTTP_PORT 配置）。

Related MCP server: spanning-mcp

范围

26 个工具，从最初包含 247 个工具的完整 schema 构建（2026-08-04）中精简而来。MSPbots 自己的 Cove Data Protection 集成（已通过在生产平台上调用 /web/int/sys/integration/api/list 确认为在线）恰好配置了 6 个 API，映射到以下底层 JSON-RPC 方法：

上表中其他 5 个已确认为真实存在的方法按原样保留，此外还为它们涉及的三种资源类型各补充了同类核心 CRUD（Add/Get/Modify/Remove）——accounts（9 个工具）、partners（9 个工具）、users（7 个工具）——以及 GetServerInfo（1 个工具，连接自检，用于下文最初的在线验证）。原始 247 个工具构建中的其他所有类别（notifications、storage_nodes、contacts、storage、view_delivery、labels、jobs、custom_columns、branding、products、eula、locations、countries、audit、email、regions、features、permissions、templates——共 19 个类别，约 221 个工具）因 MSPbots 未使用且超出本服务器的用途范围而被完全移除。

身份验证

Cove 没有静态的长期有效 API 密钥。相反，每个会话都以一次 Login 调用（partner + username + password）开始，该调用返回一个短期有效的 visa 令牌（有效期约 15 分钟），后续每次调用都必须携带该令牌。

本服务器不会在请求之间缓存 visa——缓存 visa 意味着持久化会话状态，这与“不持久化凭据”的要求相冲突。相反，api_client.CoveClient.call() 在每次工具调用时都会执行一次全新的 Login，并在调用结束后丢弃生成的 visa，以每次调用多一次 HTTP 往返为代价换取完全的无状态性。

HEADER 授权参数说明

缺少这三个请求头中的任意一个都会返回 401：

{
  "error": "Missing credentials",
  "message": "This server requires the X-CoveDataProtection-Partner, X-CoveDataProtection-Username, and X-CoveDataProtection-Password headers",
  "required_headers": ["X-CoveDataProtection-Partner", "X-CoveDataProtection-Username", "X-CoveDataProtection-Password"],
  "optional_headers": []
}

环境变量

MCP 端点

• POST /mcp — MCP 协议（流式 HTTP 传输）

• GET /health — 健康检查，精确返回 {"status": "ok"}（纯本地存活探针；不会调用 Cove API）

工具列表

工具名称遵循 covedataprotection_<snake_case_method_name> 格式——例如，JSON-RPC 方法 EnumerateAccountStatistics 对应工具 covedataprotection_enumerate_account_statistics。参数名称与 JSON-RPC 方法自身的参数名称保持一致（camelCase → snake_case）；结构体/枚举类型的复杂参数以 dict/str 形式接受，并原样透传给供应商 API——这在实践中意味着什么，请参阅已知差距。

测试示例

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-CoveDataProtection-Partner: <your-partner-name>" \
  -H "X-CoveDataProtection-Username: <your-username>" \
  -H "X-CoveDataProtection-Password: <your-password>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "covedataprotection_get_server_info",
      "arguments": {}
    }
  }'

预期结果：凭据有效时返回 200 及服务器版本；凭据无效时，Login 调用本身会失败，每个工具都会返回一个结构化的 JSON 错误封装，例如：

{"error":{"code":"unauthorized","message":"<vendor error message>","retryable":false}}

code 是固定值 not_configured / unauthorized / not_found / invalid_argument / rate_limited / upstream_error 之一；retryable 告知调用方重试同一调用是否可能成功（仅对 rate_limited 和 upstream_error 为 true）。工具绝不会因业务/供应商错误而抛出异常——该封装会作为正常的工具结果字符串返回。

已在线验证（2026-07-29）：通过此运行中的服务器，使用真实的 partner/username/password 对 covedataprotection_get_server_info（零参数）进行了端到端调用，并返回了实际的 Cove 服务器版本——确认 Login → visa → 方法调用管道能够针对线上 API 正常工作，而不仅仅是结构上正确。

API 参考

• 入门指南：https://developer.n-able.com/n-able-cove/docs/getting-started

• 授权：https://developer.n-able.com/n-able-cove/docs/authorization

• 构造调用：https://developer.n-able.com/n-able-cove/docs/construct-a-json-rpc-api-call

• 完整的方法/结构体/枚举模式（JSON）：https://documentation.n-able.com/covedataprotection/Schema_23.3.json

已知差距

• 2026-08-04 从 247 个工具缩减为 26 个。 最初的构建覆盖了 Management Service 模式中的每个方法。根据后续的范围决策，缩减为 MSPbots 自己的生产集成配置实际调用的内容（已通过 app.mspbots.ai 上的 /web/int/sys/integration/api/list 在线验证，集成 ID 为 2026570354981494786），外加同类别的核心 CRUD——有关确切的 API→方法映射和已移除类别的完整列表，请参阅上面的 Scope 部分。被移除的 ~221 个工具（notifications、storage_nodes、contacts、storage、view_delivery、labels、jobs、custom_columns、branding、products、eula、locations、countries、audit、email、regions、features、permissions、templates）完全不在此构建中；如果未来需要其中任何一个，原始模式（Schema_23.3.json，见下方链接）仍记录有其确切的方法签名，并且可以按照保留工具相同的生成方式重新添加。

• 这仅涵盖 Management Service。 Cove 的 Getting Started 指南描述了第二个独立的 Reporting Service（{host}/repserv_json，在每个存储节点上运行），它提供备份/恢复会话统计信息。MSPbots 自己的配置会针对此 Reporting Service 调用一个 “Query Sessions” 报告——它不属于此 MCP 所依据的 Management Service 模式，并且未找到 Reporting Service 的公开模式。这是此 MCP 未覆盖的唯一一个 MSPbots 配置的端点；如果 Reporting Service 的方法列表/模式可用，则可以添加它。

• 复杂的结构体/枚举参数是未类型化的（dict/str），而非完整建模。 该模式定义了 106 个结构体和 78 个枚举；对于机械生成的服务器而言，将每一个都完整重现为类型化的 Python 参数超出了范围。调用方需要按照供应商模式来构造这些 dict 参数（有关确切的字段名，请参阅 Schema_23.3.json 的 Structs 部分）——每个此类参数的描述都会指明其映射到的结构体，并指向该模式文件。

• 无 visa 缓存——请参阅上面的 Authentication 部分。每次工具调用都会执行自己的 Login，这简单且完全无状态，但意味着每次工具调用需要向供应商发送 2 次 HTTP 请求，而不是 1 次。

• 全部 26 个工具都是直接从供应商自己的模式文件代码生成的，而非手写——参数名称/类型的准确度仅与该模式相当。covedataprotection_get_server_info 是唯一一个经过端到端在线验证的工具；其余工具在结构上是正确的（模式已验证，MCP 协议的 tools/list 已确认），但未针对真实数据逐一进行冒烟测试。

供应商 MCP SOP 合规性说明

• 工具数量（26）超过了 SOP 的“应 ≤20”指南。 已从 247 缩减为 26（见上文）；剩余的 26 个工具与 3 个资源域（accounts/partners/users）中的不同 JSON-RPC 方法一一对应，这些方法无法合并，否则会丢失必需参数的区别（例如，按 name+password 的 get_*_info 与按数字 ID 的 get_*_info_by_id 是不同的查找键，而不是带有可选参数的同一个工具）。

• 任何工具上都不存在 limit / page_size 标量参数。 26 个方法中没有一个暴露正式的数值型分页大小参数——唯一一个具有分页形态的字段（EnumerateChildPartners 上的 range）是一个不透明的供应商结构体，按原样透传；GetPartnerTree 上的 children_limit 同样被不加解释地直接传给供应商。此服务器没有任何东西可以依据 SOP 的默认 50 / 硬上限 200 指南进行限制；如果供应商模式的 range/limit 结构体本身有文档化的每页最大值，则应在此处强制执行该值，而不是采用 SOP 的通用回退上限。

• 没有凭据环境变量回退。 config.Settings 没有 partner/username/password 字段；每当每请求的 contextvar 未设置时，get_client_from_context 返回 None（→ not_configured 信封）。不存在回退到环境变量的代码路径。

• 工具注解：每个读取工具（get_*、enumerate_*）都被标记为 readOnlyHint=True, idempotentHint=True；add_* 工具为 readOnlyHint=False, idempotentHint=False（创建两次并非无操作）；modify_*/set_*/remove_* 工具为 readOnlyHint=False, destructiveHint=True, idempotentHint=True。