Skip to content
祛魅 MCP

第 6 章：MCP 生态系统

MCP 发布以来，吸引了众多开发者的关注和参与，形成了丰富的生态系统。本章将介绍 MCP 生态系统的各个方面，包括现有的 MCP 资源和对未来 MCP 生态发展的探讨。

6.1 MCP 工具链

为了方便开发者基于 MCP 快速开发服务器和客户端，MCP 官方推出了一系列跟 MCP 配套的工具。包括：

  • SDK

MCP 官方发布了包括 Python、TypeScript、Java、Kotlin、C#、Rust 在内的多种语言的 SDK。

你可以在 MCP 官方仓库 获取这些 SDK 的源代码。并按照说明文档进行安装和使用。

  • 调试工具

MCP 官方发布了一个名为：MCP Inspector 的工具，帮助开发者在开发 MCP 服务器时，模拟发起请求，调试 MCP 服务器。使用方式如下所示：

Terminal window
npx @modelcontextprotocol/inspector <command>

其中，<command> 是 MCP 服务器的运行命令。

  • 命令行工具

MCP 官方发布了两个命令行工具，分别用于创建基于 TypeScript 和 Python 的 MCP 服务器。

  1. 创建基于 TypeScript 的 MCP 服务器
Terminal window
npx @modelcontextprotocol/create-server my-server
  1. 创建基于 Python 的 MCP 服务器
Terminal window
uvx create-mcp-server

除了 MCP 官方发布的工具之外，在社区中还存在很多由第三方发布的实用工具，比如：

  • mcp-go 使用 Go 语言开发 MCP 服务器的 SDK
  • fastmcp 快速开发 MCP 服务器的框架
  • fastapi_mcp 把 FastAPI 转成 MCP 服务器的工具
  • mcp-cli 在命令行调试 MCP 服务器的工具
  • mcp-get 快速安装 MCP 服务器的工具
  • mcp-proxy 转换 MCP 服务器传输方式的工具

6.2 MCP 平台与服务

MCP 本身是一个开源协议，任何人都可以基于 MCP 开发服务器和客户端，这些服务器和客户端可以发布到任何地方，被任何人，以任何方式使用。从这个角度看，我们可以说：

MCP 是分布式、去中心化的。

围绕 MCP 生态，有很多可以做的事情，我设想了一套架构方案，来实现在 MCP 生态内的业务闭环，如图 6-1 所示：

图 6-1：基于 MCP 生态的系统架构图

接下来，我想谈谈对这几套系统的设想，以及这些系统的主要功能和价值。

  • 海量的 MCP 服务器：mcp servers

MCP 发布以来，生态迅速发展，全世界的开发者基于 MCP 开发了大量的 MCP 服务器，覆盖的业务场景广泛。

然而，MCP 服务器的质量参差不齐。如何从海量的 MCP 服务器之中选择适合自己业务需求的一部分，是 MCP 服务器使用者面临的一个很大问题。

  • MCP 应用市场：mcp marketplace

为了更好的收集、分类和分发 MCP 服务器，我们需要一个 MCP 应用市场。MCP 官方暂未推出应用市场，诸多第三方 MCP 应用市场率先推出了，代表产品包括 MCP.so、Smithery 等。

MCP 应用市场存在的意义和价值，是提供一个中心化的渠道，让 MCP 服务器与使用者之间可以更好地连接。一定程度上可以类比 App Store 和 Google Play 在移动应用生态中的定位。

  • MCP 服务器路由平台：mcprouter

前面聊到，MCP 是分布式、去中心化的。用户使用 MCP 服务器的一种主要方式，是把 MCP 服务器代码拉到电脑本地运行。对用户而言，使用成本较高（需要安装环境、配置、运行）。

因此，一个中心化的 MCP 服务器路由平台很有必要。

这个 MCP 服务器路由平台的核心功能，是对接 MCP 应用市场上的高质量 MCP 服务器，通过云端部署的方式，对 MCP 服务器进行托管，再对外提供统一的接入方式。

开发过大模型应用的人应该对 OpenRouter 这个平台不陌生，如图 6-2 所示。OpenRouter 是一个大模型路由平台，对接了大量的开源大模型和商业大模型，提供统一的 API 接入方式。开发者只需要选择自己需要的大模型，按量付费使用。

