🤝 The Model Context Protocol: Unifying AI Communication
28:32 Share

大家好，欢迎收听AI Unraveled的特别节目。

这是深度潜水，由高级工程师Etienne Newman创作和制作，我们听到一位在加拿大的充满激情的足球爸爸的声音。没错。在我们开始之前，请记住在您收听播客的任何地方点赞和订阅AI Unraveled。这真的对我们很有帮助。绝对的。所以今天我们将深入探讨一个概念，它正在悄然改变AI与现实世界互动的方式。我们正在讨论模型上下文协议。

或MCP，它是一个很大的概念，确实如此。想象一下，您正在参加一个大型的全球会议，到处都是杰出的人才，准备分享精彩的想法，但每个人都在说不同的语言，一片混乱，对吧？非常令人沮丧。这几乎就是我们的AI模型一直困扰的情况。它们非常聪明，非常强大，但却被困在自己的数字泡沫中，你知道的，难以与其他AI甚至只是

基本的外部数据源连接。这就是MCP的用武之地。这是一个革命性的开放标准，专门设计用于打破这些障碍，实现AI的真正连接。人们称之为AI的USBC。这是一个很好的类比，实际上。我们的任务是今天。

要准确分解MCP是什么，为什么它是一个改变游戏规则的东西，以及它如何在我们说话的时候真正塑造AI的未来，我们有一些非常引人入胜的资料可以使用。它真正始于解决核心问题。你提到了AI的呼气。你知道，这些大型语言模型，LLM，尽管它们功能强大，但它们基本上就像……

就像缸中之脑。对。强大但脱节。没错。它们可以根据训练数据进行精彩的推理，但它们与实时信息隔绝。想想贵公司的CRM，您的客户关系管理系统，甚至只是您机器上的本地数据库。是的，如果它看不到最新的数据，它就无法提供最新的答案。正是如此。令人着迷的，或者可能是令人沮丧的是，这种隔离严重削弱了它们在日常实际应用中的潜力。

如果AI助手无法访问销售系统，它就无法总结最新的销售报告。所以它需要一种连接方式。它需要一种标准的连接方式。这导致了资料中提到的N×M集成问题。你有N，越来越多的不同AI模型，以及无数的外部工具、API、数据库。好的。N乘以M。如果没有一个共同的标准，将每一个N模型连接到每一个M工具……

需要它自己的自定义点对点集成。这是一个噩梦。正如他们所说，这是一个组合爆炸。这就是术语。它产生了大量的冗余开发工作，巨大的维护负担，到处都是碎片化的实现。它根本无法扩展。所以MCP介入来解决这个巨大的难题。没错。MCP不仅仅是另一个标准。它从根本上来说是一个瓶颈破坏者。它将指数级集成噩梦变成了一个更简单的线性连接模型。

将您的工具连接到MCP一次，任何启用MCP的AI都可以使用它。将您的AI连接到MCP一次，它就可以访问任何启用MCP的工具。这使得AI集成在经济上实际上是可行的。这是第一次，真的。而且，你知道，对于任何正在浏览这个快速发展的AI世界的人来说，理解MCP这样的基础协议，这不仅仅是有帮助的。如果你想提升你的职业生涯，它正在变得至关重要。说得对。

对于那些希望真正巩固专业知识，也许获得认证的人，无论是Azure、Google Cloud还是AWS，我们的制作人Etkin Newman都编写了一些令人难以置信的AI认证预备书籍。哦，是的。是的。例如Azure AI工程师助理指南、Google Cloud生成式AI领导者认证预备、EWS认证AI从业人员学习指南、Azure AI基础知识，甚至Google机器学习认证。非常全面的内容。人们在哪里可以找到这些？

您可以在DJAmgatech.com上找到所有这些。DJAmgatech.com。我们将确保链接在节目说明中。完美。好的。所以我们理解了为什么，这个巨大的集成问题，但是……

MCP究竟是如何工作的？让我们来分解一下架构。听起来很复杂，但资料说它出奇地优雅。是的，它确实如此，是的。它真正归结为三个主要组件一起工作。好的，组件一。首先，您有MCP客户端。把它想象成信使。它存在于AI应用程序或代理中。它的工作是理解AI需要什么，

