Model Context Protocol（MCP）是一套开放协定，让 AI 应用以一致方式发现并使用外部资料、提示与工具。它降低每个 Agent 都要为每个系统重写整合的成本，但只规范「如何交换能力与 context」；资料是否正确、工具能做什么、谁能核准，仍由 host、server 与组织治理决定。
把 MCP 想成 Agent 的连接规格，不是智慧本身
USB 的价值不是让硬碟变聪明，而是让不同电脑用共同规格辨识装置。MCP 的角色相近：一端是 AI 应用，另一端是提供资料或能力的服务；双方透过标准讯息描述「我有哪些东西」与「你要怎么呼叫」。
依 MCP 最新正式规格（2025-11-25），协定采 JSON-RPC 2.0，主要参与者有三个：
- Host：协调使用者、模型与多个连线的 AI 应用。
- Client：host 内与单一 MCP server 维持连线的元件。
- Server：提供 context 或可执行能力的程式。
Server 可暴露三种核心 primitive：
| Primitive | 它提供什么 | 资料分析例子 |
|---|---|---|
| Resources | 可读取的 context 或资料 | schema 文件、指标定义 |
| Prompts | 可重用的讯息模板或工作流入口 | 月报分析提示模板 |
| Tools | 可由模型请求执行的函式 | 查询资料、建立 Plan、汇出结果 |
Host 也可能提供 roots、sampling 或 elicitation 等能力。实际支援哪些功能，取决于 client 与 server 在连线初始化时协商的 capability；「支援 MCP」不代表支援所有 primitive。
一次工具呼叫实际发生什么事？
以「查询订单资料」为例，可以拆成五步：
- Host 与 server 建立连线并交换协定版本、capabilities。
- Client 询问 server 有哪些 tools 或 resources。
- Server 回传工具名称、描述与输入 schema。
- 模型根据使用者目标提出 tool call，host 依权限与同意流程决定是否送出。
- Server 执行后回传结果，模型再解读或进行下一步。
MCP 架构文件 特别指出，MCP 专注于 context exchange，不规定 AI 应用如何使用 LLM 或管理取得的 context。也就是说，同一个 MCP server 接到两种 Agent harness，可能产生完全不同的审批、记录与错误处理体验。
这也是「MCP 是 Agent 的 USB」类比的限制：MCP 工具可能查资料、写档甚至执行高影响操作，远比一般周边装置敏感。工具描述也不能自动视为可信。
MCP 解决了三个整合问题，没有解决四个治理问题
MCP 的直接价值包括：
- 可发现性：Agent 能用标准方法列出能力，而非把每个 API 都硬写进 prompt。
- 可组合性：同一个 host 能连多个 server，server 也能被不同 client 使用。
- 介面一致性：lifecycle、工具 schema、进度、取消与错误有共同语言。
但接通之后，仍要分别回答：
- 权限：这条连线能读、能写，还是能做管理操作？
- 正确性：工具回传的资料是否新鲜，栏位与指标定义是否一致？
- 治理：高风险动作何时需要人核准，活动是否可查？
- 信任：server、tool description、输入内容与 credential 由谁管理？
正式规格的安全章节也明确要求使用者同意与控制、资料保护及 tool safety，并说明协定本身无法在 protocol layer 强制完成所有安全原则。换句话说，MCP 是治理的载体之一，不是「接上就安全」的认证。
为什么 2026 年更值得关注 MCP
MCP 2026 Roadmap 将 transport scalability、agent communication、governance maturation 与 enterprise readiness 列为优先方向。Roadmap 也坦白指出，企业部署正在遇到 audit trail、SSO 整合授权、gateway 行为与设定可携性等问题；其中多数仍是发展方向，不该写成已经由 core spec 完整解决的功能。
这个讯号的重要性在于：MCP 正从「本机工具整合」走向更广的 production use，而规模越大，host 边界、credential、approval 与 audit 就越不能靠预设值处理。
Lantide Data 的两种 MCP 方向，不要混在一起
Lantide Data 同时支援两个相反方向的整合：
方向一：Lantide 作为 MCP client
在 MCP Sources 中，Lantide 连到外部 MCP 来源，透过 stdio 或 HTTP 设定取得资料，再物化为侧边栏可查询的表。这适合传统 PostgreSQL／MySQL／SQLite 连线以外的资料或 API；如果只有标准资料库与本机 CSV，未必需要 MCP Sources。操作与状态见 MCP Sources 入门。
方向二：Lantide 作为本机 MCP Server
Lantide 也能让 Codex、Claude、Cursor 等支援 Streamable HTTP MCP 的外部 Agent 连入其分析工作面。外部 Agent 可以依连线的 Observe／Execute／Admin 能力上限，读取或建立 Plan、SQL evidence 与 Report；Lantide GUI 则保留审阅、Activity 与 audit。Server 仅绑定本机 127.0.0.1，bearer credential 只应交给信任的本机 client，不能贴到公开或远端环境。详见 外部 Agent 与 MCP Server 指南。
MCP Server 的连接、recovery 与 client compatibility 行为可能随版本调整，导入前应以当版 User Guide 和实测结果为准。
两者都不会让 Agent 自动取得无限权限。MCP Sources 的来源权限由来源本身与设定决定；外部 Agent 的 access mode 由 connection 建立时设定，而 Plan 的 Approve & Execute 只核准该 Plan，不会提升 connection mode。
选 MCP 整合前的四问
评估任何 MCP server，不要只看「能不能连」，先问：
- 这个 server 暴露哪些 resources 与 tools？每个 tool 的副作用是什么？
- credential 存在哪、多久过期、如何 rotate 或 revoke？
- host 是否在呼叫前显示清楚的参数与同意介面？
- 执行后留下哪些 artifact、activity 与 audit，可否重现关键结果？
如果四题答不完整，先用测试资料与唯读权限验证。协定能缩短整合时间；可信任的 Agent 工作流，仍要由具体的 scope、approval 与 evidence 补齐。