Something about MCP

Something about MCP Something about MCP Modified April 12, 2025 📌 GraphQL 让客户端能够精确地指定需要哪些数据，适合 多个微服务整合成一个 API 网关、数据模型复杂、前端需要灵活控制数据结构等场景。 Temporal 是一个用于构建 可扩展、可靠的后台工作流和分布式系统 的开源平台。假如你要处理一个「下单 → 扣款 → 发货 → 发邮件」的流程，通常你得自己写各种消息队列 + 状态管理 + 重试机制，非常复杂。但用 Temporal，就可以像写普通代码那样，写一个函数代表工作流，Temporal 来帮你管理执行、状态、重试、恢复等。 React 是一个由 Facebook 开发的 构建用户界面（UI） 的 JavaScript 库。UI 被拆分成一个个可重用的组件。你告诉 React「想要什么样的界面」，它负责怎么更新。 • 未来的需求都会从“如何打造一个上帝之盒”的母命题出发，如何组合远程本地，如何解决更多的M乘N问题，Agent需要获取什么信息，使用什么工具，能否拥有比现存context实际更多的资源内容等。 • “资源”比工具可能会更加灵活 • 未来的理想情况是还会有资源调配的系统（ 资源resources 可以理解为结构化的数据实体，比如一个数据库表、一个 GitHub 仓库、一个网页链接，甚至是某种可交互的对象。）如果你是开发者，想给模型用数据库，那么把数据库当成一个“资源”是很合理的做法，模型就可以围绕这个数据库进行对话，比如查某张表、解释字段、写查询语句等。未来的理想情况是，你可以非常自然地告诉模型“我想跟你聊这个数据库表”，然后模型就可以利用资源机制理解这个表的结构并帮助你。 SDK、API、MCP： 📌 现在很多MCP的server只暴露了之前API已有的服务蹭这个风口，实际上不太可用。因为MCP需要回答的问题是如何做到更好的：用户——server——模型三方体验，以及回应API和MCP的区别。 当用户通过服务器或 SDK 使用外部 API（比如 Google Maps）时，用户能不能自定义/获取完整数据，还是必须接受服务器开发者“裁剪后”的数据？ 1. 服务器开发者决定返回哪些字段 ： a. 比如 Google Maps 的工具调用，用户可能希望拿到特定属性（比如经纬度、地点类型、评分），但服务器只返回了一部分。 b. 用户无法覆盖或扩展这个行为，只能“接受它给你的”。 2. SDK 的常见痛点 ： ◦ 很多 SDK（API 封装工具）只暴露了部分参数，导致一些 API 新功能或字段无法用。 Justin/David（MCP作者）回应中提到Google Maps的参考服务器是他们自己写的，所以这种限制是他们的设计结果。而且 故意没有做成“严格结构化的 JSON 数据” —— 而是返回文本、图像、或者是像发给 LLM 的“消息”那样的内容。 因为他们相信： • LLM（大语言模型）擅长处理“杂乱的数据” ，可以自己理解、提取关键信息。 • 如果过度规范数据结构（例如只给出几个字段），反而限制了 LLM 的能力，也不利于随着 LLM 能力提升而扩展系统。 理想状态是“把原始 API 的结果直接传给 LLM” MCP与API有啥区别？ API 是为传统系统服务的标准化接口描述方式，而 MCP 是为 AI 模型量身定制的、支持多模态、状态化、智能交互的“新一代接口系统”。 • OpenAPI 是描述 HTTP 接口的结构化方式（如 Swagger 文档），非常适合“人 后端”的交互。 • 但它关注的是每一个 endpoint、参数、响应格式 ，而不是一个 完整的上下文或心智模型（mental model） 。 • LLM 需要的是“我在和谁对话、我可以做什么、数据在哪里”这类高层语义，而不是一堆 GET /users/{id}。 状态 vs 无状态：MCP 更“有记忆” • 传统 REST API 是 无状态 的：每次请求都不记得上次发生了啥。 • MCP 是状态化的 ：适合 AI 场景中“持续对话”、“上下文连续性”、“跨工具任务链”的需求。 • 例如：用户让模型分析一个文档、然后对比两个表格、再生成报告 —— 这中间的步骤最好是连贯的，有记忆的 • MCP 不打算取代 OpenAPI，而是解决 OpenAPI 解决不了的 “AI 应用的智能交互” 问题。 很多工具现在已经能把 OpenAPI 转换成 MCP 可理解的“资源”或“工具”，反过来也可以。 如何将一个 MCP 导入另一个 MCP？比如我想构建类似 subreddit （reddit的主题板块）的，可能需要 Reddit API 的 MCP 和摘要 MCP。我该如何构建一个超级 MCP？ • MCP 正在设计一个“模块化 + 递归 + 模型独立”的 AI 应用框架，让开发者可以自由组合、连接各种智能服务，让模型真正成为 通用智能助手的基础设施 。 还没完全落地的功能 ： • 自动选择/安装 MCP 组件 ：自动发现并集成可用的 MCP 服务（像插件商店那样）。 • 递归执行 ：支持一个 MCP 服务器像“函数”一样调用其他 MCP 服务并组合。 • 多路复用（multiplexing） ：多个 MCP 服务器可以组合在一个宿主服务器中，行为统一管理。 • DAG（有向无环图）结构 ：支持多模块之间的数据流和任务流。 “在一个 MCP 系统中，可以支持多少个工具或 MCP 服务器，才既不会让模型混乱，又能保持强大的功能和扩展性？” 说白了，就是： 你能在一个 AI 应用里塞多少个能力点（工具、服务）而不会“把模型整懵”？ • 取决于： ◦ 模型的上下文窗口大小（比如 Claude 支持百万 tokens，就可以放得更多） ◦ 工具的名字是否明确 ◦ 描述是否足够区分（避免“工具撞脸”） • 实际系统设计里，可以引入一个“预筛选”步骤： ◦ 让小模型过滤不相关工具 ◦ 把精简后的列表给主模型调用 ◦ 也可以用一个 MCP 服务器做代理，只暴露它“代理的”一部分服务给当前上下文。 • Claude目前被实测能处理 约 250 个工具上下， 超过这个量可能会开始出问题，特别是描述相似度高的工具。 “如果你将 GitHub 和 GitLab 工具放在一起……它们很相似，模型容易搞混。” • 如果你的工具清单中有很多功能重叠的 MCP 服务，比如：upload to github和upload to gitlab • 模型可能不知道选哪个，尤其描述差不多时。所以：工具命名要明确、描述要具体、可以分组/分类使用工具集 开放性、去中心化、信任体系、语言无关性、供应链安全 “我预见会有很多 GitHub 或 Postgres MCP 服务器，这很好，生态会自己收敛。” • 我们不需要强行规定“官方”版本，每个服务器实现都可以 coexist（共存），最终由社区使用频率和实际表现决定哪些成为“主流”。 • 背后的理念 是：“让最好的自己胜出”（类似开源精神），而不是设计标准压制创新。未来 MCP 世界可能就像 npm 或 PyPI 一样，有多个包实现同一功能，由用户选择。 目前信任机制还没解决：这就像 npm 包里，有些库你信不过 —— 我怎么知道这个 mcp github proxy 不是偷偷上传我的私有仓库数据？ • 可能需要 “声誉系统” 或类似于 “由 Anthropic/OpenAI 审核通过” 的标记机制。 注册表（Registry）是一个“危险而诱人的想法” “你可以搞个 registry，加入下载数、评分、点赞……但也很容易被滥用。” • 问题 ：就像 npm 或 PyPI，registry 系统能赋予“信任感”，但也容易被滥用。 • 比如攻击者拿到信任之后更新恶意代码，危害反而更大。 • 建议方案 ：用 MCP Inspector 这类工具，通过查看 实际通信行为 来判断 MCP 是否可信。 • 有些 MCP server 不只是接外部 API，而是提供内建“智能功能”：memory（记忆）、sequential thinking（顺序任务推理） • 比如 memory server 就是一个“可嵌入的记忆模块”，只有 200 行代码，但功能完整。 • 对初创团队或个人开发者来说，是“现成的智能组件”。 未来 AI 应用构建，就像接乐高积木一样，把这些 MCP server 组合就行。 📌 我们现在大致可以把MCP分为两类：API类和智能功能类。 未来的 AI 生态一定是“有状态”的（stateful），但实现上得“渐进式”兼容，不能强推复杂的持久连接。 • 传统 SSE 服务器推送事件 （Server Sent Events）要求模型与 MCP server 保持 长连接 ，但这在大规模场景（如云服务）下难部署。 • 所以MCP团队设计了一个新的协议叫 “可流式 HTTP（streamable HTTP）” ： ◦ 默认像普通 HTTP 一样请求响应 ◦ 逐步增强 ：可以升级为流式结果、会话恢复、双向交互等：既保留状态性，也不牺牲可扩展性。 • 访问权限范围（Scope）目前还没加入，但很关键： 人们会希望 MCP 工具只访问“部分资源”（比如只看某类邮件）。MCP团队对此的态度是：尽管很重要，但除非有 清晰的用户案例 + 当前实现确实解决不了的问题 ，暂时不会入核心协议 未来MCP还有哪些好玩的东西？ 📡 总结 每个信息来源帖子的 MCP 服务器 🎮 AI + 游戏引擎（Godot / 云测试） 🛠️ DevTool + Blender + 3D 工作流（生成式 AI） 📌 GraphQL 让客户端能够精确地指定需要哪些数据，适合 多个微服务整合成一个 API 网关、数据模型复杂、前端需要灵活控制数据结构等场景。 Temporal 是一个用于构建 可扩展、可靠的后台工作流和分布式系统 的开源平台。假如你要处理一个「下单 → 扣款 → 发货 → 发邮件」的流程，通常你得自己写各种消息队列 + 状态管理 + 重试机制，非常复杂。但用 Temporal，就可以像写普通代码那样，写一个函数代表工作流，Temporal 来帮你管理执行、状态、重试、恢复等。 React 是一个由 Facebook 开发的 构建用户界面（UI） 的 JavaScript 库。UI 被拆分成一个个可重用的组件。你告诉 React「想要什么样的界面」，它负责怎么更新。 GraphQL 让客户端能够精确地指定需要哪些数据，适合 多个微服务整合成一个 API 网关、数据模型复杂、前端需要灵活控制数据结构等场景。 Temporal 是一个用于构建 可扩展、可靠的后台工作流和分布式系统 的开源平台。假如你要处理一个「下单 → 扣款 → 发货 → 发邮件」的流程，通常你得自己写各种消息队列 + 状态管理 + 重试机制，非常复杂。但用 Temporal，就可以像写普通代码那样，写一个函数代表工作流，Temporal 来帮你管理执行、状态、重试、恢复等。 React 是一个由 Facebook 开发的 构建用户界面（UI） 的 JavaScript 库。UI 被拆分成一个个可重用的组件。你告诉 React「想要什么样的界面」，它负责怎么更新。 • 未来的需求都会从“如何打造一个上帝之盒”的母命题出发，如何组合远程本地，如何解决更多的M乘N问题，Agent需要获取什么信息，使用什么工具，能否拥有比现存context实际更多的资源内容等。 • “资源”比工具可能会更加灵活 • 未来的理想情况是还会有资源调配的系统（ 资源resources 可以理解为结构化的数据实体，比如一个数据库表、一个 GitHub 仓库、一个网页链接，甚至是某种可交互的对象。）如果你是开发者，想给模型用数据库，那么把数据库当成一个“资源”是很合理的做法，模型就可以围绕这个数据库进行对话，比如查某张表、解释字段、写查询语句等。未来的理想情况是，你可以非常自然地告诉模型“我想跟你聊这个数据库表”，然后模型就可以利用资源机制理解这个表的结构并帮助你。 SDK、API、MCP： 📌 现在很多MCP的server只暴露了之前API已有的服务蹭这个风口，实际上不太可用。因为MCP需要回答的问题是如何做到更好的：用户——server——模型三方体验，以及回应API和MCP的区别。 现在很多MCP的server只暴露了之前API已有的服务蹭这个风口，实际上不太可用。因为MCP需要回答的问题是如何做到更好的：用户——server——模型三方体验，以及回应API和MCP的区别。 当用户通过服务器或 SDK 使用外部 API（比如 Google Maps）时，用户能不能自定义/获取完整数据，还是必须接受服务器开发者“裁剪后”的数据？ 1. 服务器开发者决定返回哪些字段 ： a. 比如 Google Maps 的工具调用，用户可能希望拿到特定属性（比如经纬度、地点类型、评分），但服务器只返回了一部分。 b. 用户无法覆盖或扩展这个行为，只能“接受它给你的”。 a. 比如 Google Maps 的工具调用，用户可能希望拿到特定属性（比如经纬度、地点类型、评分），但服务器只返回了一部分。 b. 用户无法覆盖或扩展这个行为，只能“接受它给你的”。 2. SDK 的常见痛点 ： ◦ 很多 SDK（API 封装工具）只暴露了部分参数，导致一些 API 新功能或字段无法用。 ◦ 很多 SDK（API 封装工具）只暴露了部分参数，导致一些 API 新功能或字段无法用。 Justin/David（MCP作者）回应中提到Google Maps的参考服务器是他们自己写的，所以这种限制是他们的设计结果。而且 故意没有做成“严格结构化的 JSON 数据” —— 而是返回文本、图像、或者是像发给 LLM 的“消息”那样的内容。 因为他们相信： • LLM（大语言模型）擅长处理“杂乱的数据” ，可以自己理解、提取关键信息。 • 如果过度规范数据结构（例如只给出几个字段），反而限制了 LLM 的能力，也不利于随着 LLM 能力提升而扩展系统。 理想状态是“把原始 API 的结果直接传给 LLM” MCP与API有啥区别？ API 是为传统系统服务的标准化接口描述方式，而 MCP 是为 AI 模型量身定制的、支持多模态、状态化、智能交互的“新一代接口系统”。 • OpenAPI 是描述 HTTP 接口的结构化方式（如 Swagger 文档），非常适合“人 后端”的交互。 • 但它关注的是每一个 endpoint、参数、响应格式 ，而不是一个 完整的上下文或心智模型（mental model） 。 • LLM 需要的是“我在和谁对话、我可以做什么、数据在哪里”这类高层语义，而不是一堆 GET /users/{id}。 状态 vs 无状态：MCP 更“有记忆” • 传统 REST API 是 无状态 的：每次请求都不记得上次发生了啥。 • MCP 是状态化的 ：适合 AI 场景中“持续对话”、“上下文连续性”、“跨工具任务链”的需求。 • 例如：用户让模型分析一个文档、然后对比两个表格、再生成报告 —— 这中间的步骤最好是连贯的，有记忆的 • MCP 不打算取代 OpenAPI，而是解决 OpenAPI 解决不了的 “AI 应用的智能交互” 问题。 很多工具现在已经能把 OpenAPI 转换成 MCP 可理解的“资源”或“工具”，反过来也可以。 如何将一个 MCP 导入另一个 MCP？比如我想构建类似 subreddit （reddit的主题板块）的，可能需要 Reddit API 的 MCP 和摘要 MCP。我该如何构建一个超级 MCP？ • MCP 正在设计一个“模块化 + 递归 + 模型独立”的 AI 应用框架，让开发者可以自由组合、连接各种智能服务，让模型真正成为 通用智能助手的基础设施 。 还没完全落地的功能 ： • 自动选择/安装 MCP 组件 ：自动发现并集成可用的 MCP 服务（像插件商店那样）。 • 递归执行 ：支持一个 MCP 服务器像“函数”一样调用其他 MCP 服务并组合。 • 多路复用（multiplexing） ：多个 MCP 服务器可以组合在一个宿主服务器中，行为统一管理。 • DAG（有向无环图）结构 ：支持多模块之间的数据流和任务流。 “在一个 MCP 系统中，可以支持多少个工具或 MCP 服务器，才既不会让模型混乱，又能保持强大的功能和扩展性？” 说白了，就是： 你能在一个 AI 应用里塞多少个能力点（工具、服务）而不会“把模型整懵”？ • 取决于： ◦ 模型的上下文窗口大小（比如 Claude 支持百万 tokens，就可以放得更多） ◦ 工具的名字是否明确 ◦ 描述是否足够区分（避免“工具撞脸”） ◦ 模型的上下文窗口大小（比如 Claude 支持百万 tokens，就可以放得更多） ◦ 工具的名字是否明确 ◦ 描述是否足够区分（避免“工具撞脸”） • 实际系统设计里，可以引入一个“预筛选”步骤： ◦ 让小模型过滤不相关工具 ◦ 把精简后的列表给主模型调用 ◦ 也可以用一个 MCP 服务器做代理，只暴露它“代理的”一部分服务给当前上下文。 ◦ 让小模型过滤不相关工具 ◦ 把精简后的列表给主模型调用 ◦ 也可以用一个 MCP 服务器做代理，只暴露它“代理的”一部分服务给当前上下文。 • Claude目前被实测能处理 约 250 个工具上下， 超过这个量可能会开始出问题，特别是描述相似度高的工具。 “如果你将 GitHub 和 GitLab 工具放在一起……它们很相似，模型容易搞混。” • 如果你的工具清单中有很多功能重叠的 MCP 服务，比如：upload to github和upload to gitlab • 模型可能不知道选哪个，尤其描述差不多时。所以：工具命名要明确、描述要具体、可以分组/分类使用工具集 开放性、去中心化、信任体系、语言无关性、供应链安全 “我预见会有很多 GitHub 或 Postgres MCP 服务器，这很好，生态会自己收敛。” • 我们不需要强行规定“官方”版本，每个服务器实现都可以 coexist（共存），最终由社区使用频率和实际表现决定哪些成为“主流”。 • 背后的理念 是：“让最好的自己胜出”（类似开源精神），而不是设计标准压制创新。未来 MCP 世界可能就像 npm 或 PyPI 一样，有多个包实现同一功能，由用户选择。 目前信任机制还没解决：这就像 npm 包里，有些库你信不过 —— 我怎么知道这个 mcp github proxy 不是偷偷上传我的私有仓库数据？ • 可能需要 “声誉系统” 或类似于 “由 Anthropic/OpenAI 审核通过” 的标记机制。 注册表（Registry）是一个“危险而诱人的想法” “你可以搞个 registry，加入下载数、评分、点赞……但也很容易被滥用。” • 问题 ：就像 npm 或 PyPI，registry 系统能赋予“信任感”，但也容易被滥用。 • 比如攻击者拿到信任之后更新恶意代码，危害反而更大。 • 建议方案 ：用 MCP Inspector 这类工具，通过查看 实际通信行为 来判断 MCP 是否可信。 • 有些 MCP server 不只是接外部 API，而是提供内建“智能功能”：memory（记忆）、sequential thinking（顺序任务推理） • 比如 memory server 就是一个“可嵌入的记忆模块”，只有 200 行代码，但功能完整。 • 对初创团队或个人开发者来说，是“现成的智能组件”。 未来 AI 应用构建，就像接乐高积木一样，把这些 MCP server 组合就行。 📌 我们现在大致可以把MCP分为两类：API类和智能功能类。 我们现在大致可以把MCP分为两类：API类和智能功能类。 未来的 AI 生态一定是“有状态”的（stateful），但实现上得“渐进式”兼容，不能强推复杂的持久连接。 • 传统 SSE 服务器推送事件 （Server Sent Events）要求模型与 MCP server 保持 长连接 ，但这在大规模场景（如云服务）下难部署。 • 所以MCP团队设计了一个新的协议叫 “可流式 HTTP（streamable HTTP）” ： ◦ 默认像普通 HTTP 一样请求响应 ◦ 逐步增强 ：可以升级为流式结果、会话恢复、双向交互等：既保留状态性，也不牺牲可扩展性。 ◦ 默认像普通 HTTP 一样请求响应 ◦ 逐步增强 ：可以升级为流式结果、会话恢复、双向交互等：既保留状态性，也不牺牲可扩展性。 • 访问权限范围（Scope）目前还没加入，但很关键： 人们会希望 MCP 工具只访问“部分资源”（比如只看某类邮件）。MCP团队对此的态度是：尽管很重要，但除非有 清晰的用户案例 + 当前实现确实解决不了的问题 ，暂时不会入核心协议 未来MCP还有哪些好玩的东西？ 📡 总结 每个信息来源帖子的 MCP 服务器 🎮 AI + 游戏引擎（Godot / 云测试） 🛠️ DevTool + Blender + 3D 工作流（生成式 AI） 🔗 原文链接： https://mp.weixin.qq.com/s/64CXeX8U... https://mp.weixin.qq.com/s/64CXeX8U... 原创 k/Justin/David thinkingloop2025年04月12日 14:25 北京 📌 MCP可以让Agentic AI更容易use app/use API（tools），核心在于数据格式的统一，可用MCP作为Agent调用工具的底层标准。 由Anthropic推出后，OpenAI 和现在谷歌都宣布了 MCP 的支持，有效地证实了我们的预测，即 MCP 是Agent 标准之争的潜在赢家。MCP 现在在 GitHub 星标上已经超越了 OpenAPI。 传统的API 通常包括： • URL 地址 （你要请求谁）厨房 • 方法 （GET、POST 等）端菜 • 参数 （你要提供的信息）菜单 • 返回值 （你会得到什么）菜（数据） • MCP 更像是是一本厨房的“工作说明书”或者“厨房合规指南”，告诉厨师当前有哪些原材料、顾客的口味偏好、过去点过的菜（历史对话）等，让厨房确保品控和质量，让出品更确定。 本文通过MCP作者 Justin/David 的访谈，整理了很多有意思的点，包括MCP灵感来源源自于哪里？目前在做什么、未来会做什么、和其他工具的关系以及对于AI能力本质的思考。 还有一些更偏实操的经验，能让开发者顺着MCP未来发展的主线build自己的MCP功能：包括 你能在一个 AI 应用里塞多少个MCP而不会“把模型整懵”？MCP未来的feature：递归执行、多路复用能带来什么？ 等等 MCP可以让Agentic AI更容易use app/use API（tools），核心在于数据格式的统一，可用MCP作为Agent调用工具的底层标准。 由Anthropic推出后，OpenAI 和现在谷歌都宣布了 MCP 的支持，有效地证实了我们的预测，即 MCP 是Agent 标准之争的潜在赢家。MCP 现在在 GitHub 星标上已经超越了 OpenAPI。 传统的API 通常包括： • URL 地址 （你要请求谁）厨房 • 方法 （GET、POST 等）端菜 • 参数 （你要提供的信息）菜单 • 返回值 （你会得到什么）菜（数据） • MCP 更像是是一本厨房的“工作说明书”或者“厨房合规指南”，告诉厨师当前有哪些原材料、顾客的口味偏好、过去点过的菜（历史对话）等，让厨房确保品控和质量，让出品更确定。 本文通过MCP作者 Justin/David 的访谈，整理了很多有意思的点，包括MCP灵感来源源自于哪里？目前在做什么、未来会做什么、和其他工具的关系以及对于AI能力本质的思考。 还有一些更偏实操的经验，能让开发者顺着MCP未来发展的主线build自己的MCP功能：包括 你能在一个 AI 应用里塞多少个MCP而不会“把模型整懵”？MCP未来的feature：递归执行、多路复用能带来什么？ 等等 MCP的灵感来源，我们怎么build MCP？ • MCP的作者 Justin/David 习惯做内部开发工具，他们参考了Cloud Desktop（云桌面固定了一些可用拓展） IDE （更自由、极大地对文件系统和其他很多东西进行操作）来回切换的痛点。让AI use them better。 • GPTs是：app/agent builder集合给user使用。数据方提供的数据受到限制、产品格式受限制。我们需要integration（ 多个系统、服务或功能连接在一起，让它们能协同工作、数据互通、功能叠加 ）我们需要应用程序（面向user），所以面对多对多困境，我们不应该从build一个平台出发，而应该build一个 协议 。 • MCP从去年7月份开工，11月25日launch，一些炫酷的控制 3D 打印机cases最令人欣喜（现在比较有意思的demo也都是在blender等多模态或现实场景的）11labs的语音、音色克隆等接入会加速创意激发。 • MCP的主要灵感来源是 Language Server Protocol（LSP） 语言服务器协议 📌 “The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc.（ 语言服务器协议 是一种被用于编辑器或集成开发环境与支持比如自动补全，定义跳转，查找所有引用等语言特性的语言服务器之间的一种协议）。 具体而言：如果要在任何IDE中提供支持任何编程语言的语言特性检查功能，其实现的复杂度是M N！有M种编程语言，有N种IDE，就需要有M N种插件（内置）的实现。发现相似性了吗？MCP也是M N的逻辑。 “The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc.（ 语言服务器协议 是一种被用于编辑器或集成开发环境与支持比如自动补全，定义跳转，查找所有引用等语言特性的语言服务器之间的一种协议）。 具体而言：如果要在任何IDE中提供支持任何编程语言的语言特性检查功能，其实现的复杂度是M N！有M种编程语言，有N种IDE，就需要有M N种插件（内置）的实现。发现相似性了吗？MCP也是M N的逻辑。 • 具体细节上：MCP在实施JSON RPC 和双向性 ◦ JSON RPC 是一种 远程过程调用协议（RPC） ，使用 JSON 来编码数据。 JSON RPC 让你可以用 JSON 的方式，把“调用函数”的请求发到远程服务器上，并拿到返回值。 因为基于 JSON 格式、协议简单，纯文本传输、通常基于 HTTP 或 WebSocket 等进行传输。 ◦ JSON RPC 是一种 远程过程调用协议（RPC） ，使用 JSON 来编码数据。 JSON RPC 让你可以用 JSON 的方式，把“调用函数”的请求发到远程服务器上，并拿到返回值。 因为基于 JSON 格式、协议简单，纯文本传输、通常基于 HTTP 或 WebSocket 等进行传输。 • HTTP 是单向的：客户端发起请求，服务端响应，服务端不能“主动找”客户端。WebSocket 是双向的：客户端和服务端都能主动发消息。 • 🔁 JSON RPC over WebSocket ：客户端和服务端都能主动发送 JSON RPC 消息，比如：客户端请求服务端执行方法、服务端主动“通知”客户端某些事件（比如推送消息、实时状态变化）。 • MCP一开始在TypeScript, Python,Rust这几种语言中都做了一些 SDK 构建工作，包括客户端和服务器，以实现内部生态系统。 • 我们希望借助LLM+MCP做些什么？以及未来的“上帝之盒”长什么样？ 如何使用资源or信息 自动方式：模型自动搜索并加入上下文、手动方式：用户通过 UI（下拉菜单、回形针菜单）选择和标记