制定请求，然后出去获取数据或执行操作，并将结果带回AI。所以如果我在我的IBE中使用编码助手，那么助手在幕后使用MCP客户端。没错。该客户端可能正在与本地MCP服务器通信以访问您的文件，或者可能是一个远程服务器，用于GitHub信息等，所有这些都在悄无声息地发生，以帮助您进行编码。明白了。客户端是信使。接下来是什么？接下来是MCP服务器。这确实是翻译器。

协议的绝对核心。这是将工具和数据源暴露给AI世界的组件。你说是万能翻译器吗？正是如此。它接收来自MCP客户端的结构化请求，弄清楚如何与特定的底层数据源通信。也许是一个数据库查询。也许是一个API调用获取信息，然后以标准化的MCP格式将其发送回客户端。好的。客户端发出请求，服务器翻译和获取。

以及第三部分。这是本地源，或者您可以称之为数据库。这只是MCP服务器提供访问权限的实际数据存储库或工具。它可能是您公司的销售数据库，一个特定的业务应用程序，如Salesforce，您的本地开发环境，任何东西都可以。对。实际的信息来源。是的。正是这三者之间强大的标准化连接。

客户端-服务器-源形成了一个完整的链，将AI代理连接到外部世界。让我们具体说明一下。资料使用销售报告示例。这将一步一步如何进行？好的，很好的例子。假设您的经理要求AI助手显示上个月销量最高的五种产品。

足够简单的请求？对于用户来说，是的。以下是MCP流程。一，助手内部的MCP客户端解释自然语言查询并制定正式的结构化MCP请求。把它想象成办公室秘书起草一份精确的备忘录。好的，备忘录起草完毕。二，该备忘录发送到连接到销售系统的MCP服务器。

服务器读取备忘录，理解它需要销售数据，并将其转换为销售数据库理解的特定查询。服务器与数据库对话。三，销售数据库的本地源执行查询并提取原始交易详细信息，也许是整个销售清单。

就像记录员检索一大堆文件一样。获得了原始数据，现在怎么办？四，原始数据返回MCP服务器。服务器不会直接将其丢回，而是会对其进行处理。它对销售进行排序，识别出销量最高的五种产品，并将这些信息整齐地排列，也许是客户端期望的JSON格式。

就像将凌乱的电子表格数据转换为清晰的图表一样。啊，所以它清理了它。没错。五，MCP客户端从服务器接收此经过改进的有组织的数据，并将其传递回AI模型。

然后，AI使用此干净的数据为经理生成清晰简洁的摘要。哇，好的。与为每种请求类型构建自定义API调用和数据解析器相比，这听起来非常简化。是的。真正引人注目的是它如何无缝地协调整个过程。

为AI开发人员和工具提供商抽象了复杂性。真正令人惊奇的是这一切发生的速度有多快。MCP并非一直存在，对吧？根本不是。它从一个想法到成为不可或缺的标准的旅程非常迅速。

它于2024年11月由Anthropic推出并立即开源。第一天就开源。这似乎是关键。绝对的。这是一个非常深思熟虑的举动。与OpenAI早期的函数调用API不同，后者功能强大但特定于供应商，Anthropic从一开始就将MCP定位为一个中立的开源项目。这建立了信任，鼓励其他人加入。没错。它培养了这种信任。

并推动了整个行业，甚至包括竞争对手在内的广泛而快速的采用。让我们谈谈这个时间表。听起来相当紧凑。它确实令人印象深刻。所以2024年11月，Anthropic推出了它。他们提供了SDK，软件开发工具包，以及一些针对Google Drive、Slack、GitHub等常用工具的初始参考服务器实现。

Block、Replit、Sourcegraph、Zed等主要早期采用者立即加入。好的，强劲的开端。然后是重头戏，2025年3月。OpenAI，可以说是Anthropic的主要竞争对手，宣布他们正在采用MCP。他们将其集成到ChatGPT桌面应用程序、他们的代理SDK、他们的响应API中。Sam Waltman本人称其为关键一步。

哇。OpenAI采用Anthropic的标准，这意义重大。意义重大。它基本上巩固了MCP的地位。仅仅一个月后，2025年4月，Google DeepMind为其Gemini模型认可了它。Demis Hassabis表示，它正迅速成为一项开放标准。好的。所以Anthropic、OpenAI、Google，这些大公司都参与其中。在几个月内。到2025年5月，生态系统爆炸式增长。

