远程模型上下文协议服务器

示例：不带SDK的远程模型上下文协议（MCP）服务器

此存储库演示了MCP客户端和远程服务器实现的最小示例。 随之而来 模型上下文协议规范 没有 依赖官方或第三方MCP SDK，以便您可以检查 MCP流，包括通过OAuth2.1进行身份验证和授权。 这主要适用于由于现有的服务器堆栈和业务逻辑而无法使用MCP SDK的企业软件/服务器。

此演示使用 流式HTTP 为了 远程 MCP服务器实现，它允许您 统一 您的数据服务器和MCP服务器。 此演示不使用 stdio传输 它是为“本地”MCP服务器设计的。 有几个原因可以解释为什么它更喜欢追求一个 远程 MCP服务器，而不是本地MCP服务器。看 为什么要引入远程MCP服务器？ 了解更多信息。

虽然这个演示是用Python编写的，作为后端服务器，Vue.js/vite作为webview服务器， 所实现的逻辑可以被翻译/采用为其他编程语言 其中SDK可能还不支持。

入门

在VS Code扩展上运行聊天

1. 运行后端服务器.
2. 构建网络视图.
3. 构建语言服务器.
4. 运行聊天扩展程序

在浏览器上运行聊天

1. 运行后端服务器.
2. 运行webview服务器.
3. 访问http://localhost:5173/在浏览器中。

概述

此演示基于中描述的最新MCP规范https://modelcontextprotocol.io/specification/2025-06-18.

• 它支持OAuth2.1流，根据https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#2-2-例如%3A授权码授予。此身份验证流支持OAuth 2.1中要求的PKCE（使用SHA256生成代码挑战）。
• 前端组件表示（例如webview、语言服务器、编辑器扩展）：
  • MCP主机 和 MCP客户端 在……里面 MCP术语表.
  • 客户端 在……里面 OAuth术语表.
• 后端组件表示：
  • MCP服务器 和 本地数据源 在……里面 MCP术语表.
  • 资源服务器 和 授权服务器 在……里面 OAuth术语表.
  • 内存数据库中的虚拟用户被调用 资源所有者 在……里面 OAuth术语表.

以下是身份验证流程：

1. 用户访问网站。如果尚未完成授权，则将其重定向到授权服务器(GET /authorize 端点）。
2. 用户登录到授权服务器(POST /login 端点）。如果成功，它将被重定向到前端的回调URL(http://localhost:5173/callback).
3. 前端请求 POST /token 端点生成访问令牌（JWT）。
4. 向MCP端点发送前端请求 POST /mcp 或 GET /mcp 通过承载令牌认证。

为什么要引入远程MCP服务器？

模型上下文协议从 语言服务器协议，这在https://modelcontextprotocol.io/specification/2025-06-18:

MCP从语言服务器协议中获得了一些灵感，该协议规范了如何在整个开发工具生态系统中添加对编程语言的支持。同样，MCP规范了如何将其他上下文和工具集成到人工智能应用程序的生态系统中。

LSP是对 尽量减少编程语言和代码编辑器之间的摩擦，以及 大多数情况下，语言服务器都是作为 本地 服务器。然而，MCP不必遵循相同的模式，因为：

• 编辑器扩展主要需要用户计算机中的本地数据，例如在VS code中解析代码和注释。大多数时候，它不需要与远程数据交互。
• MCP主机需要 两者 用户计算机中的本地数据 和 远程服务中用户的远程和私有数据。本地和远程环境/上下文都可以通过LLM代理进行交互。

由于数据访问模式的这种不同性质，最好按以下方式设计关注点的分离：

• 远程MCP服务器仅用于访问远程上下文。
  • 私有数据服务器应通过Streamable HTTP提供MCP集成功能。这确保了MCP服务器 作为MCP主机的插件 只能与远程上下文交互，这不会与本地上下文处理程序的职责冲突。
• 本地MCP服务器仅用于访问本地上下文。
  • 融入当地环境 能 由本地MCP服务器处理 或 可以是MCP主机业务逻辑的一部分（例如Cursor）。
  • 本地上下文处理程序可以与用户的本地环境交互，例如在本地文件存储中创建文件。
  • 本地上下文处理程序可以与N个远程MCP服务器结合使用，例如使用本地MCP服务器编辑文件。通过远程GitHub MCP服务器将更改推送到GitHub，或通过远程GitLab MCP服务器推送到GitLab。
  • 为了尊重远程MCP服务器的边界，本地上下文处理程序不应与远程上下文交互。
• MCP主机/LLM决定应执行哪个工具来解析用户的输入。

此外，选择远程MCP服务器而不是本地MCP服务器有几个原因，例如：

• 向后兼容性：在本地MCP服务器中，您必须对数据服务器的API请求进行硬编码。当您更改数据服务器的API规范时，本地MCP服务器可能会停止工作，因为API请求不兼容。将MCP服务器和数据服务器统一起来可以最大限度地降低这种风险。
• 可扩展性和可维护性：在本地MCP服务器中，当它需要来自您的数据服务器的特定上下文数据时，您首先必须实现相应的API。将MCP服务器和数据服务器统一起来可以减少这种摩擦。
• 分类：对于本地MCP服务器，它要求数据服务器的API是公共的。对于远程MCP服务器，它只暴露了MCP传输的几个端点。
• 遥测：使用本地MCP服务器，您可能无法通过LLM跟踪数据使用情况，因为服务器无法区分请求者类型（例如，这是CI中的自动化还是MCP工具调用？）。集中访问MCP的端点允许您跟踪它。