图 6-2：OpenRouter 官网

OpenRouter 的出现降低了大模型的接入门槛，让开发者可以专注在业务逻辑的开发上，而不需要太关心大模型的接入问题。

参考 OpenRouter，我们可以实现一个 mcprouter 平台，提供 MCP 服务器的路由功能。在云端部署 MCP 服务器，对外提供 API 或 Streamable HTTP 接入。用户使用 MCP 服务器，不需要再把代码拉到本地运行，而是通过一个 URL 地址，简单配置即可接入。

跟 OpenRouter 对接有限的大模型不同，mcprouter 对接的 MCP 服务器有更大的数量级，且每个 MCP 服务器一般都内置多个工具。如果把每个工具作为一项原子能力，mcprouter 也可以做成一个 API 聚合平台。

很多人意识到了 mcprouter 此类平台的重要性。一些产品在做此类的事情，比如 Smithery 、composio、Glama 等。一些云厂商，比如 Cloudflare、阿里云、腾讯云等，也在推广自己的 MCP 服务器部署和路由服务。

我在 MCP.so 也上线了 MCP 服务器路由功能，并且开源了 mcprouter 这个项目。

结合我的开发实践，要实现大规模的 MCP 服务器路由平台，还面临着不小挑战，有比较大的 MCP 服务器改造成本：

  1. 大部分的 MCP 服务器，都是基于 stdio 传输机制开发的，进程开销太大，难以支持高并发请求
  2. 大部分的 MCP 服务器，都是在启动时从环境变量读取鉴权参数，无法在云端多租户（多人）场景使用。

期待后面 MCP 通过版本升级，从协议层面更好地解决并发请求和用户鉴权问题。MCP 服务器路由平台也会有更好的发展。

  • 大模型客户端：chatmcp

大模型客户端为用户接入 MCP 生态系统提供了最便捷的途径。用户只需在对话框输入内容，选择所需的 MCP 服务器，大模型客户端即可调用 MCP 服务器来完成用户需求。

“chatmcp”可作为所有支持 MCP 的大模型客户端的统称。除常见的对话类客户端（如 Claude、ChatGPT、豆包等）外，还包括 AI 编辑器（如 Cursor、Windsurf、VS Code 等）以及各类插件（如 Cline、GitHub Copilot 等）。

  • AI 智能体：ai agents

Manus 的出现展现了 AI 智能体的巨大潜力，也推动了 AI 智能体市场的发展。

MCP 实现了原子能力（如浏览器操作、命令行操作、文件操作等）的标准化，这意味着在开发不同领域的 AI 智能体时，开发者无需重复实现通用功能。开发者只需选择所需的原子能力，通过对原子能力的组装和调度，即可高效完成 AI 智能体的开发工作。

  • 命令行工具：omcp

大模型领域有一个知名的命令行工具： ollama，如图 6-3 所示：

图 6-3：Ollama 官网

Ollama 为用户提供了便捷的大模型本地部署与管理能力，使得用户能够在本地环境中快速下载、运行和切换多种开源大模型。

Ollama 支持通过简单的命令行操作，实现模型的加载、推理和管理，极大地降低了大模型的使用门槛。 此外，Ollama 还具备良好的扩展性和兼容性，支持多平台运行，并能够与其他 AI 工具和开发框架集成。无论是开发者进行模型测试，还是用户体验本地 AI 服务，Ollama 都提供了高效、灵活的解决方案，成为推动大模型普及和应用的重要工具之一。

参考 Ollama，我们也可以实现一个 omcp 工具，帮助用户在本地管理 MCP 服务器，并提供便捷的命令行操作，实现 MCP 服务器的安装、配置、运行等操作，降低 MCP 服务器使用门槛。

Ollama 对接的是大模型，omcp 对接的是 MCP 服务器。从生态发展的角度，omcp 是一个必然需要的工具。目前市面上已经有人在做此类的工具，比如：mcpm、mcphub 等。

6.3 MCP 上下游对接与供应链整合

在 6.2 小节，我们探讨了 MCP 生态系统内各类系统的作用与协作关系。