资料中提到Glamour上列出了超过5000个公共MCP服务器，Glamour已成为查找这些启用MCP的工具和服务的中央目录。大约六个月内有5000个服务器。这是令人难以置信的增长。它确实体现了开放协作生态系统的强大力量。你知道，它是开源的，可以防止供应商锁定。开发人员不会绑定到一个LOM提供商或一组工具。

他们有灵活性。而且也有官方支持，对吧？就像一个GitHub组织？是的。官方模型上下文协议GitHub组织是中心枢纽。Anthropic仍然管理它，但它对社区贡献开放。在那里您可以找到规范、多语言SDK、TypeScript、Python、Java、C#、Go、Kotlin。所以每个人都有工具。几乎如此。

至关重要的是，他们还提供了MCP检查器。这是一个可视化测试工具，对于构建MCP服务器的开发人员来说绝对是不可或缺的。它允许他们测试和调试其实现，而无需完整的AI客户端应用程序。大大加快了速度。这是有道理的。你知道，资料在这里提供了一个很好的类比。MCP就像基础设施一样。

它类似于语言服务器协议，或LSP。啊，LSP，是的。它彻底改变了代码编辑器。没错。LSP将语言智能（如自动完成或错误检查）与特定的编辑器分离。MCP对AI代理做了类似的事情。

它将代理的推理能力与其使用的特定工具分离。好的，那么让我们更技术化一些。如果它是这种通用语言，它实际上是建立在什么之上的？这些消息是如何来回传递的？在引擎盖下，MCP是建立在一个完善的标准JSON-RPC 2.0之上的。JSON-RPC。好的，那是什么？

把它想象成一种非常轻量级、简单的方法，让系统进行远程过程调用，基本上是要求另一个系统使用JSON运行函数，JSON只是人类可读的文本。它是无状态的、基于文本的、非常高效的。所以它不是什么全新的复杂传输层。它使用现有的东西。对。它建立在经过验证的技术之上。MCP中的通信遵循清晰的结构。您有三种主要的消息类型。首先，请求。

这些是要求执行某些操作的消息，例如tools list，要求服务器询问它提供的工具。它们总是有一个唯一的ID，以便客户端以后可以匹配响应。它们可以双向进行，客户端到服务器或服务器到客户端。明白了。请求需要答案。没错。这引出了……

响应。这些是对请求的回复。它们携带与它们正在回答的请求相同的ID，并且它们包含操作的结果或错误（如果出现问题）。有道理。请求，响应。第三个是什么？通知。这些是一次性消息。只是发送信息而不期望回复。想想状态更新，例如正在处理您的请求，或者服务器通知客户端文件已更改。它们没有ID。好的。请求、响应、通知。足够简单。而且

连接本身是如何工作的？他们只是开始聊天吗？不，有一个适当的生命周期。它从初始化阶段开始，一个握手，客户端和服务器交换功能并就协议版本达成一致。然后它们进入操作阶段，在此期间它们实际上交换所有这些请求、响应和通知。

最后，有一个定义的关闭过程来干净地关闭连接。它们如何通过网络物理连接？它支持两种主要方式。对于本地集成，例如IDE示例，其中工具可能正在您的机器上运行，它通常使用Stadio标准输入输出。

基本上，服务器作为子进程运行，它们直接通信。好的，本地连接。对于远程连接，例如与其他地方托管的服务器通信，它使用可流式传输的HTTP，通常使用服务器发送的事件或SSE。这允许通过标准Web协议进行高效、实时、双向通信。对，所以它涵盖了本地和网络场景。现在，你之前提到了功能。资料谈到了原语。那些是什么？啊，是的，原语。我认为真正的力量就在这里。

它们是基本构建块，MCP服务器可以向AI客户端提供的标准化类型的东西。它们旨在直接映射到高级AI代理实际需要的内容。好的，那么服务器可以提供什么？在服务器端，有三个主要的原语。首先，

工具。这些是AI可以执行的函数。例如查询数据库、发送Slack消息、创建zip问题。至关重要的是，每个工具都宣传自己的模式。它的名称、描述、它需要的输入、它产生的输出。因此，AI可以动态地发现和学习如何使用工具。没错。运行时发现是关键。第二，资源。

把它想象成类似文件的只读上下文数据。它可能是文本文件的内容、数据库中的特定行、API调用的响应。它们的工作只是提供AI进行推理或完成任务所需的信息。好的。工具用于操作，资源用于信息。第三。第三，提示。

