MCP（Model Context Protocol）可以把它理解成：让大模型/Agent 以“标准化方式”接入外部能力与上下文的一套协议。过去每家都用私有方式把“工具调用、知识读取、提示词模板”塞给模型——能跑但不可移植、不可组合、不可治理。MCP 试图解决的，就是“把模型外部世界的接口规范化”，让 Client（宿主/Agent 框架） 和 Server（能力提供方） 能解耦协作。

---

1. Server/Client

在 MCP 的世界里，存在两类角色：

• MCP Server：能力与数据的提供方
  它暴露一组标准化接口：列出工具、读取资源、获取提示词模板等。你可以把它看成“一个插件服务”，背后可能连接数据库、代码仓库、业务系统、文件系统、SaaS API。
• MCP Client：能力的消费方（通常是 Agent 框架/IDE/桌面应用）
  它负责：管理与多个 server 的连接、把工具/资源/提示词装配成模型可用的上下文，并编排“模型思考→调用→回填结果→继续”的循环。

一个典型交互链路是：

1. Client 连接 Server，拉取 tools/resources/prompts 的清单（带 schema/元信息）
2. Client 把这些能力以“模型可理解的方式”注入到对话与运行时
3. 模型选择调用某个 tool → Client 按 schema 组装参数 → 调用 Server
4. Server 执行真实动作（查数据/跑脚本/访问 API）并返回结构化结果
5. Client 将结果回填给模型，继续下一步推理或生成最终答案

工程上你会明显感受到：Client 更像编排层与安全边界；Server 更像能力适配层。这就是 MCP 能规模化的关键。

---

2. Tools

Tools 是 MCP 最像“函数调用”的部分：模型要做事（查订单、创建工单、跑搜索、生成图表），就通过 tool 来完成。

2.1 Tool 的核心价值：可发现 + 可验证 + 可治理

一个好 tool 不只是“能调用”，还必须做到：

• 可发现（discoverable）：Client 能列出工具，模型知道“我能做什么”
• 可验证（schema-valid）：参数结构清晰，client 能在调用前校验
• 可治理（governable）：可控权限、审计、速率限制、敏感参数处理

因此，一个 tool 通常会有：

• name：稳定的工具名（建议有命名空间，如 jira.createIssue）
• description：让模型选对工具的关键（别写废话，写清输入输出与限制）
• inputSchema：参数 JSON schema（越明确越少事故）
• output：最好是结构化对象，而不只是长字符串

2.2 设计 Tool 的入门最佳实践

• 把“一个业务动作”做成一个 tool：不要搞“万能 SQL 执行器”给模型（极难治理）
• 输入 schema 尽量“强约束”：枚举、最小/最大长度、必填字段
• 输出要“面向后续推理”：返回 id/status/url/summary 这类字段，方便模型继续下一步
• 错误也结构化：code/message/retriable，Client 才能决定重试或提示用户

---

3. Resources

如果说 tools 是“做事”，那 resources 就是“读材料”。比如：

• 读取某个 repo 的 README
• 读取一份内部文档
• 获取某个数据库视图的只读结果
• 列出某个目录下文件并读取内容

3.1 Resource 的意义：让上下文来源标准化

RAG 时代我们习惯了“向量库检索→把 chunk 塞进 prompt”。MCP 提供的资源机制，更像把上下文抽象为“URI 可定位对象”。好处是：

• Client 可以统一缓存、分页、权限校验
• Server 可以按业务语义组织资源（而不是让模型猜路径/猜接口）
• 资源可以被 tool 结果引用，形成可追溯链路

3.2 资源设计建议

• 资源要有稳定标识（URI）：便于引用与缓存
• 不要把资源读操作做成 tool（除非需要复杂计算）：纯读取用 resource 更清晰
• 分层组织：例如 docs/、repos/、tickets/，让模型“猜对路径”的概率更高

---

4. Prompts

很多团队做 Agent 时，prompt 是最容易失控的部分：散落在不同 repo、不同人手里，版本不一致、不可复用。MCP 的 prompts 提供了一种“提示词模板作为能力暴露”的方式。

你可以把 prompts 当成：

• 可参数化的模板（例如 summarize_doc, write_release_notes）
• 带输入字段定义（比如 doc_uri, tone, audience）
• 由 server 统一维护版本与变更（便于治理与复用）

新人最值得理解的一点是：
Prompts 不是为了让模型更聪明，而是为了让系统更稳定。当 Client 在不同场景复用同一 prompt 模板，输出风格与约束会更一致，也更容易 A/B 测试与回滚。

Prompts 的工程建议：

• 模板里明确“输出格式要求”（JSON/Markdown/分点）
• 把“不可做什么”写进去（安全、合规、数据边界）
• 尽量少写“链路细节”（如某工具名），让 Client 负责编排