其中，mcprouter 的核心职责是连接生态系统的上下游，作为中心化的枢纽，促进供需双方的高效对接。chatmcp 和 ai agents 等客户端视为 mcprouter 的上游，代表消费方；而 MCP 服务器及其所集成的各类数据和服务，视为 mcprouter 的下游，代表供给方。如图 6-4 所示。

mcprouter 向消费方提供统一的 API 接入，采用标准化的鉴权机制（如 apikey），使消费方能够便捷地访问下游提供的多样化数据和功能服务。

在与供给方对接时，mcprouter 需适配不同的鉴权方式和凭证类型。例如，对接高德地图 MCP 时需使用高德地图的 apikey，而对接其他服务时可能需要 token 等凭证。因此，mcprouter 需要具备供应链整合能力，采购并对接下游各类数据和服务资源。同时，mcprouter 为上游消费方提供统一的鉴权方式，消费方只需在 mcprouter 平台申请一个 apikey，便可调用多个后端服务，实现高效、统一的接入。

图 6-4：mcprouter 的上下游对接关系

6.4 MCP 社区与资源

MCP 是使用 MIT 许可发布的开源协议，依靠社区发展，任何人都可以参与 MCP 的修订。

  • 如何参与 MCP 的修订

MCP 社区成员可以通过给协议的 Github 仓库提交 PR （Pull Request）的方式参与 MCP 的修订。关于 MCP 的问题讨论也可以在这个仓库提交 issue。Github 仓库地址是：

https://github.com/modelcontextprotocol/modelcontextprotocol

  • MCP 资源

MCP 官方收集了大量的 MCP 资源，包括 MCP 服务器、MCP 客户端、MCP 工具等，汇总在 Github 仓库，通过 README 文档整理展示。Github 仓库地址是：

https://github.com/modelcontextprotocol/servers

  • 第三方社区

由第三方建立的 MCP 社区，日常讨论 MCP 相关的话题，包括：

Discord 讨论组：https://discord.com/invite/TFE8FmjCdS

Reddit 社区：https://www.reddit.com/r/mcp/

6.5 MCP 的局限性

MCP 毕竟是一个刚发布不久的协议，并不是特别的成熟与完善，从 MCP 生态系统的角度来看，MCP 存在一些局限性，比如：

  • 协议不够完整

MCP 在协议层面目前只修订了两版：2024-11-05 版和 2025-03-26 版。协议的完整性还不够，比如协议没有规定主机如何与大模型交互、没有规定主机如何处理用户上传附件；比如协议规定 MCP 服务器的请求、响应格式太过单一，多模态内容支持不友好；比如协议规定了客户端的采样特性，但是没有给出实现参考等。

  • 使用门槛高、体验差

市面上已存在的 MCP 服务器，大部分都需要用户拉代码到本地运行，对于普通用户（非开发者）而言，安装环境、配置和使用 MCP 服务器的门槛较高；目前没有对 MCP 支持特别完善的大模型客户端，用户使用 MCP 服务器的体验不够好。

  • MCP 服务器质量问题

虽然市面上已经存在上万个 MCP 服务器，且在以非常快的速度增长，但是质量参差不齐，真正能用、好用、有价值的 MCP 服务器占比不高。

  • 鉴权机制不够完善

目前大部分的 MCP 服务器，都是通过环境变量读取用户的鉴权凭证，意味着用户需要手动为每个 MCP 服务器设置鉴权凭证，较为麻烦；如果要支持云端多租户（多人）场景，则需要改造 MCP 服务器的鉴权机制，支持动态传递用户鉴权凭证，协议未明确支持，改造成本高；MCP 在新协议（2025-03-26 版）中，虽然规定了 Oauth 的鉴权方式，但是目前支持此鉴权方式的 MCP 服务器非常少。

  • 安全问题

MCP 因为开源开放的特性，存在被滥用的风险。通常是攻击者通过制作恶意的 MCP 服务器，诱导用户安装，完成攻击行为，包括工具投毒、窃取用户信息、执行恶意命令、非法读取目录等方面。提升 MCP 服务器的安全性，既需要在协议层面有更严格的规定，开发者在 MCP 服务器质量上也需要严格把关，使用者更需要谨慎甄别，合理设置权限。