这些是可重用的、预定义的模板或工作流程。它们可以指导AI甚至人类用户完成特定任务。想象一下，服务器提供了一个代码审查提示，该提示可以有效地组织代码审查交互。有趣。工具、资源、提示，这就是服务器提供的？但是你说通信是双向的？对。客户端，或者更确切地说，包含客户端的主机应用程序，也可以向服务器提供功能。

这使得更复杂的交互成为可能。比如什么？一个关键的是采样。这允许MCP服务器要求主机应用程序（如您的IDE或AI助手）使用其底层LLM生成一些文本或做出决定。等等，服务器要求客户端的LLM思考？是的。它实现了这种递归的思想-行动循环。服务器可能需要LLM的帮助来解释某些内容或计划下一步。

对于复杂的代理行为非常强大。好的，这很酷。还有什么？有路由，客户端告诉服务器相关的文件系统边界，例如当前项目中的根目录。这有助于服务器在正确的上下文中安全地运行。

以及引出，服务器可以意识到它缺少运行工具所需的一些信息，并且它可以要求主机应用程序弹出一个UI元素并要求用户进行澄清或缺少参数。啊，所以服务器可以通过客户端界面向用户寻求帮助。正是如此。它避免了交互只是默默地失败。你知道，当你把所有这些原语放在一起时，服务器端的工具、资源、提示，客户端端的采样、路由、引出，

你认为它们是如何实现比仅仅调用固定API更动态、更智能的交互的呢？嗯，感觉灵活多了。运行时发现，服务器要求LLM思考，要求用户输入。它不像一个严格的脚本，更像是在AI、工具和用户之间的对话。没错。它超越了简单的函数调用，进入了真正的协作。

因此，对于正在收听的开发人员来说，使用MCP实际构建某些东西有多难？资料中提到了一个教程。是的，有一个很好的入门指南。它指导您构建您的第一个MCP服务器，特别是Python和TypeScript中的简单GitHub问题提取器，涵盖了最流行的语言。这包括什么？实际上是相当标准的东西。

设置您的开发环境，安装MCP SDK，然后定义一个工具，可能称为get-issues，它接受一个存储库名称并返回打开的问题，并且可能公开一个资源，例如get-troporadme，以获取URIAD-EME文件以供上下文使用。

而你提到的MCP检查器工具在这里很有帮助。非常大。一旦您编写了基本的服务器代码，您就可以启动检查器。您可以连接到正在运行的服务器，查看它是否正确列出了get tissues工具和get report admin资源。您可以检查它们的模式，甚至可以在检查器中尝试使用测试输入调用该工具，并查看结果或任何错误。因此，您可以在甚至编写客户端之前完全独立地测试服务器。没错。它是即插即用的调试。它强化了动态发现。

检查器，就像任何客户端一样，只需连接并询问session.list tools和session.list sources即可查看服务器此时提供的功能。然后从客户端侧将其集成到实际的AI应用程序中。这也有所介绍。如何连接到这些服务器，无论是通过Stereo运行的本地服务器还是通过HTTP运行的远程服务器。

提到的一个很好的案例研究是增强IDE，例如Cursor，它以其AI功能而闻名。IDE如何使用MCP？嗯，IDE充当主机应用程序。它可以同时管理多个MCP客户端。也许一个客户端连接到理解您项目文件结构的本地MCP服务器。另一个客户端可以连接到远程MCP服务器，例如存储在Notion中的您公司的文档。

啊，所以它使用MCP从多个地方收集上下文。没错。它协调这些客户端以收集所有相关的上下文，您正在处理的代码，来自Notion的项目样式指南，并将所有这些上下文提供给其LLM以提供真正准确的上下文感知编码帮助。这很有道理。你知道，如果人们受到启发并想要开始构建AI应用程序，也许使用MCP或其他工具，

有什么可以帮助他们入门吗？绝对的。我们的制作人Etienne Newman不仅制作了认证指南。他还制作了AI Unraveled Builder's Toolkit。Builder's Toolkit？里面有什么？它专为想要亲自动手的人设计。它包括一系列PDF格式的AI教程、更多机器学习认证指南，甚至音频和视频格式的AI教程。

基本上是帮助您启动构建您自己的AI项目的资源。这对于准备好迈出下一步的听众来说非常有用。当然。同样，您可以在DJMGateTech.com的节目说明中找到工具包的链接。完美。现在我们正在讨论让AI访问各种工具和数据，执行函数。安全必须是一个巨大的问题。

