MCP Apps：产品架构、分发与信任边界

先分清概念

MCP 是协议边界，“MCP App”是产品和生态称呼，可能对应多种部署：

人类或 Agent
      |
      v
Host / Client  -- 审批、身份、界面、模型策略
      |
      v
MCP Server     -- 协议端点与能力描述
      |
      v
应用服务、数据与外部副作用

协议不会自动提供 Marketplace、计费系统、可信发布者、用户界面或授权。这些仍然是产品与部署责任。

四种产品形态

这些形态可以使用同一个 SDK，但不能共享未经验证的假设。本地 stdio 适配器不会因为增加 Manifest 就变成多 Tenant SaaS 产品。

能力设计

Tools、Resources 和 Prompts 有不同契约：

优先设计窄化的业务操作，而不是通用能力：

{
  "name": "invoice.get_summary",
  "description": "Return an approved summary for one invoice in the caller's tenant. Does not modify billing data.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "invoice_id": {"type": "string", "minLength": 1}
    },
    "required": ["invoice_id"],
    "additionalProperties": false
  }
}

Schema 只约束形状。Server 仍需从可信上下文派生 Principal，检查 Tenant 和对象访问，限制结果大小并脱敏。

产品架构

生产级 MCP 产品通常不只是一个 SDK：

1. 能力边界：窄化、版本化的 Tools、Resources 和 Prompts。
2. 身份边界：已认证 Principal、Tenant、Scope 和 Workload Identity。
3. 策略边界：对象所有权、Purpose、副作用、审批、配额和外发。
4. 可靠性边界：超时、取消、重试、幂等、背压和恢复。
5. 数据边界：最小化、留存、删除传播、审计和导出控制。
6. 商业边界：套餐、计量、发票、退款和支持语义。

这些边界应明确分开。描述或 Tool Annotation 可以帮助 Host 展示风险，但不能授权调用。

从能力到产品

1. 找到重复工作

描述用户结果，而不是“AI 集成”的新鲜感。明确输入、所需证据、预期结果、人工兜底和不可接受的失败。

2. 选择最小接口

从一个有界的读取或可逆操作开始。避免通用 SQL、任意 HTTP、Shell、无限文件访问和“什么都能做”的 Prompt。

3. 确定所有权

为每个对象定义 Tenant、Subject、Account、Price、Role 和 Approval 的事实来源。应用已经知道的值，不应接受模型参数覆盖。

4. 衡量真实结果

记录业务任务成功率、证据正确性、授权拒绝、重复副作用、尾延迟、Token 和下游成本、取消及支持事件。Tool 调用数量不等于产品价值。

5. 运营稳定后再分发

Catalog 会增加安装和供应链风险。先证明升级、回滚、凭证轮换、事件响应、限流和删除能力。

分发与发现

Catalog 或 Registry 是额外的信任系统，至少需要：

• 发布者身份和所有权验证；
• 适用时的签名或可复现构建；
• 版本与依赖固定；
• 声明的能力与副作用；
• 安装前的权限审核；
• 凭证与网络外发隔离；
• 漏洞和恶意 Result 的响应；
• 撤销、回滚、卸载和删除传播；
• 安装及审批版本的审计记录。

Discovery Metadata 是不可信输入。目录条目不能证明 Server 安全、Annotation 真实，或其全部 Tool 都适合所有 Tenant。

Host 与 Client 体验

“零代码”不等于“零责任”。好的 Host 应在风险发生时展示：

• 使用哪个身份和 Tenant；
• 将读取或修改哪些对象；
• 操作是否可逆；
• 哪些数据会离开边界；
• 预计延迟、配额和成本；
• 需要什么审批；
• 如何取消或恢复。

自然语言选择可以提出能力，但应用和 Server 决定是否执行。

计费与计量

价格是商业合同，不是模型输出。至少明确：

Account、Price、Currency、Discount 和 Ownership 必须由 Server 控制。模型可以选择与套餐有关的意图，但不能设置权威金额或客户身份。

可靠性与支持

MCP 产品是运营服务，至少测试：

• Initialization 和 Capability 协商；
• Schema 拒绝和未知字段；
• 认证、Scope、Tenant 和对象不匹配；
• Result 大小、Pagination 和敏感字段脱敏；
• 超时、取消、重试分类和幂等；
• 重连、重复投递和滚动升级；
• 下游故障、部分失败和补偿；
• 配额耗尽和公平调度；
• Fixture 回放和滥用场景；
• Primary、Cache、Index、Backup 与 Export 的删除传播。

发布明确兼容矩阵：

Host x Client x SDK x MCP revision x Transport x Authorization

“支持 MCP”不足以构成支持承诺。

最小产品 Manifest

将商业与运营 Metadata 和协议 Capability 分开：

{
  "product_id": "invoice-summary",
  "server_version": "1.4.0",
  "mcp_revision": "pinned-revision",
  "transports": ["stdio", "streamable-http"],
  "capabilities": ["invoice.get_summary"],
  "side_effects": "read_only",
  "data_classes": ["tenant_invoice_metadata"],
  "required_scopes": ["invoices.read"],
  "result_limits": {"max_bytes": 262144},
  "support": {"rollback": true, "contact": "owned-by-provider"},
  "billing": {"unit": "authorized_successful_task", "retry_policy": "idempotent"}
}

Manifest 是审核材料。Runtime 授权不能因为某字段出现在 Manifest 中就信任它。

什么时候不该做 MCP App

以下情况不要创建目录型产品：

• 确定性 API 或定时 Workflow 更清晰；
• 能力没有稳定 Owner 或事实来源；
• 数据无法合法或可靠删除；
• 副作用无法幂等或审批；
• 价值无法与模型猜测区分；
• 没有投入支持和回滚。

MCP 接口应改善真实工作流，而不是给已有 Endpoint 添加新标签。

决策清单

• [ ] 定义用户结果和失败兜底。
• [ ] 首个 Tool 保持窄化、有界、只读或可逆。
• [ ] 从可信应用状态派生身份、Tenant、对象、价格和所有权。
• [ ] 分离协议 Capability 与 Catalog、UI、计费和支持 Metadata。
• [ ] 将描述、Annotation、Prompt、Resource 和 Result 视为不可信。
• [ ] 测试取消、重试、重复投递、配额和下游故障。
• [ ] 在凭证轮换、回滚、撤销、卸载和删除可用后再发布。
• [ ] 记录准确的 Host、Client、SDK、版本、Transport 和 Authorization 矩阵。
• [ ] 衡量成功结果和用户信任，而不只是 Tool 调用量。

总结

MCP 可以让 Host 更容易发现和调用能力，但不会把协议端点变成可信应用商店或商业模式。先构建窄化能力，建立身份和对象边界，让失败与删除可观测，再选择分发和计费。这样才能用可预测的行为建立信任，而不是用宣传替代产品质量。

一手来源

• Model Context Protocol Specification
• Model Context Protocol Tools
• Model Context Protocol Resources
• Model Context Protocol Authorization