哦，绝对至关重要。令人着迷的，也许有点违反直觉的是，MCP规范故意将主要安全负担转移到主机应用程序上。所以不是协议本身或服务器，而是用户正在交互的应用程序，例如IDE或AI助手应用程序。没错。该协议为安全交互提供了框架。

但正是主机，用户最终信任的东西，必须执行规则并充当守门人。那里的核心原则是什么？资料列出了几个关键原则。首先也是最重要的，用户同意和控制。用户必须是最终仲裁者。

任何潜在的敏感操作，例如运行修改文件的工具或访问私有数据，都需要主机应用程序发出明确的UI提示，要求用户许可。没有无声操作。好的。用户负责。有道理。第二，数据隐私。类似的想法。在任何潜在的私有用户数据作为资源或工具输入暴露给MCP服务器之前，都需要明确的用户内容。

第三，工具安全。这至关重要。服务器提供的工具可能做任何事情，对吧？它们代表任意代码执行。因此，主机应用程序必须极其谨慎地对待它们。它不能隐式信任服务器为其工具提供的描述。在调用任何工具之前，特别是来自不受信任的服务器的工具之前，它必须获得明确的用户同意。最后，LLM采样控制。

如果服务器使用该采样功能要求主机的LLM生成文本……主机也需要控制它。是的。用户理想情况下应该能够批准采样请求，查看服务器想要使用的确切提示，并控制服务器获得LLM响应的哪些部分。

完全透明和控制。听起来主机应用程序承担了很多责任。是的。这提出了一个重要的问题，特别是对于企业来说。从一开始就嵌入这种安全设计理念对于MCP的广泛企业采用究竟有多么重要？是的，如果MCP被认为是不安全的，企业不会碰它。

没错。资料甚至深入研究了MCP生命周期的威胁建模，考虑了潜在的攻击，例如名称冲突（恶意服务器冒充合法服务器）、安装程序欺骗，甚至是从安全性较差的服务器进行沙箱逃逸。那么建议是什么？对于服务器开发人员来说，它是多层的。严格验证和清理所有输入。实施最小权限原则。保持依赖项安全。

对于那些客户端开发人员，构建我们讨论过的那些强大的用户同意流程，验证和验证来自服务器的结果，实现安全日志记录。对于部署此的企业？他们应该针对零常设权限模型，也许维护一个他们员工可以连接到的受信任MCP服务器的精选注册表，并在可能的情况下使用不可变基础设施来运行服务器。这是一项共同的努力，但这种积极主动的安全立场使组织能够自信地利用MCP的力量。

好的，所以MCP是这个功能强大的安全连接器。它如何融入更大的图景？它不是AI世界中唯一存在的标准或协议，对吧？不，绝对不是。它在一个更大的生态系统中运行。了解它与其他事物的关系很重要。例如，传统的API，如REST或GraphQL。MCP是否正在取代它们？不是真的。MCP最好被认为是建立在这些现有机制之上的AI原生抽象层。

服务器可能在内部使用REST API来完成请求，但它通过标准化的MCP接口公开该功能。关键的区别在于MCP的动态运行时发现与您通常依赖于传统API的静态文档。好的。那么ONNX，开放神经网络交换呢？互补的。ONNX标准化了机器学习模型本身的格式，可以说是大脑。

MCP标准化了运行时交互，即大脑一旦运行，如何与外部世界、感官和手进行通信。它们解决了不同的问题。还有MLflow？也是互补的。MLflow更像是一个MLOps平台，管理整个机器学习生命周期，例如实验跟踪、模型部署、模型注册表。MCP纯粹专注于模型或代理部署后的运行时通信。明白了。但资料强调了一种比较尤其重要。

MCP与A2A。什么是A2A？A2A代表代理到代理协议。这非常重要。MCP和A2A被明确设计为一起工作。它们解决了两个不同的问题。

但复杂AI系统所需的重新加载类型的通信。好的，它们有什么不同？正如我们所讨论的，MCP定义了代理到工具的通信。它关乎单个AI代理如何连接到其工具箱，即它需要完成其工作所需的各种API、数据库、文件系统等。代理与工具对话。对。另一方面，A2A最初由Google开发，现在由Linux基金会管理，它定义了代理到代理的通信。

它关乎多个可能自主的、可能独立拥有的AI代理如何协作、相互委托任务、有效地协商和沟通。啊，所以MCP是一个代理使用许多工具。A2A是许多代理相互对话。你明白了。资料在这里也使用了一个很好的类比。如果你的AI代理是一个汽车修理工，MCP就是他们工具箱中所有工具的通用标准。

插座、扳手、诊断扫描仪。它确保他们可以将工具连接到进入车间的任何品牌或型号的汽车。对。工具与汽车一起工作。然后，A2A是机械师用来与其他人交谈的标准化语言，零件供应商订购特定零件，

也许是另一个专家机械师来咨询一个棘手的问题，甚至是客户来解释维修。好的，这很好地澄清了这一点。MCP用于工具，A2A用于团队合作。没错。您可以看到，对于复杂现实世界的工作流程，例如可能使用AI编排整个供应链，您几乎肯定需要这两个协议有效地协同工作。

那么展望未来，MCP的下一步是什么？这一切将走向何方？嗯，资料中概述的路线图非常令人兴奋。他们关注的一些关键领域。一个巨大的领域是标准化的身份验证和授权。目前，安全地连接到远程MCP服务器，特别是那些需要付费或处理敏感数据的服务器，仍然是一个尚未解决的挑战。他们需要标准的方法来处理登录和权限。是的，这对于现实世界的使用似乎至关重要。绝对的。

另一个推动因素是建立官方的可信服务器注册表。这将有助于应对诸如名称冲突或用户连接到恶意服务器之类的安全威胁。拥有一个经过审核的中央目录将建立很大的信心。就像一个应用商店，但用于 MCP 服务器。有点像，是的。是的。当然，还有持续的协议增强，使流数据更高效，并且

可能允许服务器更积极地向客户端推送更新，诸如此类。除了核心协议之外，研究是否将其推得更远？哦，是的。人们已经在研究诸如企业部署的集中式安全监督、更好地管理真正漫长而复杂的代理工作流的状态、确保 MCP 在多租户云环境中良好扩展的方法。甚至连接到物理世界。这是一个引人入胜的领域，与智能环境、物联网 (IoT) 和工业自动化集成。

想象一下，AI 代理不仅使用 MCP 访问数据库，还与工厂或智能家居中的传感器和控制装置进行交互。哇。所以把所有这些放在一起，MCP 究竟带来了什么可能性？资料来源很好地总结了这一点。

降低集成成本。显然，那个 NILAM 问题变得可控了。显著提高 AI 能力。突然之间，你的 AI 不仅仅是一个“缸中之脑”。它连接到数千种专业工具和数据源，就像有数千名专家随时待命一样。如果实施得当，安全性也会增强。通过标准化和明确的责任划分来增强安全性。

加快开发速度，工程师们可以停止浪费时间在定制连接器上，而专注于构建独特的 AI 功能和价值。这听起来不仅仅是一个技术标准。这是一场范式转变。它将 AI 模型从这些孤立的理论大脑转变为多功能、实用、有效的执行者，它们可以实际交互并影响现实世界。这引出了一个相当深刻的最终思考。如果 MCP 是让 AI 连接到世界上所有数据和工具的通用连接器……

当这些连接的 AI 开始真正自主、真正普遍存在于我们的日常生活中时，会产生哪些全新的伦理或社会问题？

值得思考。绝对值得思考。好吧，非常感谢您今天与我们一起深入探讨模型上下文协议。希望这能让我们听众真正了解 MCP 是什么、为什么重要以及它所拥有的巨大潜力。这绝对是一个值得关注的领域。绝对的。如果这次深入探讨激发了您的好奇心，并且您可能正在考虑动手操作，请务必查看 Etienne Newman 的

我们之前提到的 Azure、Google Cloud 和 AWS 的 AI 认证预备书籍，以及 AI Unraveled Builder's Toolkit。这些都是弥合理解与实践之间差距的绝佳资源。当然。Etienne 的所有资料都可以在 djamgate.tech.com 上找到。就像我们所说的那样，您需要的所有链接都在我们的节目说明中。

我们也强烈建议您查看官方的 MCP 资源本身，例如 GitHub 存储库和 Anthropix 文档。是的，深入研究原始资料。再次感谢您加入我们的深度潜水。直到下次，继续学习，继续质疑，继续连接这些点。